HTTPS 的加密流程

目录

概念理解

对称密钥

非对称密钥

认证机构

---

概念理解

想要理解HTTPS的加密流程 我们首先要了解以下几个概念

1.明文：指原原本本未进过任何加密的报文，http协议就是明文传输的，但是因为其安全性问题，现在几乎很少有使用http协议来传输数据的网站了。

2.密文：经过一些加密转换成无法读懂含义的报文，起到了加密效果，黑客在窃取报文时无法因为没有对应的密钥无法识别其含义，使得报文有了一定的安全性，https就是密文传输的。

3.密钥：在密文和明文之间转换所需要的一个或者多个中间数据（密钥并不是一个函数或者一些对应规则 只是一段数据 并不起计算作用 只是作为一个参与者帮助转换 就像1+2=3里的1或2 而不是+）

---

（ps：为了让大家更好的理解https的加密机制为什么是现在这个样子，采用慢慢解决问题，逐步升级的方式来讲解）

对称密钥

知道了这些之后，我们再来了解一下对称加密

对称加密其实就是通过同一个 " 密钥 " , 把明文加密成密文 , 并且也能把密文解密成明文 .

        

一个简单的对称加密 , 按位异或

假设 明文 a = 1234, 密钥 key = 8888

则加密 a ^ key 得到的密文 b 为 9834.

然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234.

( 对于字符串的对称加密也是同理 , 每一个字符都可以表示成一个数字 )

当然 , 按位异或只是最简单的对称加密 . HTTPS 中并不是使用按位异或 .

像上图所描述，如果用客户端和服务器持有同一把密钥，即使黑客在中间截获了报文，但是因为他并没有得到这把密钥所以自然 无法顺利窃取真实内容。可问题是，服务器同时要服务很多客户端，而每个客户端所持有的密钥肯定都是不一样的，否则这把密钥就没有意义了。因此服务器就需要维护每个客户端和密钥间的关联关系，这对服务器来说显然是一件十分有负担且不易于管理的事儿。

所以我们需要解决 第一个问题： 服务器的负载太重

一个比较容易想到的解决方法是：客户端每次给服务器发起连接时再将自己的密钥传过去。

但是这时 第二个问题又出现了，可恶的 黑客也能截获到密钥!那不就更危险了吗？那不如我们把密钥也加密一遍？此时就出现了密钥的密钥...（套娃了）但是别着急，套娃不会无限进行下去，只要我们再想想办法... 此时我们就可以引入非对称加密的解决方案啦！！

---

非对称密钥

非对称加密和对称加密的区别应该很容易从字面意思理解，如果对称加密是用同一把密钥进行加密解密，那非对称加密就是用不同的两把锁加解密。其中一把我们叫它公钥，另外一把叫私钥。公钥用于加密，私钥用于解密。

我们在客户端向服务器发起询问——你的公钥是啥？服务器返回其公钥，客户端再用这把公钥对自己的密钥进行加密，再次发给服务器，服务器收到后用全世界唯他独有的私钥进行解密，于是及拿到客户端的密钥。接下来过程中双方就可以用这把密钥进行秘密对话啦！

ps：为什么不全程用非对称密钥通信？因为非对称加密的过程很复杂，计算速度比对称加密的慢太多。

更清晰的理解如图： 

好不容易解决了第二个问题成功升级了，但是狗儿子黑客实在太聪明了。他想出一个办法，我可以进行 中间人攻击！

具体过程如下： 

1.客户端询问公钥阶段，黑客不做反应

2.服务器返回公钥阶段，黑客截获，返回客户端自己的公钥

3.客户端用假公钥加密自己的密钥返回给服务器，黑客再次截获，用自己对应的私钥解密出了客户端的密钥

4.黑客拿着之前截获的服务器公钥把破解的客户端密钥加密返还给服务器

5.于是服务器用自己的私钥解密，得到的确实是客户端的真实密钥，和客户端又能拿着这个密钥进行通信，但是此时他们的交流不再秘密了，因为黑客也神不知鬼不觉得得到了这把密钥，此时他们之间的交流在黑客眼里无异于大声密谋。。。

于是我们又引出了第三个问题：怎么解决中间人攻击呢？

答：引入认证机构

---

认证机构

我们需要明确，解决中间人攻击的突破口就是让客户端能够验证，这里的公钥来自于真正的服务器。

引入认证机构后，我们在客户端请求的就不是公钥了，而是包含公钥的证书，而这个证书是服务器从权威的认证机构申请的，里面包括以下信息：

1.证书发布机构

2.证书有效期

3.公钥

4.证书所有者 （如果黑客也申请了证书想像上面那个中间人套路一样，客户端一看域名对不上就能知道证书是假的）

5.签名

.....

申请成功后和这些信息一起打包发给服务器。而客户端浏览器可以通过受信任发布机构来验证此证书是否是伪造的。

        ps:查看浏览器的受信任证书发布机构:浏览器右上角三个点->点击设置>设置里的管理证书

主要验证：

1.判定证书的有效期是否过期

2.判定证书的发布机构是否受信任 ( 操作系统中已内置的受信任的证书发布机构 ).

3.验证证书是否被篡改 : 从系统中拿到该证书发布机构的公钥 , 对签名解密 , 得到一个 hash 值 ( 称为 数 据摘要 ), 设为 hash1. 然后计算整个证书的 hash 值 , 设为 hash2. 对比 hash1 和 hash2 是否相等 .

如果相等 , 则说明证书是没有被篡改过的。

关于签名的问题我们可能会疑惑，那黑客把签名也改了不就好了吗？确实可以，所以我们对hash1的传输也要结果加密，而加密的私钥是服务器申请证书时认证机构发给他的，公钥则可以从认证机构获取。在这种情况下，虽然黑客能拿到认证机构的公钥，解密出hash1，但是因为没有私钥，所以无法对篡改的hash1进行加密。

如图： 

终于解决了在三个问题后，我们算是理解了https真正的加密过程了

送上一张图看清完整过程：