1. HTTPS是什么
HTTPS也是应用层的协议，在HTTP基础上引入了加密层。
HTTP协议是按照文本的明文方式传输的，就会导致在过程中出现被篡改的情况，例如“运营商劫持”。
如果进行明文传输，不仅用户隐私信息，甚至用户的账户余额及支付密码都会暴露。
2. “加密”是什么
加密就是把明文（传输的信息）经过一系列转换生成密文。
明文: h e l l o （想发送的真实内容） +3 +3 +3 +3 +3 （规则：每个字母后移 3 位） 密文: k h o o r （信道上实际传输的内容）解密就是把密文进行一系列变换还原成明文。
密文: k h o o r -3 -3 -3 -3 -3 （拿同一把"钥匙"反着移回来） 明文: h e l l o ✅ 还原成功3. HTTPS的工作过程
3.1 对称加密
就是通过同一个密钥，可以把明文加密成密文，也可以把密文解成明文。
服务器同一时刻需要为多个用户提供服务，需要维护不同用户的密钥，每个人的密钥必须不同，所以要想维护每个人的密钥非常麻烦。
所以比较理想的办法是在双方建立连接的时候来商量密钥是什么，但是呢，如果把密钥进行明文传输，那么黑客也能获取密钥，所以密钥也需要加密传输，但是“密钥的密钥”就成了一个新问题。
所以需要引入非对称加密。
3.2 非对称加密
非对称加密需要两个密钥，分别为“公钥”和“私钥”，这两个是配对的，缺点是运算速度慢，比对称加密慢不少。
- 通过公钥对明⽂加密，变成密文
- 通过私钥对密文解密，变成明文
两个钥也可以反着用。
- 客户端在本地生成对称密钥，再通过公钥加密，发送给服务器。
- 即便是中间有设备捕获这个密文，在没有私钥的情况下无法得知里面的密钥。
- 服务器通过自己的私钥对密文进行解析得到里面的对称密钥，并使用这个对称密钥加密给客户端的响应数据。
- 后续的通信使用对称密钥加密即可，由于对称密钥只有客户端和服务器知道，即使中间有设备拦截数据也无济于事。
此时有了新问题：
客户端怎么获取的公钥？
客户端怎么确定获取的公钥不是黑客伪造的？
3.3 中间人攻击
黑客通过攻击获取对称密钥。
服务器有非对称加密算法的公钥S，私钥S`，黑客有非对称加密算法的M，M`。
- 客户端给服务器发送请求，服务器明文返回公钥给客户端。
- 中间人劫持数据获取公钥S并保存，把被劫持的报文里的公钥换为自己的公钥M，将伪造的报文发给客户端。
- 然后客户端使用M将手里的对称密钥X进行加密再发出去，黑客获取到这个报文利用手里的私钥M` 解密获取密钥X，黑客利用之前保存的S给X进行加密发送给服务器。
- 服务器拿到报文后利用手里的私钥S` 对报文解密获取里面的密钥X。
- 之后客户端和服务器利用密钥X进行通信，但是中间人已经知道了密钥，所以可以获取通信数据甚至修改。
3.4 引入证书
服务端使用HTTPS之前需要向CA机构申请数字证书，数字证书含有申请者、公钥信息等。服务器把证书传给浏览器，浏览器从里面获取公钥。
证书包含信息：证书发布机构，证书有效期、公钥、证书所有者、签名等。
申请证书会生成密钥对（公钥和私钥），公钥写进证书，私钥服务器藏好不公开。
3.5 数字签名
当服务端申请CA证书的时候，CA机构会对服务端进行审核，并为该网站形成数字签名，过程如下：
- CA机构有非对称加密算法的公钥A`和私钥A
- CA机构对服务端生成的证书明文进行hash，形成数据摘要
- 然后对数据摘要需要用CA的私钥A进行加密得到数字签名S
服务端申请的证书明文和数字签名S组合成数字证书发给服务端
3.6 使用证书解决中间人攻击
客户端建立连接的时候服务端给客户端返回了证书，证书包含了公钥和网站身份信息。
客户端获取证书后，会对这个证书进行校验：
- 判断证书是否过期
- 判断证书发送是否信任（操作系统已内置受信任的发送机构）
- 客户端取出证书的明文，使用相同hash的方法计算一遍摘要，得到摘要1
- 使用内置的CA公钥A`解开数字签名S，得到摘要2
- 如果摘要1和摘要2相同则证明是正确的证书，反之证书可能被人篡改
3.7 中间人有无可能篡改该证书
- 中间人篡改了证书
- 中间人没有CA的私钥，无法hash后对私钥加密形成签名，也没法对篡改后的证书形成匹配的签名
- 如果强行篡改，客户端发现 hash后证书的明文 和 解析数字签名的值 对不上，说明证书已被篡改，停止向服务器发送信息
3.8 中间人掉包整个证书
中间人没有CA的私钥，没办法造假证书。中间人只能向CA申请证书，然后进行掉包。但是证书里是包含服务器域名等相关信息的，客户端依旧会察觉。
记住一点：中间人没有CA的私钥，无法对任何证书进行修改。
4. 常见问题
（1）为什么摘要内容在网络传输中一定加密形成签名？
- 只发明文 + 哈希：能验完整性，但哈希是明文传输的 → 黑客改
hello为hella，顺手重算 MD5 一起换掉 → 客户端对比通过，被骗。 - 所以哈希必须加密：用CA 私钥加密摘要 = 签名 → 黑客没有 CA 私钥，改了明文也造不出能通过验证的签名；
- 客户端验证：用内置的 CA 公钥解签名还原出 CA 当初的摘要，再和自己重算的摘要比对——一致则证书可信。
（2）为什么签名不直接加密，而是先形成hash摘要？
非对称加密很慢，证书是很长的，先用hash把正文转换成定长的内容，这样加快了验证签名的速度。
流程：数据 → Hash → 摘要 → 私钥加密 → 签名。
（3）完整流程
5. 总结
HTTPS 工作过程中涉及到的密钥有三组。
第一组（非对称加密）：用于校验证书是否被篡改。服务器持有私钥（私钥在注册证书时获得），客户端持有公钥（操作系统包含了可信任的 CA 认证机构有哪些，同时持有对应的公钥）。服务器使用这个私钥对证书的签名进行加密。客户端通过这个公钥解密获取到证书的签名，从而校验证书内容是否是被篡改过。
第二组（非对称加密）：用于协商生成对称加密的密钥。服务器生成这组私钥-公钥对，然后通过证书把公钥传递给客户端。然后客户端用这个公钥给生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥。
第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。
其实一切的关键都是围绕这个对称加密的密钥。其他的机制都是辅助这个密钥工作的。
第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器。
第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。
