HTTPS加密过程（个人总结）

---

HTTP存在的问题

http明文传输，且无身份认证，防篡改机制，因此是既不安全的。

综合来说，http存在三大安全问题：

1. 明文传输，信息泄露
2. 无防篡改机制，可能被黑客将信息篡改
3. 无身份认证，收到假冒网站发来的信息

---

对称加密

为了解决上述问题，首先考虑到对称加密。

浏览器和服务器共享一个秘钥，两方发消息时都通过这个秘钥来对数据进行加密和解密。这样黑客窃取到的都是经过加密的消息。

存在问题：浏览器和服务器交换秘钥时是明文传输，这样黑客就可以提前窃取到这个秘钥，之后两方的加密消息都可以这个黑客解密。

---

非对称加密

为了使这个对称加密的秘钥避免明文传输，可以使用非对称加密机制。

服务器有一对公钥和私钥，浏览器发的消息都用服务器的这个公钥来加密，而这个消息解密只能用服务器的私钥进行解密。服务器的这个公钥是公开的，但私钥是私有的。此时黑客因为不知道服务器的私钥，因此窃取到信息也无法解开。同理，浏览器也可以准备一对公钥与私钥，服务器发消息用浏览器的公钥，这个消息只有浏览器的私钥可以解密。

存在问题：黑客可以提前截取公钥并提供一对假秘钥，因为浏览器和服务器交换公钥时依然是明文传输。

1. 情况一，黑客截取服务器要给浏览器的公钥，这个公钥本来是给浏览器用作加密信息的，此时黑客将自己的假冒的一对公私钥中的公钥给浏览器，这样浏览器发的消息都是用黑客的假公钥进行加密，这样黑客用自己的私钥就可以解密消息，导致消息泄露（银行卡密码没了）。
2. 情况二，黑客截取浏览器要给服务器的公钥，这个公钥本来是给服务器用作加密信息的，此时黑客将自己的假冒的一对公私钥中的公钥给服务器，这样服务器发的消息都是用黑客的假公钥进行加密，这样黑客用自己的私钥就可以解密消息，从而篡改消息（进入黑客链接，填了银行卡，银行卡密码没了）。
3. 实际情况中，非对称加密计算耗费计算过程，每一步都用这种加密方式会降低传输效率。

总结来说：用非对称加密技术来传输用来对称加密的秘钥确实可以防止黑客窃取到，因为交换过程是非对称加密的公钥，这个公钥只能用来加密而不能用来解密，因此即使黑客拿到非对称加密的公钥也无济于事。

而上面的例子说的都是黑客将自己的一对公私钥来替换真正的公私钥，这样浏览器或者服务器就会用假的公钥加密，信息被黑客窃取，这就是仅用非对称加密无法解决身份冒充问题。

---

数字签名

为了解决防篡改的问题，可以利用数字签名技术。

通过将此次发送的报文进行hash计算出一个摘要。（此时用MD5等不可逆加密算法，防止被窃取后通过逆运算解析出原报文）。
发送时将报文和数字签名一起发送，这样只要被修改一个bit，就会导致对端利用同样算法计算出来的摘要与发送过来的数字签名不一致。

---

数字证书

为了防止黑客利用自己的公私钥进行身份假冒，引入权威可信的第三方机构。
CA机构用自己的私钥对服务器要交换的公钥进行数字签名并加密。浏览器收到这个CA后首先验证是否是真正的CA，只要是真的CA，就可以利用这个CA机构对应的公钥进行解密（此时验证了是真正服务器发来的公钥，防止了黑客发送假冒证书），然后利用同样的算法计算证书里面的公钥的数字签名，如果计算出来的结果与证书里面的数字签名一样（此时验证了数字证书没有被篡改），下次就可以用这个公钥进行非对称加密来交换浏览器与服务器真正需要用来对称加密的公钥。

题外音1：黑客可以利用CA的公钥解密证书里面的东西，他可以替换成自己的公私钥在给浏览器啊！（因为数字证书都是用CA的私钥进行加密的，浏览器如果收到假证书，因为只要不是真CA私钥进行加密的数字证书，就无法用公钥解开，所以保证了黑客假冒的数字证书）

题外音2：黑客可以通过解密CA拿到服务器发来的公钥，这咋办？（拿就拿呗，反正这个公钥是用来非对称加密的，浏览器用这个服务器公钥加密后必须由服务器的私钥进行解密，所以说拿到也没啥用）