---

一、HTTPS

HTTPS协议其实就是将HTTP协议中发送的报文和接收的报文经过加密后发送出去。
这就是HTTPS协议。

• 加密就是将一个原文经过一系列变换变成另一个密文。
• 解密就是将一个密文经过一系列变换变回原文。

二、HTTPS协议五种加密方案

1.只使用对称加密

对称加密，对称加密就是通信双方都持有同一个密钥。
假如这个密钥没有被其他人知道的话，这样通信双方就会是安全的。

但是没有假如，对称密钥也就是只持有一个公钥，这个公钥通过客户端发送给服务器时，要经过网络，极易被其他人获取到，这样双方的通信就不安全了。

并且，如果是客户端持有公钥的话，每个客户端对应发送一个公钥给客户端，服务器同时连接成千上万个客户端，这样就需要保存和管理多份公钥数据对象，这也是一个比较麻烦且耗时的问题。

所以理想的做法是，在进行通信前，就进行密钥协商。

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

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

不过由于只有一个公钥进行加密解密，所以速度非常快，算法不复杂，如果在安全的前提下，使用对称加密是非常高效的。

2.只使用非对称加密

非对称密钥是，持有一对密钥，分别是公钥和私钥。
可以采用公钥加密，私钥解密；也可以私钥加密，公钥解密。

服务器与客户端进行通信前，服务器发送公钥给客户端。
客户端发送数据给服务器前，会进行加密，这样就能保证客户端到服务器单方面安全（其实也还有安全问题）

3.双方都使用非对称加密

客户端和服务器各持有一对密钥，分别是公钥和私钥。

双方开始进行数据通信时，客户端发送自己的公钥C给服务器，服务器收到后，发送自己的公钥S给客户端。这样通信两端就持有对方的公钥。

此时再进行数据通信时，使用对方的公钥进行加密，虽然中间人也截取到双方的公钥，但是没有私钥，是无法解密的。这样就保证了双方的通信安全（真的吗？)

看似安全了，这个方案仍然存在两个问题:

1.不安全
2.效率低下

使用非对称密钥进行加密解密，会经过大量算法计算，就会比较耗时。

4.对称加密+非对称加密

服务器持有一对密钥：公钥S和私钥S’
客户端本地生成一个对称密钥C

服务端具有非对称公钥 S 和私钥 S’

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

这样就大大提高了效率，因为只有一开始使用非对称加密进行密钥交换，后续都会使用对称加密进行通信。

但是！

其实方案2，3，4都存在安全问题：中间人攻击

中间人攻击

比如方案4：

• 1.服务器自己持有一对密钥S和S’，中间人自己也持有一对密钥M和M’
• 2.客户端发起HTTP请求时，服务器发送响应，将自己的公钥S发给客户端，中间人将服务器的公钥S，替换成自己的公钥M，继续发给客户端。
• 3.客户端将自己本地生成的对称密钥C，通过服务端的公钥加密后（客户端当然不知道已经被换了），发送给服务端。
• 4.中间人使用自己的私钥M’进行解密，获取到了客户端的对称密钥
• 5.将该对称密钥用曾经获取到的服务器的公钥S加密后，继续将报文发给服务器，服务器此时通过自己的私钥S’，也拿到了客户端的对称密钥。
• 6.客户端和服务器从此之后使用对称密钥加密通信。
• 7.中间人对整个过程了如指掌，想监听，窃取和篡改数据都可以了。

如上的攻击过程同样对方案2，3有用。

问题的本质就出现在，客户端无法确定收到含有公钥的报文，就是服务器发过来的！！

理解数字签名

1.将一份数据（比如10000字节），经过一些哈希函数算法计算后，得到一个散列值，这个散列值叫数据摘要（这个散列值是固定长度的）。
2.再用该散列值，拿签名者的私钥进行加密，得到数字签名（比如50字节)。
3.拿原数据和签名进行拼接（10050字节），就得到了带有数字签名的数据。

数字签名存在的意义，就是验证原始的明文数据是否被篡改过。
我们知道，用哈希算法形成的数据摘要，只要原始数据修改过1个比特位，其形成的数据摘要都差别非常大的。（几乎不可能形成重复的数据摘要）

如何验证数字签名？

1.将原始的明文数据，进行同样的哈希算法得到一个散列值。
2.再拿签名者的公钥，进行解密，得到散列值。
3.判断两者的散列值是否一样，如果一样，则数字签名有效，即数据没有被篡改过。

---

这里有很多疑问。
1.签名者是谁？为什么要用他的签名？我的签名，中间人的签名不行吗？

如果采用中间人自己的私钥对散列值加密，得到一个数字签名，然后让客户端用中间人自己的公钥
解密，得到相同的散列值，这样是可以的。但问题是，客户端不承认中间人的合法性！！！
在颁发数字签名给服务器客户端时，就已经内置式地通知客户端，必须使用我给你的公钥来对数字签名解密，用其他任何人的公钥解密都是无效的！！

因为世界上只有我一个人持有私钥，意味着只有我一个人可以进行数字签名！！
这是一种权力，谁持有大家都认可的公钥，谁就可以签名。

CA机构和证书

其实，CA机构就是上面数字签名中的签名者。

而证书的样子如下：
证书并不是只包含一个服务器的公钥，而是在证书中含有公钥。

证书 = 用明文信息经过哈希算法生成数据摘要后再通过CA机构的私钥加密生成的数字签名 + 原始的明文信息。

服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性

证书的申请过程：

1.服务器填写资料，包括服务器自己的公钥等信息，生成请求文件发给CA机构。
2.CA机构进行审核，审核通过后，通过数字签名+服务器的明文信息形成证书发给申请者（服务器）
3.有客户端建立HTTPS请求时，服务器发给客户端的响应中就会携带证书。
4.客户端提取证书的数字签名拿内置的CA机构的公钥对签名解密，在对证书的明文信息进行哈希算法加密后形成的两个散列值对比验证证书的合法性。

只要合法了，就能进行对称加密通信了！！

---

5. 对称加密+非对称加密+证书认证

到这里，其实已经知道了方案5的具体实现流程了。

客户端进行认证
当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的。

中间人篡改证书？

中间人如果篡改证书中的公钥，改成自己的，客户端在进行证书认证时，对明文信息进行哈希得到的散列值和对数字签名进行解密（用CA机构给的公钥）得到的散列值就不一样，就认定证书不合法，此时客户端就不会再对服务器进行通信了！

中间人调包整个证书？

中间人没有CA机构的私钥，无法用哈希后的散列值进行私钥加密，就无法制作假证书。
想要调包整个证书，只能去申请真的证书来调包服务器的证书。
这样做理论上可行，但是，证书中除了有公钥信息，还有域名信息等。
域名信息也是具有唯一性的，客户端一检查发现域名不对，也会停止向服务器发送信息。

更何况，中间人既然是中间人，他也不会傻到泄露自己的信息去申请真证书吧。

常见问题

1.为什么用哈希算法形成的摘要在网络中传输时一定要加密形成签名？

• 1）通过CA机构的私钥加密形成签名才能保证证书合法性，因为中间人无法调包证书，也无法篡改证书。
• 2）如果不加密，直接传输摘要，那中间人很容易就把摘要替换调包，（可以直接替换内容，然后通过MD5等算法生成一样的摘要）这样就不具备安全性了。

2.为什么明文数据不直接通过CA机构的私钥加密形成签名，而是要先通过哈希形成摘要？

• 这样是为了缩小形成签名后的长度，加快形成签名的时间和对签名验证的时间，提高效率。

总结

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

• 第一组(非对称加密)：用于校验证书是否被篡改。服务器持有CA证书，客户端持有CA机构的公钥（操作系统包含了可信任的CA认证机构并持有对应的公钥），客户端会对服务器发来的CA证书进行认证，保证证书合法性，其实就是让客户端信任服务器是合法的，同时也保证了服务器的公钥是合法的。
• 第二组（非对称加密）：用于协商生成的对称密钥。客户端通过信任后的服务器公钥加密，将客户端本地生成的对称密钥加密后传输给服务器，服务器用自己的私钥解密，得到对称密钥。
• 第三组（对称加密）：双方都持有对称密钥，此后使用对称加密进行通信。

第一组对称密钥（CA的公钥和私钥）是为了让客户端拿到第二组对称密钥的公钥（服务器的）
第二组对称密钥（服务器的公钥和私钥）是为了安全拿到客户端传输过来的对称密钥。