TLS 与证书链：握手、SNI、证书透明度与常见故障 —— 主题精读 未开始

题记与说明

主题形式研究条目（knowledge-h6n221ha-0）｜精读日期：2026-11-05
方法：先检索后精读 6 个来源（2 份 RFC 原文 + 1 份官方 CT 说明 + 3 篇工程实践文章），全部网络可达，并做了 3 组本机实测。无"基于已有知识"占位；凡非精读来源的内容（如后量子、ECH 部署现状）均显式标注为"搜索摘要/背景知识"。

来源清单与读法

另有一次仅到搜索摘要层级的核实（标注非精读）：RFC 9580 是 OpenPGP 不是 TLS（TLS 1.3 仍以 RFC 8446 为准）；RFC 10024（2025-03）为 TLS 1.3 定义 X25519MLKEM768 等混合后量子密钥交换，Cloudflare 称其混合 TLS 已覆盖约 70% 的浏览器流量（postquantum.com 分析）。

一、TLS 握手：从 TLS 1.2 的"90 年代密码学"到 1.3 的三阶段

1.1 为什么必须重做：TLS 1.2 的结构性缺陷

Cloudflare 文章的判断句（原文引述）：

"TLS was designed by engineers using tools from mathematicians. Many of the early design decisions from the days of SSL were made using heuristics and an incomplete understanding of how to design robust security protocols."

"TLS was 90s crypto: It meant well and seemed cool at the time, but the modern cryptographer's design palette has moved on."

四大结构性问题（均为该文原文论断）：

1. RSA 密钥交换不具前向保密："if someone records the encrypted conversation and then gets ahold of the RSA private key of the server, they can decrypt the conversation." 且 1998 年 Bleichenbacher 百万消息攻击持续作祟："major websites (including facebook.com) were also vulnerable to a variant of Bleichenbacher's attack called the ROBOT attack as recently as 2017." → TLS 1.3 删除 RSA 密钥交换，只留临时 Diffie-Hellman。
2. MAC-then-Encrypt + CBC + RC4："In TLS, they chose the latter, MAC-then-Encrypt, which turned out to be the wrong choice."（BEAST、Lucky 13、POODLE 皆源于此）→ 1.3 只允许 AEAD。
3. 签名不覆盖完整协商：1.2 的服务器签名只覆盖部分握手，密码套件协商靠对称 MAC 保护 → FREAK/LogJam 降级攻击。1.3 中 "the server signs the entire handshake, including the cipher negotiation"（RFC 8446 §2 原文定义：CertificateVerify = "A signature over the entire handshake using the private key corresponding to the public key in the Certificate message."，出自下载文本 §2/L715-717）。
4. DH 参数选择失控：LogJam/WeakDH（2015）"showed that many TLS servers could be tricked into using small numbers for Diffie-Hellman"。1.3 改为只接受已知安全组（X25519、P-256 等）。

1.2 握手本体：三阶段、1-RTT、key_share 前置

RFC 8446 §2 把握手拆为 Key Exchange / Server Parameters / Authentication 三阶段。完整流程图（原文 Figure 1 节选，下载文本 L570-602）：

Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

关键机制（RFC 8446 §2 原文）：

• "the ServerHello contains a 'key_share' extension with the server's ephemeral Diffie-Hellman share; the server's share MUST be in the same group as one of the client's shares."
• "All handshake messages after the ServerHello are now encrypted."（§1.2）
• 密钥协商前置到 ClientHello（客户端猜服务器支持的组、直接带 key share），把 1.2 的 2-RTT 压成 1-RTT。Cloudflare："Chrome's implementation of TLS 1.3, for example, sends an X25519 keyshare in the first message to the server." 猜错时服务器发 HelloRetryRequest 重启握手（§2.1 Figure 2），且 "the handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello."
• 协商模型从 1.2 的"密码套件大爆炸"（如 DHE-RC4-MD5、ECDHE-ECDSA-AES-GCM-SHA256）拆成三个正交维度："Cipher + HKDF Hash / Key Exchange / Signature Algorithm"。

本机实测（2026-11-05，与 cloudflare.com 真实握手）：

$ echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -brief
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=cloudflare.com
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits

一次握手同时验证了：1.3 单 RTT 生效、X25519 key share、ECDSA 证书签名、SNI 正确送达。

1.3 0-RTT：用重放风险换一个 RTT

0-RTT 依靠 PSK 恢复会话，客户端在第一飞就带上加密应用数据。RFC 8446 §2.3 有一段罕见的 IMPORTANT NOTE（原文逐字，下载文本 L1017-1031）：

"IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data. Specifically:
1. This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK.
2. There are no guarantees of non-replay between connections."

工程对策（Cloudflare 文）：

"If you increment a counter, perform a database transaction, or do anything that has a permanent effect, it's risky to put it in 0-RTT data." → "HTTP GET requests are supposed to be safe, so a browser can usually protect HTTPS servers against replay attacks by only sending GET requests in 0-RTT."

RFC 8446 §8 另给出服务器侧缓解（单次使用票据、CSRF 式令牌、"The simplest form of anti-replay defense is for the server to only..." 等，§8.1-8.3）与"客户端时间戳偏移即拒收"启发式。原则：0-RTT 只放幂等请求，服务端默认怀疑其新鲜性。

1.4 可部署性的代价：中间盒化石效应

"Even minor changes to the TLS 1.3 protocol that were visible on the wire (such as eliminating the redundant ChangeCipherSpec message, bumping the version from 0x0303 to 0x0304) ended up causing connection issues for some people." —— 为了兼容，1.3 线上格式被改得"像 TLS 1.2 会话恢复"。这是部署全世界最大加密协议时"化石效应（ossification）"的直接例证。

二、SNI：明文点名的必要之恶

2.1 它解决什么

RFC 6066 §3 开篇（原文）：

"TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting."

一台 IP 上挂多个 HTTPS 虚拟主机时，服务器必须在发送证书之前知道客户端要哪个域名。SNI（server_name 扩展）就是在 ClientHello 里"点名"。约束（RFC 6066 §3 原文）：

"In practice, current client implementations only send one name, and the client cannot necessarily find out which name the server selected." → "Multiple names of the same name_type are therefore now prohibited."

服务器不认识这个名字时的行为（RFC 6066 原文）：

"It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable."

2.2 TLS 1.3 里的地位与缺失后果

RFC 8446 §9.1（原文，下载文本 L5793-5799）：

"Additionally, all implementations MUST support the use of the 'server_name' extension with applications capable of using it. Servers MAY require clients to send a valid 'server_name' extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a 'server_name' extension by terminating the connection with a 'missing_extension' alert."

实践后果链：客户端不发 SNI（很老的库、某些代理/内网客户端）→ 服务器只能回默认站证书 → 主机名不匹配错误。反之，正确发 SNI 即可像上文实测那样正常选证书。

2.3 隐私缺口与 ECH

ClientHello（连同 SNI）在握手早期是明文的："the TLS ClientHello contains the SNI field in cleartext, so anyone on the path can see which website is being connected to"（security.stackexchange 讨论，搜索结果层级）。继任方案 Encrypted Client Hello（ECH） 把 ClientHello 整体加密、"closes the privacy gap that SNI opened"（yougetsignal 词条，搜索结果层级）。⚠️ 本笔记所精读来源未含 ECH 规范原文；其标准化状态（draft-ietf-tls-esni，浏览器陆续支持）为搜索摘要层级信息，未逐字核对。

三、证书链与验证：信任锚独立分发，服务器发"全链（除根）"

3.1 链规则（RFC 8446 §4.4.2 原文逐字）

"The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates."

"The server's certificate_list MUST always be non-empty."（服务器认证时）

"All certificates provided by the server MUST be signed by a signature algorithm advertised by the client if it is able to provide such a chain."

以及一条兼容性 Note（解释了为何烂配置仍常能过）：

"Prior to TLS 1.3, 'certificate_list' ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. ... For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first."

CT 官方说明补充了验证全景（Web PKI 视角）："A website then provides its certificate and those of its issuers as a 'certificate chain' to the user agent, which in turn uses them to verify that the website certificate is associated with one of these 'root certificates'... All of this is described in more detail in RFC 5280."

3.2 故障之王：链不完整（含本机复现）

Svix 文的定义：

"This happens when a server has a valid certificate, that's correctly signed by a trusted authority, but the server has no way of knowing that because it's missing some required intermediary certificates."

典型报错（Svix 原文示例）：error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed: ... unable to get local issuer certificate；curl 表现为 curl: (60) SSL certificate problem: unable to get local issuer certificate。

本机实测复现（2026-11-05，badssl.com 故障测试端点）——同一台服务器、同一分钟，两种客户端相反结果：

$ echo | openssl s_client -connect incomplete-chain.badssl.com:443 -brief
verify error:num=20:unable to get local issuer certificate
verify error:num=21:unable to verify the first certificate
Verification error: unable to verify the first certificate

$ curl -sS https://incomplete-chain.badssl.com/        # curl 8.15.0 (mingw) + Schannel 后端
HTTP 200，退出码 0

解读（据 curl 版本行 libcurl/8.15.0 ... Schannel 推断）：Windows Schannel 会走 AIA 自动补抓中间证书/系统缓存，而 OpenSSL 是严格链构建。这正是 Svix"But it works for me!"现象的活体演示：

"Web browsers usually cache intermediary certificates, so if an intermediary certificate has already been received before, the browser will happily use the cached version even with the incomplete chain and will just work."（macOS 有系统级缓存，Linux 没有，"so this will fail there"）

修法（Svix 原文）："Fix the configuration and make sure the server returns the full certificate chain in its TLS response excluding the root certificate." Certbot 用户应配 fullchain.pem 而非 cert.pem（Authgear 文，搜索摘要层级）。benjojo 也贴了同样的文件选择常识：

fullchain.pem # <- You want this
cert.pem      # <- You likely don't want this

3.3 浏览器的宽容是双刃剑（benjojo 的测量）

benjojo 文的两个机制与一组数据：

• Firefox："ship a large set of intermediate CAs into the browser that it will check whenever there is an incomplete TLS certificate chain."
• Chrome："Chrome will try to match intermediate certificates with what it is seen since the browser has been started. This has the effect of meaning that a cold start of Chrome does not behave the same way as a Chrome that has been running for 4 hours." → 排障噩梦："the admin administering the website would not be able to reproduce this problem"。
• 数据（Tranco 1M 扫描）："once you get past the 10,000 rank for domains you get around about 0.8% of domains that have misconfigured TLS certificate chains presented to clients." 彩蛋案例："playstation.com who sends their leaves certificate twice, bt.com, and a large number of government websites."
• AIA 扩展：浏览器在验证时按证书内嵌 URL 联网补抓链——"This is also mildly crazy as it requires your browser at TLS verification time to go and make additional network connections to validate the chain."（与当年 OCSP 被 Stapling 取代的理由同构：隐私与可靠性）
• 他的结论："I look at this particular mitigation and wonder if we really needed to do this when the error rate is around 0.8%."

四、证书透明度（CT）：把 CA 的每一次签发放进公共账本

4.1 动机与机制（certificate.transparency.dev 原文引述）

问题："A lack of transparency weakens the reliability and effectiveness of encrypted connections... they can enable a wide range of security attacks, such as website spoofing, server impersonation, and man-in-the-middle attacks."——CA 误签/被攻破的证书此前可以悄无声息地存在。

机制五步（全部为该文原文/直接转述，标注节名）：

1. append-only 日志："Certificate logs are append-only ledgers of certificates. Because they're distributed and independent, anyone can query them to see what certificates have been included and when."
2. 预证书破死锁：CA 先签 precertificate（"has a poison extension so that user agents won't accept it"），先拿 SCT 再签正式证书——解开"证书要先有 SCT 才能被记日志"的鸡生蛋问题。
3. SCT 与 MMD：日志返回 SCT，"This is a promise to add the certificate to the log within a time period called the Maximum Merge Delay (MMD)."（"The MMD is usually 24 hours"）
4. Merkle 树与 STH："In CT, leaves are the hashes of individual certificates that have been appended to the log. Nodes are the hashes of paired child leaves or paired child nodes." 日志签根哈希得 Signed Tree Head；"Certificates can only be added to a log, not deleted, modified, or retroactively inserted."
5. SCT 投递："CAs attach SCTs to a certificate using an X.509v3 extension."（最常见；另两种少见方式是 OCSP stapling 与 TLS extension）"CT doesn't require server modification."

4.2 执行者与监督者

• 浏览器强制："Both Safari and Chrome user agents require at least 2 SCTs, depending on certificate lifetimes."——把"公开可审计"从自愿变成事实准入门槛。
• 监控者（Monitors）："Monitors cryptographically check which certificates have been included in logs."（一致性证明 + 存在性证明："it computes an audit proof itself and use it to verify the presence of that certificate."）域名主可订阅监控，发现未授权签发。
• 版本现状：RFC 6962（v1）与 RFC 9162（v2）并存，但据 MDN 内容仓库讨论（搜索摘要层级），现实中的日志与消费方仍实现 RFC 6962。

4.3 防御者用法（实践层）

CT 让"谁给我的域名签过证书"变成可查询的公开数据（如 crt.sh 之类的日志检索界面——此条为背景知识，非精读来源内容）。对个人/团队的最小动作：为自有域名订阅 CT 监控，把"陌生证书出现"当作入侵/仿冒的前置告警；CTI Academy 也把它列为发现仿冒钓鱼域的常规手段（来源，搜索摘要层级）。

五、常见故障速查（现象 → 根因 → 修法）

排障命令组（本笔记实测过的为准）：

openssl s_client -connect host:443 -servername host -brief           # 协议/套件/SNI/验证结果
openssl s_client -connect host:443 -servername host -showcerts       # 打印整条链，检查中间证书与顺序
openssl s_client -connect host:443 -verify_hostname host             # 主机名专项
curl -v https://host/                                                # 看实际协商版本与证书信息（注意后端是 Schannel 还是 OpenSSL）

六、七维提取（主题级）

七、原文引述索引（精读来源逐条）

1. RFC 8446：Abstract/§1.2/§2/§2.1 Figure 2/§2.2 Figure 1/§2.3 IMPORTANT NOTE/§4.4.2/§9.1——见 §1.2、§1.3、§2.2、§3.1 引述块；全文 https://www.rfc-editor.org/rfc/rfc8446（本组下载副本 /tmp/tls-note/rfc8446.txt，8963 行）。
2. Cloudflare RFC 8446 深读——见 §1.1、§1.3、§1.4 引述块；https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
3. RFC 6066 §3——见 §2.1 引述块；https://www.rfc-editor.org/rfc/rfc6066
4. How CT Works——见 §4.1、§4.2 引述块；https://certificate.transparency.dev/howctworks/
5. Svix 链不完整——见 §3.2 引述块；https://www.svix.com/blog/ssl-tls-incomplete-certificate-chain/
6. benjojo 浏览器宽容测量——见 §3.3 引述块；https://blog.benjojo.co.uk/post/browsers-biggest-tls-mistake

附：本组执行的实测命令与结果

# 1) 真实 TLS 1.3 握手 + SNI（成功）
$ echo | openssl s_client -connect cloudflare.com:443 -servername cloudflare.com -brief
→ TLSv1.3 / TLS_AES_256_GCM_SHA384 / CN=cloudflare.com / ECDSA / Verification: OK / X25519

# 2) 链不完整端点（OpenSSL 严格验证：失败）
$ echo | openssl s_client -connect incomplete-chain.badssl.com:443 -brief
→ verify error num=20/21: unable to get local issuer certificate
   Verification error: unable to verify the first certificate

# 3) 同一端点（curl 8.15.0 mingw + Schannel 后端：成功）
$ curl -sS https://incomplete-chain.badssl.com/ -o /dev/null -w "%{http_code}"
→ 200, exit 0

# 4) RFC 全文取证
$ curl -sS https://www.rfc-editor.org/rfc/rfc8446.txt   # 8963 行，grep/sed 逐节取句