HTTPS 的加密流程

明文：要传输的原始数据。密文：把明文进行一系列转换之后，变成了一个看不懂的内容。

加密： 明文 -> 密文的过程。解密：密文 -> 明文的过程。

加密和解密的过程中，用到了一个特殊的数据，即密钥。

对称加密：一个密钥，既可以加密，也可以解密。

非对称加密：两个密钥key1 key2（key1和key2是一对有关联关系的数字，数学理论支撑），如果使用key1加密，就使用key2解密；如果使用key2加密，就使用key1解密。把其中一个，公开出去，称为 "公钥"；另一个自己保存好，称为 "私钥"。

加密解密的具体细节/算法，属于 "数学问题"，计算机圈子中有很多现成的库，可以直接使用，此处谈流程即可。

一、引入对称加密

客户端或服务器生成一个密钥，让对方也持有这个密钥。客户端发送给服务器的数据，使用这个密钥加密，服务器就使用这个密钥解密。HTTP的header和body加密，首行不需要。

此时黑客看到的是加密后的数据，由于黑客没有密钥，就无法进行解密，就不知道请求的真实内容是什么了。但事情没那么简单，服务器同一时刻是要给很多个客户端提供服务的，每个人用的密钥都必须是不同的（如果是相同的 那密钥就太容易扩散了，黑客就也能拿到了）。

比较理想的做法，就是在客户端和服务器建立连接的时候，双方协商确定这次的密钥是啥，让客户端生成一个随机的对称密钥，再把这个对称密钥通过网络传输给服务器。

此时888888密钥被黑客拿到了。如果直接把密钥明文传输，那么黑客也就能获得密钥了，此时后续的加密操作形同虚设了。因此密钥的传输也必须加密传输。如何对密钥安全传输呢？也得加密~再搞一个对称密钥77777，对888888进行加密吗？如果这么搞，还得明文传输77777（又被黑客拿到了）。再搞一个对称密钥6666对77777加密吗？如果这么搞，还得明文传输6666......

二、引入非对称加密

黑客入侵的设备，即使拿到了数据，也无法解密，也就无法获取到对称密钥。因为它手里只有公钥，没有私钥。公钥是一把锁头（给谁都行），私钥是对应的钥匙。后续客户端和服务器都只用对称加密即可，由于该对称密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥，即使截获数据也没有意义。注：服务器两次生成的公钥私钥，是不同的，随机的。

只使用非对称，针对刚才客户端和服务器传输的数据进行密文传输是否可行呢？对称加密，效率比较高，占用的系统资源少；非对称加密，效率比较低，占用的系统资源多。使用非对称加密，传输对称密钥，规避非对称加密开销大的问题。使用对称密钥 加密数据，由于对称密钥已经安全到达对方了，对称加密也一样是安全的。

但是上述通信方案存在缺陷，黑客巧妙利用此缺陷进行攻击。

三、中间人攻击

四、引入证书（应对中间人攻击）

证书是第三方公证机构给服务器颁发的，可以理解成是一个结构化的字符串。证书就如身份证，证明服务器公钥的权威性。

安装 Fiddler 的时候，要安装证书。Fiddler 抓取 https 的时候，就是在进行中间人攻击，需要你信任 Fiddler 的证书，信任了 Fiddler 的公钥。Fiddler 把证书中的 pub1 和数字签名都替换了，使用自己的私钥，对校验和加密。信任 Fiddler 的证书，安装了 Fiddler 的公钥，Fiddler 就也是 "公证机构"，客户端对 Fiddler 的数据进行验证的时候，使用  Fiddler 的公钥解密数字签名。