谈谈 HTTPS

Category（分类）: NET Protocol Status: 优

本文尽量保留原文的故事线和“对称密钥 → 非对称密码学 → 证书”的讲解方式，同时补充现代 TLS 1.3、ECDHE、X.509 证书和 HTTPS 的安全边界。

一、什么是 HTTPS

HTTPS 更准确的含义是：

HTTPS = HTTP over TLS

原文将 HTTPS 的全称解释为“Hyper Text Transfer Protocol over Secure Socket Layer”，这是 SSL 时代的历史说法。SSL 2.0 和 SSL 3.0 已经废弃，现代 HTTPS 主要使用 TLS 1.2 或 TLS 1.3，因此现在不应再把 HTTPS 简单描述成“HTTP 加 SSL”。

HTTPS 仍然使用 HTTP 的请求、响应和语义，只是在 HTTP 与传输层之间加入 TLS。TLS 负责握手认证、密钥协商、加密传输和完整性保护。

HTTPS 主要提供以下能力：

• 机密性：让网络中的旁观者不能直接读取 HTTP 应用数据；
• 完整性：发现应用数据在传输过程中是否被修改；
• 服务器身份认证：通过证书、信任链、域名匹配和握手签名验证服务器身份；
• 可选的客户端认证：在双向 TLS 等场景中验证客户端证书。

HTTPS 默认使用 443 端口，HTTP 默认使用 80 端口，但端口只是约定，HTTPS 也可以运行在其他端口。

二、HTTP 与 HTTPS 的区别

• HTTP 通常以明文传输，HTTPS 使用 TLS 保护 HTTP 应用数据；
• HTTP 通常使用 80 端口，HTTPS 通常使用 443 端口；
• HTTPS 通常需要有效的服务器证书，HTTP 不需要；
• HTTP 语义通常不保存跨请求的会话状态，但 TLS 连接本身包含握手状态、密钥和序列号等状态；
• HTTPS 可以认证服务器并保护传输过程，但不能保证网站业务本身可信，也不能代替应用层认证和授权。

证书不一定需要购买。Let’s Encrypt 等 CA 可以免费签发证书，不过证书具有有效期，申请、部署、续期和私钥保护都需要正确配置。

三、为什么要使用 HTTPS

前一段时间，公司要求全站使用 HTTPS。当时我还在想，HTTPS 不是只用于支付环节吗，为什么要全站都使用 HTTPS。实际上，只要网页或 API 中包含登录信息、Cookie、个人资料、搜索内容或其他隐私数据，就有使用 HTTPS 的必要。

使用 HTTPS 最主要的作用是：

• 建立一个具有机密性和完整性保护的信息通道；
• 验证访问域名对应的服务器身份，降低中间人攻击风险；
• 防止网络旁观者读取或篡改页面、脚本、请求和响应。

HTTPS 不能防止所有安全问题。例如服务器被入侵、客户端被恶意软件控制、用户安装了攻击者控制的根证书，或者应用存在 XSS、CSRF 和权限校验漏洞时，HTTPS 也不能替代其他安全措施。

四、HTTPS 原理：张大胖和 Bill 的故事

在搜索 HTTPS 时，经常会遇到应用层、传输层、TLS、证书、CA 等术语。下面仍然使用“来自中国的张大胖和位于米国的 Bill 进行通信”的故事来理解基本思想。

需要说明的是，故事中的“公钥加密对称密钥”是早期 TLS 资料常见的简化模型。现代 TLS 1.3 通常使用 ECDHE 密钥协商，而不是直接用服务器证书公钥加密最终会话密钥，后文会单独说明。

1. 总是有一种被偷看的感觉

由于张大胖和 Bill 使用 HTTP 进行通信，HTTP 应用数据通常是明文的，网络中的旁观者可能看到他们的聊天内容，也可能修改请求和响应。

所以 HTTPS 首先要解决的是：让传输中的应用数据不能被旁观者直接读取，并且能发现数据是否被篡改。

2. plan1：使用对称密钥

两人商量了一下，可以使用对称密钥进行加密。对称加密就是加密和解密使用同一个秘密密钥。

对称加密的优点是速度快，适合加密大量数据。AES-GCM、ChaCha20-Poly1305 等 AEAD 算法还可以同时提供机密性和完整性校验。

但是问题又来了：既然网络是不安全的，那么最开始的时候怎么把这个对称密钥安全地交给对方？如果密钥在发送时被攻击者拦截，攻击者就可能读取后续密文；如果攻击者还能够修改消息而不被发现，则会产生篡改问题。

因此，对称加密的主要难点不是加密速度，而是如何安全地协商或分发共享密钥。

3. plan2：使用非对称密码学

非对称密码学使用一对密钥：公钥和私钥。通常由服务器生成密钥对，服务器妥善保管私钥，公钥可以公开发布。

使用公钥加密、私钥解密，可以实现机密性：张大胖用 Bill 的公钥加密，只有持有对应私钥的 Bill 才能解密。

但“私钥加密、公钥解密”不应当作为普通加密流程。私钥生成签名、公钥验证签名，解决的是身份认证和完整性问题，而不是把消息当作秘密隐藏起来。

非对称密码学有以下问题：

• RSA、椭圆曲线等非对称运算通常比对称加密开销更大；
• 单独拥有一个公钥，并不能证明它确实属于 Bill；
• 如果攻击者把 Bill 的公钥替换成自己的公钥，张大胖仍可能把数据加密给攻击者；
• 现代 TLS 1.3 不再使用 RSA 进行密钥交换，而是通常使用 ECDHE；RSA、ECDSA 或 EdDSA 等密钥仍可能用于签名认证。

所以，非对称密码学既需要解决效率问题，也需要解决公钥身份绑定问题。

4. plan3：非对称密码学 + 对称加密

使用对称加密的好处是速度快，使用非对称密码学的好处是可以帮助完成身份认证和密钥协商。实际协议通常会结合两者：

1. 在握手阶段使用非对称密码学认证服务器并协商共享秘密；
2. 通过密钥派生算法生成双方使用的会话密钥；
3. 在后续通信中使用对称 AEAD 算法加密 HTTP 数据。

原文用“把钥匙放进保险柜，然后把保险柜寄给对方”来解释 RSA 密钥传输。这个比喻可以帮助理解历史上的 TLS 1.2 RSA 密钥交换：客户端生成 premaster secret，用服务器 RSA 公钥加密，服务器用私钥解密。

但 TLS 1.3 通常使用临时 ECDHE：双方交换临时公钥参数，各自计算相同的共享秘密，再使用 HKDF 派生会话密钥。最终的对称会话密钥不会直接通过服务器证书公钥传输，并且临时 ECDHE 可以提供前向保密。

五、中间人攻击

即使使用非对称密码学，首先仍然需要把 Bill 的公钥交给张大胖。如果公钥传输过程中没有身份认证，中间人就可以把 Bill 的公钥替换成自己的公钥。

这相当于张大胖想拨打 Bill 的电话，但中间人把 Bill 的号码替换成自己的号码。张大胖以为自己在和 Bill 通信，实际上连接的是中间人。中间人还可以分别与两边建立加密连接，从而读取和篡改双方通信。

因此，仅仅使用加密算法不能自动防止中间人攻击，客户端还必须验证公钥属于目标域名对应的服务器。

六、确认身份——数字证书

1. CA 和 X.509 证书

为了确认 Bill 给张大胖的公钥确实属于 Bill，需要一个双方信任的第三方机构。故事中可以把 CA（Certificate Authority，证书颁发机构）理解成负责核验身份并签发证书的机构。

CA 会根据证书申请和验证结果，签发 X.509 服务器证书。证书通常包含：

• 服务器公钥；
• Subject Alternative Name（SAN），例如域名或 IP 地址；
• 有效期；
• 证书序列号；
• 签发者信息；
• Key Usage 和 Extended Key Usage 等用途；
• CA 对待签名证书内容生成的数字签名。

数字证书不是简单的“原始信息 + 数字签名”，而是具有明确结构的 X.509 对象。CA 的签名覆盖待签名证书内容，修改域名、公钥或有效期等字段后，原签名就会验证失败。

2. 数字签名和证书验证

数字签名相当于公证机构在证书内容上盖章，但签名本身不负责隐藏证书内容。

客户端拿到服务器证书后，通常会：

1. 根据签发者构建证书链；
2. 使用上级 CA 公钥验证证书签名，而不是简单地“解密签名”；
3. 检查当前访问域名是否匹配 SAN 中的 dNSName；
4. 检查证书有效期、用途和安全算法；
5. 验证证书链是否连接到客户端信任库中的根证书；
6. 根据实现和策略检查 CRL、OCSP 或其他撤销信息。

现代域名验证应以 SAN 为准，不能依赖证书 Subject 的 Common Name（CN）。CA 验证域名控制权或组织信息的强度，也取决于证书类型；有证书不等于网站业务一定可靠。

七、现代 HTTPS 的 TLS 1.3 工作流程

上面的故事帮助我们理解了基本思想，但现代 HTTPS 不应简化成“客户端用证书公钥加密对称密钥”。典型的 TLS 1.3 服务器认证握手可以概括为：

客户端                                      服务端
  | -------- ClientHello + key_share ------> |
  | <------- ServerHello + key_share -------- |
  | <------- EncryptedExtensions ------------ |
  | <------- Certificate -------------------- |
  | <------- CertificateVerify -------------- |
  | <------- Finished ----------------------- |
  | -------- Finished ---------------------> |
  | <====== 加密的 HTTP Application Data ======> |

主要步骤如下：

1. 客户端发送 ClientHello，包含支持的 TLS 版本、密码套件、随机数和 ECDHE key_share；
2. 服务端发送 ServerHello，选择参数并提供自己的 ECDHE 公钥参数；
3. 双方根据临时密钥计算相同的 ECDHE 共享秘密；
4. 服务端发送证书链，客户端验证证书和域名；
5. 服务端通过 CertificateVerify 使用证书对应的私钥签署握手 transcript，证明自己确实持有私钥；
6. 双方通过 HKDF 从共享秘密派生握手密钥和应用数据密钥；
7. Finished 消息验证握手上下文没有被篡改；
8. 握手完成后，HTTP 请求和响应使用 TLS 记录层的 AEAD 算法加密和认证。

1. TLS 1.2 RSA 流程与 TLS 1.3 的关系

为了照顾旧资料，可以把“RSA 加密对称密钥”保留为历史知识：TLS 1.2 的某些密码套件使用 RSA 密钥传输，客户端生成 premaster secret 并使用服务器 RSA 公钥加密，服务器用私钥解密。

但这种方式不是现代 TLS 1.3 的默认流程，而且不具备理想的前向保密性。TLS 1.3 删除了 RSA 密钥交换，要求使用支持前向保密的密钥协商方式。

2. 0-RTT 和会话恢复

TLS 1.3 在会话恢复场景下可以使用 0-RTT 发送早期数据，从而减少等待时间，但 0-RTT 数据具有可重放风险。只有幂等、可安全重放的请求才适合使用 0-RTT；敏感的状态修改操作应等待正常握手完成。

3. TLS 保护的范围

TLS 主要保护客户端与 TLS 终止点之间的应用数据。如果 TLS 在 CDN 或负载均衡器处终止，那么从该设备到源站是否继续加密，需要根据部署方式单独配置。

TLS 也不会隐藏所有元数据。IP 地址、连接时间、流量大小和部分网络层信息可能仍然可见。

八、HTTPS 的实际使用建议

在实际项目中，除了部署证书，还应注意：

• 开启 HTTP 到 HTTPS 的安全重定向；
• 配置 HSTS 时评估域名和子域名的实际情况；
• Cookie 使用 Secure、HttpOnly 和合适的 SameSite 属性；
• 避免 HTTPS 页面加载 HTTP 的混合内容；
• 禁止使用过时的 SSL、TLS 1.0/1.1 和弱密码套件；
• 保护证书私钥，避免提交到代码仓库；
• 自动续期并监控证书过期时间；
• 在 CDN、负载均衡器和源站之间明确 TLS 终止和重新加密策略。

九、总结

HTTPS 的核心不是“把 HTTP 和 RSA 简单拼在一起”，而是由 TLS 提供一套完整的安全通信机制：

• 对称 AEAD 算法负责高效保护大量应用数据；
• ECDHE 等密钥协商机制帮助双方建立共享秘密；
• 数字签名证明私钥持有者参与了握手；
• X.509 证书和 CA 信任链把服务器身份与公钥绑定；
• TLS 1.3 通过 HKDF 派生握手密钥和应用数据密钥；
• 证书验证、域名匹配和信任库共同降低中间人攻击风险；
• HTTPS 保护传输过程，但不能替代应用层的认证、授权和安全开发。

参考资料

• RFC 8446：TLS 1.3
• RFC 5280：Internet X.509 Public Key Infrastructure
• RFC 9525：Service Identity in TLS
• TLS 1.3 更新版 RFC 9846
• Let’s Encrypt