HTTPS
HTTP协议安全上存在以下三个风险:完整性 可用性 保密性
窃听风险,比如通信链路上可以获取通信内容,用户号容易没。
篡改风险,比如强制植入垃圾广告,视觉污染,用户眼容易瞎。
冒充风险,比如冒充淘宝网站,用户钱容易没。
HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议,来解决上述的风险。
TLS 协议是如何解决 HTTP 的风险的呢?
TLS能够加密交互信息,如果信息泄露被篡改则会有警告提示,并且拥有身份证书证明发送端非伪造。
TLS 握手
上述每个框都是一个记录,多个记录可组合为一个tcp包,通常四个包就可以完成TCP握手
因为需要先完成TCP连接,然后通过TLS握手才建立安全通信链接,所以可以发现HTTPS是应用层协议。
密钥交换算法
因为在传输过程中想要保证加密密钥的安全性,所以采用了非对称加密的方法来保护对称加密的加密密钥。
RSA密钥协商握手过程
TLS 第一次握手
客户端发起握手请求(ClientHello)
客户端向服务器发送第一个消息,包含以下关键信息:
- 支持的 TLS 版本(如 TLS 1.2)。
- 支持的加密套件列表(需包含以 RSA 为密钥交换方式的套件,如
TLS_RSA_WITH_AES_256_CBC_SHA
)。 - 客户端生成的随机数(Client Random):16 字节,用于后续密钥计算。
- 其他可选信息(如压缩方法、扩展字段等)。
TLS 第二次握手
服务器回应(ServerHello)
服务器根据客户端的请求,选择合适的配置并返回消息:
- 确认使用的 TLS 版本和加密套件(必须是客户端支持的 RSA 类套件)。
- 服务器生成的随机数(Server Random):16 字节,同样用于密钥计算。
- (可选)会话 ID:用于复用已有会话,减少握手次数。
客户端验证证书
服务器发送证书及相关信息(Certificate + ServerHelloDone)
- Certificate 消息:服务器向客户端发送自己的数字证书(包含服务器 RSA 公钥),证书链可能包含多级 CA 证书(从服务器证书到根 CA 证书)。
- (可选)CertificateRequest:若服务器需要验证客户端身份(如双向认证),会请求客户端证书。
- ServerHelloDone 消息:表示服务器已完成初始消息发送,等待客户端回应。
TLS 第三次握手
客户端发送加密的预主密钥(ClientKeyExchange)
客户端将加密后的 PMS 通过ClientKeyExchange 消息发送给服务器。由于 PMS 用服务器公钥加密,中途被窃听也无法解密。
客户端和服务器计算会话密钥(Master Secret + Session Keys)
- 服务器解密 PMS:服务器收到加密的 PMS 后,用自己的RSA 私钥解密,得到原始的 Pre-Master Secret。
- 计算主密钥(Master Secret):客户端和服务器分别使用相同的算法,结合以下三个参数计算 Master Secret:
plaintext
Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random)
其中,PRF
是伪随机函数(Pseudorandom Function),用于将输入转换为固定长度的密钥材料。 - 生成会话密钥:再用 Master Secret、Client Random、Server Random 通过 PRF 生成用于实际通信的对称密钥(如 AES 密钥、HMAC 密钥等),包括:
- 客户端加密密钥、服务器加密密钥(对称加密,用于数据加密)。
- 客户端 MAC 密钥、服务器 MAC 密钥(用于数据完整性校验)。
客户端验证握手完整性(Finished 消息)
- 客户端用生成的会话密钥,对之前握手过程中的所有消息(ClientHello 到 ClientKeyExchange)计算摘要(通过 MAC 算法),并加密后通过Finished 消息发送给服务器。
- 目的:证明客户端已正确生成会话密钥,且握手过程未被篡改。
TLS 第四次握手
服务器验证握手完整性并回应(Finished 消息)
- 服务器用自己生成的会话密钥,对相同的握手消息计算摘要,与客户端发送的 Finished 消息解密后的值对比,验证客户端是否正确生成密钥。
- 验证通过后,服务器同样生成Finished 消息(加密握手消息摘要)并发送给客户端,证明服务器也已正确生成密钥。
握手完成,开始加密通信
客户端和服务器均验证通过后,握手结束。后续所有通信数据均使用协商出的对称密钥进行加密和校验,确保机密性和完整性。