总结 HTTPS 的加密流程

一、前言

http是为了解决http存在的问题而在http基础上加入了SSL/TSL，在HTTP/2中TCP三次握手后会进入SSL/TSL握手，当SSL/TSL建立链接后，才会进行报文的传输。

二、HTTPS的混合加密

我们先来认识密钥：

密钥是用于加密和解密数据的关键信息。它是一个特定的值或参数，根据所使用的加密算法，用于转换明文（未加密的数据）成密文（加密的数据），或者将密文还原为明文。

我们知道加密方式有三种

对称加密
非对称加密
混合加密

引入对称加密

在对称密钥加密算法中，同一个密钥被用于加密和解密数据。发送方使用密钥将明文加密为密文，并将其发送给接收方。接收方使用相同的密钥将密文解密为明文。对称密钥加密算法的主要优点是处理速度快，但密钥的安全传输和管理是一个挑战。

也就是说只有一个密钥，把明文加密和把密文解密。

引入对称加密之后 , 即使数据被截获 , 由于黑客不知道密钥是啥 , 因此就无法进行解密 , 也就不知道请求的真实内容是啥了.

但事情没这么简单 . 服务器同一时刻其实是给很多客户端提供服务的 . 这么多客户端 , 每个人用的秘钥都必须是不同的( 如果是相同那密钥就太容易扩散了 , 黑客就也能拿到了 ). 因此 服务器就需要维护每个客户端 和每个密钥之间的关联关系 , 这也是个很麻烦的事情~

此时服务器就需要维护这个密钥与客户端之间的关系。—— 比较理想的做法 , 就是能在客户端和服务器建立连接的时候 , 双方协商确定这次的密钥是啥 ~

发现既然每个客户端的密钥都不相同，那么让客户端自己生成一个密钥，用来加密和解密数据，但是服务器此时也要知道这个密钥用来解密和加密数据。那么如何让服务器也知道这个密钥呢？ 肯定要通过网络传输的方式来让服务器知道客户端生成的密钥。

但是如果直接把密钥明文传输 , 那么黑客也就能获得密钥了 ~~ 此时后续的加密操作就形同虚设了 .

因此密钥的传输也必须加密传输 !

但是要想对密钥进行对称加密 , 就仍然需要先协商确定一个 " 密钥的密钥 ". 这就成了 " 先有鸡还是先有蛋 " 的问题了. 此时密钥的传输再用对称加密就行不通了 .

就需要引入 非对称加密

引入非对称加密

公钥 pub
私钥 pri

非对称加密要用到两个密钥 , 一个叫做 " 公钥 ", 一个叫做 " 私钥 ".

公钥和私钥是配对的 . 最大的缺点就是 运算速度非常慢 ，比对称加密要慢很多 .

通过公钥对明文加密, 变成密文
通过私钥对密文解密, 变成明文

也可以反着用

通过私钥对明文加密, 变成密文
通过公钥对密文解密, 变成明文

客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器.
由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥
服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据.
后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义

由于对称加密的效率比非对称加密高很多 , 因此只是在开始阶段协商密钥的时候使用非对称加密 ,

后续的传输仍然使用对称加密 .

中间人攻击

通过在入侵的网络设备上进行伪造服务器的公钥和私钥来进行攻击的一种手段。

此时当服务器把自己的pub发给客户端的时候，黑客自己也生成了一对公钥和私有，我们记为pub2和pri2，此时黑客就会把自己的pub2给客户端发去，通过用把服务器的pub给悄悄记住了。

此时客户端使用黑客自己生成的pub2来对key进行加密，当发送出去之后，黑客就能通过自己生成的pri2来轻松的解密，得到了key，然后有把key重新使用服务器的pub来进行加密，然后发送出去，此时服务器并不知道key已经被黑客拿到了。

服务器拿到用pub加密的key之后，并不知道黑客已经拿到了key，于是就双方就放心大胆的使用对称密钥key进行传输。

但是黑客早就直到了key，所以在传输的过程中，黑客就使用拿到的key来对数据进行解密和加密，而服务器和客户端全然不知，数据已经全部暴露。

破解中间人攻击的关键就是让客户端直到这个服务器的公钥是不是已经被篡改的。

那么接下来问题又来了:

客户端如何获取到公钥?
客户端如何确定这个公钥不是黑客伪造的?

引入证书

在客户端和服务器刚一建立连接的时候 , 服务器给客户端返回一个证书 .

这个证书包含了刚才的公钥 , 也包含了网站的身份信息 .

这个证书就好比人的身份证 , 作为这个网站的身份标识 . 搭建一个 HTTPS 网站要在 CA 机构先申请一个证书. ( 类似于去公安局办个身份证 ).

这个证书可以理解成是一个结构化的字符串, 里面包含了以下信息:

证书发布机构
证书有效期
公钥
证书所有者
签名
......

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).

判定证书的有效期是否过期
判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
验证证书是否被篡改: 从系统中拿到该证书发布机构(自己本来有的)的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.

理解判定证书篡改 的过程

假设我们的证书只是一个简单的字符串 hello, 对这个字符串计算 hash 值 ( 比如 md5), 结果为

BC4B2A76B9719D91

如果 hello 中有任意的字符被篡改了 , 比如变成了 hella, 那么计算的 md5 值就会变化很大 .

BDBD6F9CF51F2FD8

然后我们可以把这个字符串 hello 和哈希值 BC4B2A76B9719D91 从服务器返回给客户端 , 此时客户端如何验证 hello 是否是被篡改过 ?

那么就只要计算 hello 的哈希值 , 看看是不是 BC4B2A76B9719D91 即可

但是还有个问题 , 如果黑客把 hello 篡改了 , 同时也把哈希值重新计算下 , 客户端就分辨不出来了呀 .

所以被传输的哈希值不能传输明文 , 需要传输密文 .

这个哈希值在服务器端通过另外一个私钥加密 ( 这个私钥是申请证书的时候 , 证书发布机构给服务器的, 不是客户端和服务器传输对称密钥的私钥 ).

然后客户端通过操作系统里已经存的了的证书发布机构的公钥进行解密 , 还原出原始的哈希值 , 再进行校验.

完整流程

HTTPS 工作过程中涉及到的密钥有三组 .

第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.
第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组私钥-公钥对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密. 其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的.