HTTPS 的加密流程

既然要保证数据安全, 就需要进行 "加密". 网络传输中不再直接传输明文了, 而是加密之后的 "密文". 加密的方式有很多, 但是整体可以分成两大类: 对称加密（密钥由客户端生成） 和 非对称加密（服务器生成）。

    对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文。引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了。但事情没这么简单. 服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情。比较理想的做法, 就是能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥，但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了，此时后续的加密操作就形同虚设了。因此密钥的传输也必须加密传输! 但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋"的问题了. 此时密钥的传输再用对称加密就行不通了，这时就需要引入非对称加密。

    非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥". 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.通过公钥对明文加密, 变成密文，通过私钥对密文解密, 变成明文 。也可以反着用，通过私钥对明文加密, 变成密文，通过公钥对密文解密, 变成明文。客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器. 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥。服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据。后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密。那么接下来问题又来了: 客户端如何获取到公钥? 客户端如何确定这个公钥不是黑客伪造的（也称中间人，服务器生成一对公钥私钥，然后将公钥发送给客户端，但这个信息被黑客截获，然后黑客也生成一对公钥私钥，并将自己的公钥替换掉服务器的公钥，然后发送给客户端，这时客户端并不知道与它进行连接的不是服务器，直接使用发来的公钥对对称密钥进行加密后在发送给黑客，然后黑客使用自己的私钥对其进行解密，这样黑客就得到了对称密钥，然后再使用从服务器得到的公钥对其进行加密，然后服务器对其进行解密，后续与客户端进行数据交互就使用这个对称密钥，但此时黑客已经得到对称密钥，因此后续的数据交互都能被黑客所知晓）?

解决这个问题的关键在于客户端如何确定这个公钥不是黑客伪造的，因此需要引入一个证书来证明这个公钥是来自服务器的。在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书。这个证书包含了刚才的公钥, 也包含了网站的身份信息。这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息: 证书发布机构  证书有效期  公钥  证书所有者  签名 等，当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的)。判定证书的有效期是否过期，判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)，验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥（该公钥不是通过网络传输，而是直接系统内置，客户端安装好window系统后，系统就会内置各种知名公正机构的公钥，因此黑客无法进行中间人）, 对签名解密（签名由公正机构的私钥所生成，如果被替换，客户端解密不了）, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等。如果相等, 则说明证书是没有被篡改过的。（数据摘要会被证书发布机构的私钥所加密，避免它被其他设备所生成）