HTTPS用的是对称加密还是非对称加密？

1）为什么用了 HTTPS 就是安全的？

2）HTTPS 的底层原理如何实现？

3）用了 HTTPS 就一定安全吗？

HTTPS 的实现原理

大家可能都听说过 HTTPS 协议之所以是安全的是因为 HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现。但其实：HTTPS 在内容传输的加密上使用的是对称加密，非对称加密只作用在证书验证阶段。

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

① 证书验证阶段：

• 1）浏览器发起 HTTPS 请求；
• 2）服务端返回 HTTPS 证书；
• 3）客户端验证证书是否合法，如果不合法则提示告警。

② 数据传输阶段：

• 1）当证书验证合法后，在本地生成随机数；
• 2）通过公钥加密随机数，并把加密后的随机数传输到服务端；
• 3）服务端通过私钥对随机数进行解密；
• 4）服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输。

1. 为什么数据传输是用对称加密的？

首先：非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。

另外：在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密

2. 为什么需要CA机构颁发证书？

防止”中间人“攻击，同时可以为网站提供身份证明。

3. 使用https会被抓包吗？

会被抓包，HTTPS 只防止用户在不知情的情况下通信被监听，如果用户主动授信，是可以构建“中间人”网络，代理软件可以对传输内容进行解密。

4. 中间人攻击

中间人的确无法得到浏览器生成的密钥B，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开拿到它呀！然而中间人却完全不需要拿到密钥A’就能干坏事了。请看：

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
6. 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人得到了密钥B。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。那么下一步就是解决下面这个问题：

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

数字签名的制作过程：

1. CA拥有非对称加密的私钥和公钥。
2. CA对证书明文信息进行hash。
3. 对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。
那浏览器拿到服务器传来的数字证书后，如何验证它是不是真的？（有没有被篡改、掉包）

浏览器验证过程：

1. 拿到证书，得到明文T，数字签名S。
2. 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
3. 用证书里说明的hash算法对明文T进行hash得到T’。
4. 比较S’是否等于T’，等于则表明证书可信。

为什么这样可以证明证书可信呢？我们来仔细想一下。

中间人有可能篡改证书吗？假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改

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

假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，会导致上文提到的漏洞。
其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

参考链接：https://juejin.im/post/5b8f3190e51d4538a67abfad#heading-4