HTTPS的加密原理

什么是对称加密？

简单说就是有一个密钥，它可以加密一段信息，也可以对加密后的信息进行解密，和我们日常生活中用的钥匙作用差不多。

用对称加密可行吗？

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。

什么是非对称加密？

简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

用非对称加密可行吗？

服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，只有服务器有相应的私钥能解开公钥加密的数据。

反过来，由服务器到浏览器，任何手持公钥的浏览器都能解密，所以并不安全。

非对称加密+对称加密可行吗？

1，浏览器向网站服务器请求，服务器把公钥明文给传输浏览器。

2，浏览器随机生成一个用于对称加密的密钥X，用公钥加密后传给服务器。

3，服务器拿到后用私钥解密得到密钥X。

这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。HTTPS基本就是采用了这种方案。完美？还是有漏洞的。

中间人两边欺骗的操作：

1，浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。

2，中间人劫持到公钥A，把数据包中的公钥A替换成自己的公钥B，再发送给浏览器。

3，浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。

4，中间人劫持后用私钥B解密得到密钥X，再用公钥A加密后传给服务器。

5，服务器拿到后用私钥A解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人通过一套“狸猫换太子”的操作，掉包了服务器传来的公钥，进而得到了密钥X。根本原因是浏览器无法确认收到的公钥是不是网站自己的，因为公钥本身是需要明文传输的。

如何证明浏览器收到的公钥一定是该网站的公钥？

所有证明的源头都是一条或多条不证自明的“公理”，由它推导出一切。身份证能证明身份的公理，就是“政府信用背书”，这也是社会正常运作的前提。

那能不能类似地有个机构充当互联网世界的“公理”呢？让它作为一切证明的源头，给网站颁发一个“身份证”？它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

什么是数字证书？

使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。

如何放防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，然后，对比得到的签名和生成的签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫数字签名。

数字签名的制作过程：

1，CA机构拥有非对称加密的私钥和公钥。

2，CA机构对证书明文数据T进行hash，对hash后的值用私钥加密，得到数字签名S。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了，以后，网站就能将证书发送给浏览器，浏览器拿到证书后，验证一下真伪。

浏览器验证过程：

拿到证书，得到明文T，签名S。

用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥），得到S’。

用证书里指明的hash算法对明文T进行hash得到T’。

显然通过以上步骤，T’应当等于S‘，除非明文或签名被篡改。所以此时比较S’是否等于T’，等于则表明证书可信。

中间人有可能篡改该证书吗？

中间人没有CA机构的私钥，即便中间人自己的私钥加密生成的签名，浏览器验证签名时发现签名不一致，从而发现证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

中间人有可能把证书掉包吗？

因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

怎么证明CA机构的公钥是可信的？

操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。

实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。

为什么会遇到提示安装证书？

说明浏览器不认给这个网站颁发证书的机构，那么你就得手动下载安装该机构的根证书（风险自己承担）。安装后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？

服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作和传输密钥了。

by： 彻底搞懂HTTPS的加密原理 - 知乎 (zhihu.com)