TLS 握手与 HTTPS
复习
- 证书与信任链：证书把公钥与身份绑定
- 密钥交换：协商出共享的会话密钥
- 窃听与对称加密：对称加密保护传输内容
TL;DR
- HTTPS 就是 HTTP 加上 TLS，在网络之上加了一层安全
- TLS 握手先验证身份、再协商密钥
- 之后的数据用对称加密保护，兼顾安全与效率
- 它把认证、密钥协商和加密组装在了一起
正文
现在，密码学的积木都齐了：对称加密负责快，非对称负责解决分发，签名负责证明身份，密钥交换负责协商密钥，证书负责绑定身份。把它们组装起来，就得到了保护网页通信的 TLS（传输层安全协议）。
而 HTTPS，就是 HTTP over TLS：普通的 HTTP 之下，垫了一层 TLS。
握手：先认识，再说话
TLS 的握手（handshake）发生在正式传数据之前，大致做三件事：
- 验证身份：服务器出示证书，客户端顺着信任链验证，确认“你确实是我要找的网站”
- 协商密钥：双方通过密钥交换，商量出一把本次会话专属的对称密钥
- 确认参数：约定好使用哪种加密算法等细节
这三件事办完，一条安全的通道就算建好了。
之后用对称加密
握手结束后，真正的数据就开始传输了。注意：这些数据是用对称加密保护的，而不是非对称。
为什么？因为对称加密快得多。前面说过，非对称计算开销大，只适合用来做“协商”这种小量工作；真正的大批量数据传输，交给对称加密才划算。
于是 TLS 采取了漂亮的“混合加密”策略：
- 用非对称与证书，安全地解决“和谁协商、协商出什么”
- 用对称加密，高效地保护“之后所有的数据”
认证、密钥协商、加密，各司其职，组合成一套完整的安全方案。
把整个系列串起来看
HTTPS 一次访问，其实把我们这一部分学的东西几乎都用上了：
- 域名先经 DNS 解析成 IP
- 通过 TCP 建立可靠连接（还可能涉及 NAT、经过 CDN）
- 在连接之上做 TLS 握手，验证身份、协商密钥
- 再用 HTTP 交换请求与响应，数据由 TLS 加密保护
一层叠一层，各管一段。这正是整部教程反复强调的：复杂系统，靠分层与协作搭起来。
思考题 1
HTTPS 为什么先用非对称方式协商，再用对称方式传输数据？
思考题 2
TLS 握手一次，大致做了哪几件事？
小结
知识点
- HTTPS 是 HTTP 加上 TLS
- TLS 握手验证身份并协商密钥
- 传输数据用对称加密，兼顾安全与效率
- 它把认证、密钥协商与加密组装在一起
参考资料
- Wikipedia(zh)：传输层安全：为通信提供保密与认证的协议
- Wikipedia(zh)：超文本传输安全协议：HTTP 与 TLS 结合的安全网页协议
思考题答案（仅供参考）
思考题 1
因为非对称加密适合解决“安全协商与身份认证”，能安全地交换出一把会话密钥；但它速度慢，不适合传输大量数据。对称加密则很快，适合保护批量数据。两者配合，既安全又高效。
思考题 2
大致做了三件事：验证服务器身份（通过证书与信任链）、协商出本次会话的共享密钥（密钥交换）、确认双方使用的加密参数。完成后，双方即可用对称加密安全地传输数据。
协议
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
封面图
设计师 | 南国微雪