极客工场

Appearance

共 1,290 字预计阅读约 4 分钟

TLS 握手：怎么安全地商量出密钥 ​

更新时间：2026-09-17。网络协议域·安全。TLS 1.3 把这套流程压缩得更短，见 TLS 1.3；证书本身的验证见证书链与 PKI，握手性能见 HTTPS 性能。

HTTPS = HTTP over TLS。在发第一个 HTTP 请求前，TCP 之上先完成一次 TLS 握手，目标有三个：验证对方身份（通常是服务器）、协商出一个只有双方知道的会话密钥、并保证握手本身没被篡改。此后用对称加密高效传输。

一、核心思路：非对称协商，对称通信 ​

  • 非对称加密（公钥/私钥对）慢，适合小数据与身份/密钥协商。
  • 对称加密（一把共享密钥）快，适合大量应用数据。
  • TLS 结合两者：用非对称机制安全地就一个对称密钥达成一致，之后全部用对称加密。服务器公钥藏在证书里，由 CA 体系担保其真实性。

二、TLS 1.2 的经典握手（ECDHE，前向保密） ​

bash
客户端                                   服务端
  |-- ClientHello ----------------------->|  支持的TLS版本、客户端随机数、密码套件、SNI
  |<-- ServerHello -----------------------|  选定套件、服务端随机数
  |<-- Certificate -----------------------|  服务器证书链（含公钥）
  |<-- ServerKeyExchange (ECDHE 参数+签名)--|  临时EC参数，并用证书私钥签名
  |<-- ServerHelloDone -------------------|
  | （验证证书链/主机名/有效期）
  |-- ClientKeyExchange (ECDHE 参数) ----->|
  |-- ChangeCipherSpec, Finished -------->|  此后用协商出的密钥加密
  |<-- ChangeCipherSpec, Finished --------|
  |== 加密的应用数据（HTTP/1.1 或 HTTP/2）==|

两边各出一个随机数 + ECDHE 的临时公钥参数，各自用椭圆曲线 Diffie–Hellman 在本地算出同一个共享密钥（pre-master → session key）。窃听者即使抓全握手，也无法从公开的临时参数推出共享秘密（离散对数难题）。Finished 消息用新密钥加密并覆盖前面握手摘要，确保没人篡改过协商内容。

  • SNI（Server Name Indication）在 ClientHello 明文带上要访问的域名，让一台 IP/一张证书托管多个 HTTPS 站点（类似 HTTP 的 Host）。明文 SNI 的隐私问题由 ESNI/ECH 改进。
  • 完整约 2 个 RTT（在 TCP 握手之后），所以 HTTPS 比 HTTP 多 2~3 RTT 才能发请求——这是优化重点。

三、RSA 密钥交换 vs ECDHE：前向保密 ​

历史上更简单的做法是 RSA 密钥交换：客户端生成 pre-master，用服务器证书公钥加密发给服务端。它能保密但没有前向保密（PFS, Perfect Forward Secrecy）：

RSA 交换ECDHE/DHE
如何得到共享密钥客户端用服务器公钥加密后发送双方各出临时参数，本地算出
私钥泄露后，旧的被抓流量可被解密（用私钥解出 pre-master）仍安全（临时密钥用完即弃，私钥推不出）
前向保密❌✅
现状TLS 1.3 已移除主流推荐

ECDHE 的临时密钥每次握手重新生成、用完丢弃，即使将来服务器长期私钥泄露，也无法回溯解密历史会话——这就是前向保密。现代服务应只允许 ECDHE（如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这类套件）。

TLS 握手：非对称协商、对称通信

四、密码套件在协商什么 ​

如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256：

  • ECDHE：密钥交换算法（带前向保密）。
  • RSA：证书签名/身份认证算法。
  • AES_128_GCM：批量对称加密（GCM 同时提供机密性与完整性 AEAD）。
  • SHA256：PRF/握手摘要哈希。

协商原则：客户端给出支持列表，服务端按安全配置选择；禁用 RC4、3DES、CBC 模式下的老套件、SHA1 等。可用 [testssl/ssllabs] 或 openssl s_client -connect host:443 -tls1_2 检查协商结果。

五、服务器如何被验证 ​

客户端拿到 Certificate 后，沿证书链逐级验签到信任的根 CA，并检查：证书在有效期内、未被吊销（CRL/OCSP）、域名与 SAN 匹配（主机名校验）、签名合法。任一不通过则告警/中断（中间人攻击、自签名证书、证书过期都是这里失败）。

六、握手的代价与优化（详见 HTTPS 性能篇） ​

  • 每次新连接 2 RTT（TCP 1 + TLS 2，TLS 1.2），高 RTT 移动网络首访慢。
  • 优化方向：会话复用（Session ID/Session Ticket，恢复连接可 1-RTT 甚至 0-RTT）、会话票证、OCSP Stapling、HTTP/2 单连接复用、TLS 1.3（1-RTT/0-RTT），以及证书链与硬件（AES-NI）。见 HTTPS 性能与会话复用。

相关阅读 ​

TLS 1.3 缩短握手并强制前向保密，证书链与 PKI 讲身份信任，三次握手 是 TLS 的下层前提，HTTP/2 的 ALPN 在握手里协商。

总结 ​

TLS 握手在 TCP 之上先验证服务器证书（CA 链+主机名+有效期），再用非对称的 ECDHE/RSA 让双方安全协商出对称会话密钥，随后用对称 AEAD 加密通信并以 Finished 防篡改；ECDHE 相比 RSA 提供前向保密（长期私钥泄露也无法解密历史流量）应优先使用，代价是约 2-RTT 的建连延迟，由会话复用与 TLS 1.3 优化。