HTTP协议探究（三）：HTTPS

一 复习与目标

1 复习

• 代理：转发通信数据（一般协议不变，作为中间人，可对报文进行过滤修改）
• 网关：转发通信数据（协议改变，作为资源拥有者）
• 隧道：转发通信数据（协议不变，作为管道，不对报文进行过滤修改）

2 目标

• HTTP请求的安全问题
• 简单密码学
• 对称加密与非对称加密
• SSL/TLS
• HTTPS

二 HTTP请求的安全问题

• 缺乏保密性：HTTP使用明文，内容可能被窃听
• 缺乏完整性：无法验证报文的完整性，报文可能被篡改
• 缺乏鉴别性：不验证通信方的身份，可能遭遇伪装（中间人攻击）

三 数字加密

1 简单密码学

（1）基本定义

• 明文：原始的报文
• 密文：转换后的报文
• 加密算法：明文转换成密文
• 解密算法：密文转换成明文
• 密码算法：加密和解密算法合称密码算法
• 密钥：密码算法中参与运算的数值。
• 对称加密（如DES）：加解密使用同一个密钥
• 非对称加密（如RSA）：密钥为一对，公开的称为公钥，自己保留的称为私钥，公钥加密的数据使用私钥解密，反之亦然。

（2）传统加密算法（字符）

• 替换加密：使用一个符号替换另一个符号
• 移位加密：字母按照ASCII码移动几位
• 换位加密：某个字母与另一个字母换位置

（3）现代简单加密算法（位）

• XOR加密：明文与密钥异或运算
• 旋转加密：位替换的加密算法（长度不变）
• 替换加密（S-盒）：位替换的加密算法（长度改变）
• 换位加密（P-盒）：位换位的加密算法

（4）现代迭代加密

• 迭代加密：使用多个密钥(密钥生成器生成)进行迭代加密

（5）总结

• HTTP明文经过上述某个加密算法变成了密文传输，解决了保密性

2 数字签名

• 发送方使用私钥对报文进行加密生成签名，对方使用公钥进行解密，验证签名的正确性。
• 签名使用了非对称加密算法，得知谁编写了该报文，解决鉴别性
• 签名使用了散列函数(MD5、SHA1等)，防止报文被篡改，解决了完整性

注1：非对称加密好处是安全，但是效率不高，并且公钥不一定是真实可信的。

注2：散列函数不可逆运算，所以报文修改将导致hash值改变，接收方就可以知道报文被篡改。

3 数字证书

• 身份、过期时间
• 证书颁发者、来自证书颁发者的数字签名
• 公钥、签名算法的描述信息

注：证书 = 公钥 + 颁发者信息，即由颁发者来证明该公钥的真实性和可信度。所以如果颁发者不可靠，其实该公钥就是不可靠的。

四 SSL/TLS

• HTTPS，其实就是身披SSL/TLS协议这层外壳的HTTP。

• SSL协议独立于HTTP协议，位于传输层之上应用层之下的会话层。

• SSL协议不光只为HTTP协议提供安全支持，还能为WebSocket、SMTP、Telnet等协议提供支持。

• HTTPS采用了混合加密机制，即充分利用非对称加密和对称加密的优势。

注1：SSL和TLS本质上没有区别，不需要纠结它们关系，真想知道请看《图解HTTP》第156页。

注2：混合多种算法的优势是很常见的，如：jdk中的排序算法就混合了快排和插入算法。

五 HTTPS的安全通信机制

• 步骤1：Client -> Server，Client Hello报文，报文包含SSL的指定版本、加密组件列表
• 步骤2：Server -> Client，Server Hello报文，报文包含 SSL 版本以及加密组件，其实就是根据Client报文选择其中一个来进行双方通信的加解密。
• 步骤3：Server -> Client，Certificate报文，包含证书、公钥等信息
• 步骤4：Server -> Client，Server Hello Done报文， SSL 握手协商部分结束
• 步骤5：Client -> Server，Client Key Exchange 报文，包含Pre-master secret 的随机密码串（共享密钥）
• 步骤6：Client -> Server，Change Cipher Spec 报文，提示服务器，之后报文采用 Pre-master secret 密钥加密
• 步骤7：Client -> Server，Finished 报文，包含连接至今全部报文的整体校验值，Server根据私钥解密成功则进入下一步，否则协商失败。
• 步骤8：Server -> Client，Change Cipher Spec报文
• 步骤9：Server -> Client，Finished报文，包含连接至今全部报文的整体校验值，Client根据公钥解密成功则进入下一步，否则协商失败。
• 步骤10：Client -> Server 此时双方已建立起SSL通信管道了，发送HTTP请求。
• 步骤11：Server -> Client，发送HTTP响应
• 步骤 12： 最后由客户端断开连接，发送close_notify 报文。

六 HTTPS的抓包分析

# TCP三次握手连接
192.168.1.46	103.61.37.178	TCP	64600 → 443 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
103.61.37.178	192.168.1.46	TCP	443 → 64600 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1410 SACK_PERM=1 WS=128
192.168.1.46	103.61.37.178	TCP	64600 → 443 [ACK] Seq=1 Ack=1 Win=66048 Len=0

# HTTPS握手协议
192.168.1.46	103.61.37.178	TLSv1.2	Client Hello
103.61.37.178	192.168.1.46	TCP	443 → 64600 [ACK] Seq=1 Ack=518 Win=30336 Len=0

103.61.37.178	192.168.1.46	TLSv1.2	Server Hello
103.61.37.178	192.168.1.46	TLSv1.2	Certificate [TCP segment of a reassembled PDU]
192.168.1.46	103.61.37.178	TCP	64600 → 443 [ACK] Seq=518 Ack=2821 Win=66048 Len=0
103.61.37.178	192.168.1.46	TLSv1.2	Server Key Exchange, Server Hello Done
192.168.1.46	103.61.37.178	TLSv1.2	Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

192.168.1.46	103.61.37.178	TLSv1.2	Application Data
192.168.1.46	103.61.37.178	TLSv1.2	Application Data

# TLS优化相关内容:https://imququ.com/post/optimize-tls-handshake.html
# Session Ticket可以使得客户端不需要多次重复获取证书
103.61.37.178	192.168.1.46	TLSv1.2	New Session Ticket, Change Cipher Spec, Encrypted Handshake Message
103.61.37.178	192.168.1.46	TLSv1.2	Application Data
192.168.1.46	103.61.37.178	TCP	64600 → 443 [ACK] Seq=1058 Ack=3392 Win=65536 Len=0

......

# 四次挥手断开
103.61.37.178	192.168.1.46	TLSv1.2	Encrypted Alert
103.61.37.178	192.168.1.46	TCP	443 → 64600 [FIN, ACK] Seq=5125 Ack=2501 Win=36736 Len=0
192.168.1.46	103.61.37.178	TCP	64600 → 443 [ACK] Seq=2501 Ack=5126 Win=65536 Len=0
192.168.1.46	103.61.37.178	TCP	64600 → 443 [FIN, ACK] Seq=2501 Ack=5126 Win=65536 Len=0
103.61.37.178	192.168.1.46	TCP	443 → 64600 [ACK] Seq=5126 Ack=2502 Win=36736 Len=0

注：HTTP/HTTPS优化，后面讲解，这一节知道什么是HTTPS即可。

参考：

• 《图解HTTP》
• 《HTTP权威指南》
• 《Web性能调优指南》
• 《数据通信与网络》