HTTP & HTTPS

HTTP (Hypertext Transfer Protocol)

• HTTP 超文本传输协议，是一种用于分布式、协作式和超媒体信息系统的应用层协议，可以说 HTTP 是当代互联网通信的基础。
• HTTP 有着一个致命的缺陷，那就是内容是明文传输的，没有经过任何加密，而这些明文数据会经过 WiFi、路由器、运营商、机房等多个物理设备节点，如果在这中间任意一个节点被监听，传输的内容就会完全暴露，，这一攻击手法叫做 MITM（Man In The Middle）中间人攻击。
• 可以拿小时候上课传纸条来类比，你坐在教室靠墙的一边，想要传一句「晚上放学操场我等你」给坐在窗边的小红，中间要经过六七个人的传递。虽然你把纸条对折了一下，但是防君子不防小人，中间的所有人都可以很轻易地打开纸条看到你想要说什么。只是看还好，如果有小刚也喜欢小红，看到你俩马上就要甜甜蜜蜜地回家了，心有不甘，换了一张纸条，改成了「晚上放学你自己回家吧，我要去网吧玩游戏」。小红看到你要抛弃她自己去玩游戏，非常伤心，开始在纸条上质问「说好的一起回家呢，为什么要去打游戏，哼」。在小红的纸条传回来的路上，小刚又改了纸条「你玩你的游戏去吧，我要和小刚回家」。于是，你和小红都倍感伤心，小刚横刀夺爱，而你一头雾水。

HTTPS (HyperText Transfer Protocol Secure)

• HTTPS 其实就是将 HTTP 的数据包再通过 SSL/TLS 加密后传输

1. 用户在浏览器发起 HTTPS 请求（如 https://www.google.com/），默认使用服务端的 443 端口进行连接;
2. HTTPS 需要使用一套 CA 数字证书，证书内会附带一个公钥 Pub，而与之对应的私钥 Private 保留在服务端不公开;
3. 服务端收到请求，返回配置好的包含公钥 Pub 的证书给客户端;
4. 客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示 HTTPS 警告信息，如果通过则继续;
5. 客户端生成一个用于对称加密的随机 Key，并用证书内的公钥 Pub 进行加密，发送给服务端;
6. 服务端收到随机 Key 的密文，使用与公钥 Pub 配对的私钥 Private 进行解密，得到客户端真正想发送的随机 Key;
7. 服务端使用客户端发送过来的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端;
8. 客户端使用随机 Key 对称解密密文，得到 HTTP 数据明文;
9. 后续 HTTPS 请求使用之前交换好的随机 Key 进行对称加解密;

https 中间人攻击(Man-in-the-middle attack, MITM)

1. 服务端有非对称加密的公钥 A1，私钥 A2;
2. 客户端发起请求，服务端将公钥 A1 返回给客户端;
3. 客户端随机生成一个对称加密的密钥 K，用公钥 A1 加密后发送给服务端;
4. 服务端收到密文后用自己的私钥 A2 解密，得到对称密钥 K，此时完成了安全的对称密钥交换，解决了对称加密时密钥传输被人窃取的问题;
5. 之后双方通信都使用密钥 K 进行对称加解密;

CA 颁发

服务端在使用 HTTPS 前，去经过认证的 CA 机构申请颁发一份数字证书，数字证书里包含有证书持有者、证书有效期、公钥等信息，服务端将证书发送给客户端，客户端校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作。 但是，如果中间人也聪明一点，只改动了证书中的公钥部分，客户端依然不能确认证书是否被篡改，这时我们就需要一些防伪技术了。 私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。具体过程如下：

• 数字签名

1. CA 机构拥有自己的一对公钥和私钥
2. CA 机构在颁发证书时对证书明文信息进行哈希
3. 将哈希值用私钥进行加签，得到数字签名
4. 明文数据和数字签名组成证书，传递给客户端。

• 客户端得到证书，分解成明文部分 Text 和数字签名 Sig1

1. 用 CA 机构的公钥进行解签，得到 Sig2（由于 CA 机构是一种公信身份，因此在系统或浏览器中会内置 CA 机构的证书和公钥信息）
2. 用证书里声明的哈希算法对明文 Text 部分进行哈希得到 H
3. 当自己计算得到的哈希值 T 与解签后的 Sig2 相等，表示证书可信，没有被篡改