[!info] related notes

• 所属 MOC：计算机网络 MOC、HTTP 与前端网络请求 MOC
• HTTP：HTTP、HTTP vs HTTPS、HTTP/1.1 vs HTTP/2、HTTP/3
• 排障：TLS 握手失败排查、错误 IP 导致 TLS 失败

HTTPS

[!abstract] 一句话定义 HTTPS 是 HTTP 语义通过 TLS 安全信道传输。TLS 提供机密性、完整性和对端身份认证；它保护传输过程，但不会自动修复 XSS、SQL 注入、越权或业务逻辑漏洞。

分层模型

HTTP semantics
→ HTTP/1.1 or HTTP/2 over TLS over TCP

HTTP/3
→ HTTP over QUIC, with TLS 1.3 integrated into QUIC handshake

HTTPS 不是一套新的业务方法和状态码，主要变化是传输前先建立安全上下文。

TLS 握手解决三件事

1. 协商协议版本和密码套件；
2. 验证服务器身份；
3. 通过密钥交换推导会话密钥。

以现代 TLS 1.3 为主线：

ClientHello
  supported versions / key share / SNI / ALPN
        ↓
ServerHello
  selected parameters / key share
        ↓
Encrypted Extensions + Certificate + CertificateVerify
        ↓
Finished messages
        ↓
Application Data protected by symmetric keys

实际握手细节会随 TLS 版本、会话恢复、客户端证书和传输协议变化。不要把 TLS 1.2 中某一种 RSA 握手流程当成所有 HTTPS 的固定步骤。

为什么“非对称 + 对称”一起用

• 证书签名和握手用于证明身份；
• ECDHE / DHE 等密钥交换让双方推导共享密钥；
• 后续大量数据使用高效对称加密保护。

TLS 1.3 只使用具备前向保密的临时 Diffie-Hellman 类密钥交换，不再支持旧式静态 RSA Key Exchange。

证书链验证

Trusted Root CA
→ Intermediate CA
→ Server Certificate

客户端至少检查：

• 证书签名链能否到达可信根；
• 域名是否匹配 SAN；
• 当前时间是否在有效期内；
• Key Usage / Extended Key Usage 是否允许服务端认证；
• 算法和策略是否可接受；
• 必要时检查吊销或 Certificate Transparency 信息。

[!warning] 加密不等于身份可信 自签名证书也能建立加密，但客户端没有预先信任它时，无法确认对端就是目标服务。

SNI 与 ALPN

• SNI 告诉服务器客户端想访问哪个 Host，使一个 IP 可以托管多个证书/站点。
• ALPN 协商应用协议，例如 http/1.1、h2 或 h3。

普通 TLS 连接中的 SNI 可能暴露目标域名；ECH 旨在加密 ClientHello 中的敏感部分，但可用性取决于客户端、DNS 和服务端支持。

TLS 1.2 与 TLS 1.3

维度	TLS 1.2	TLS 1.3
完整新握手	通常更多往返	通常 1-RTT
密钥交换	多种组合，可能含静态 RSA	仅前向保密的 (EC)DHE 类
密码套件	历史组合复杂	大幅精简
握手加密	较多明文握手元数据	ServerHello 后更多内容加密
0-RTT	不支持	会话恢复可选，存在重放风险

Session Resumption 与 0-RTT

会话恢复减少重复握手成本。TLS 1.3 0-RTT 允许客户端在握手完成前发送 Early Data，但该数据可能被重放。

因此有副作用的请求不能仅因为“走 HTTPS”就假设 0-RTT 安全：

• GET 等只读请求更容易接受；
• 支付、创建、删除等操作需要拒绝 Early Data 或具备强幂等/防重放设计。

HSTS

服务器通过 HSTS 告诉浏览器在有效期内只使用 HTTPS：

Strict-Transport-Security: max-age=31536000; includeSubDomains

它减少 SSL Stripping 和用户误访问 HTTP 的风险。includeSubDomains 与 Preload 都需要谨慎，因为配置错误可能让整个域名体系长期不可访问。

HTTPS 仍然不能保护什么

• 终端已经被攻陷；
• 服务端本身泄露数据；
• 应用越权、XSS、SQL Injection；
• 用户把敏感信息发给错误但证书有效的网站；
• 流量大小、时间、目标 IP 等部分元数据；
• 业务请求被合法客户端重复提交。

常见握手失败

DNS points to wrong IP
certificate hostname mismatch
certificate expired / not yet valid
missing intermediate certificate
unsupported protocol / cipher
client clock wrong
SNI / ALPN / proxy misconfiguration
firewall or middlebox interference

调试命令

# 查看握手、证书链和 SNI
openssl s_client -connect example.com:443 -servername example.com -showcerts

# 查看证书主题、SAN、签发者和有效期
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# 查看 curl 的 DNS、连接、TLS、ALPN 和 HTTP 过程
curl -v https://example.com/

# 指定协议版本测试
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

排障顺序：DNS → TCP/QUIC → SNI/证书 → TLS 协商 → ALPN → HTTP。

学习检查

不看正文回答：

1. HTTPS 改变的是 HTTP 的应用语义，还是 HTTP 数据的传输保护方式？
2. TLS 握手至少要解决哪三件事？
3. 为什么现代 TLS 会把身份认证 / 密钥交换与后续对称加密分工处理？
4. 证书链、SAN、SNI、ALPN 分别解决什么问题？
5. TLS 1.3 相比 TLS 1.2 在握手和密码套件上有哪些关键变化？
6. 为什么 0-RTT 会带来重放风险，支付/删除类请求尤其需要谨慎？
7. HTTPS 已经建立成功时，为什么应用仍然可能存在 XSS、越权或业务漏洞？
8. 遇到 HTTPS 握手失败时，为什么排障顺序应从 DNS / 连接层开始，而不是直接猜证书？

掌握验收

• HTTPS 提供机密性、完整性和身份认证；
• TLS 握手的协商、证书验证与密钥交换；
• 非对称与对称加密的分工；
• TLS 1.2 与 1.3 的主要变化；
• 证书链、SAN、SNI 与 ALPN；
• Session Resumption 与 0-RTT 重放风险；
• HSTS 的作用和边界；
• 能用 OpenSSL / curl 分层定位失败。

Related notes

• 计算机网络 MOC
• HTTP
• TLS 握手失败排查