TLS 1.3 握手、记录层与证书验证

• TLS 1.3 握手消息的完整顺序与单次往返（1-RTT）结构
• 每条消息由哪个阶段密钥（early / handshake / application traffic secret）保护
• ClientHello 与 Finished 在不同阶段明文/密文的差异

完整握手流程为：客户端发送 ClientHello（明文，携带 key_share、supported_versions、signature_algorithms 等扩展，其后可选附加的 early 数据）；服务器依次发送 ServerHello（明文，随后的消息用 handshake 密钥加密）、EncryptedExtensions（HKDF 派生的 Client/Server Handshake Traffic Secret 加密）、Certificate（同样用 handshake traffic secret 加密）、CertificateVerify（对 transcript 签名，用 server handshake traffic secret 加密）、Finished（握手最后一条保护消息，用 handshake traffic secret 加密）；客户端随后发送 Finished（用 client handshake traffic secret 加密）。两条 Finished 之后双方才切换为 application traffic secret 加密应用数据。关键在于：ServerHello 之后的全部服务器握手消息都立即被 handshake 密钥保护，而 ClientHello 必须在服务器看到它之前无法加密，因此只能明文。

加密时机由密钥派生进度决定——消息在派生出对应 traffic secret 之后才被加密。ServerHello 一经发送，双方即可用 HKDF 从 ECDHE 共享密钥与 transcript 派生出 handshake secret，因此其后的消息全部加密。Finished 使用 handshake key 而非 application key，因为它本身是握手认证的一部分，需要先完成对握手 transcript 的校验。1-RTT 意味着只需一次往返（ClientHello 与 ServerHello 之间的往返）即可完成握手。

• 静态 RSA 密钥交换缺乏前向保密（PFS）的缺陷
• 密码套件协商与老式 CBC/RC4 组合带来的配置复杂度与攻击面
• 压缩导致的 CRIME 类侧信道攻击

TLS 1.3 移除了静态 RSA 密钥交换，因为它无法提供前向保密：RSA 私钥一旦被服务器保留，历史会话所有流量都能被解密，且其 PKCS#1 v1.5 padding 曾引发 Bleichenbacher 类 padding oracle 攻击。移除密码套件协商（cipher suite negotiation）是因为 1.2 中套件把密钥交换、认证、加密、MAC 组合成大量排列，导致配置混乱、互操作困难；1.3 将密钥交换与认证分离为独立扩展，密码套件只表达 AEAD 加密算法与 hash 函数。压缩被移除是因为 CRIME 攻击可利用压缩前后长度差异泄露 Cookie 等机密。仅保留 AEAD 模式（AES-GCM、ChaCha20-Poly1305 等 5 个强制套件）是因为 AEAD 在单一算法中同时提供机密性与完整性，消除了 CBC 模式下 MAC-then-Encrypt 的 padding oracle 与 IV 复用等历史问题，大幅收窄攻击面。

设计哲学是"握手中只保留经过验证的最简安全原语"。密钥协议用 ECDHE（可扩展至后量子），认证用签名，加密用 AEAD，三者正交，避免组合爆炸。这使协议实现更简单、更安全、更易维护。

• key_share：客户端预先生成的 ECDHE 公钥，支持 0-RTT 与 1-RTT
• signature_algorithms：客户端可接受的证书签名算法
• supported_versions：客户端支持的 TLS 版本，配合降级防护

key_share 携带客户端预生成的 (EC)DHE 公钥（如 X25519），使服务器无需额外往返即可派生出共享密钥，是 1-RTT 和 0-RTT 握手的关键；若服务器支持的组不在其中，会返回 HelloRetryRequest 让客户端重发。signature_algorithms 声明客户端认可的证书签名算法（如 ECDSA P-256、RSA-PSS），服务器据此选择证书并签名 CertificateVerify，避免协商出弱算法。supported_versions 声明客户端支持的协议版本列表，服务器选择最高共同版本，并借 downgrade sentinel 字段检测降级攻击。psk_key_exchange_modes 声明客户端是否接受纯 PSK（psk_ke）或 PSK+ECDHE（psk_dhe_ke）协同模式，后者提供前向保密，服务器据此决定是否可复用 PSK。

这四个扩展把 TLS 1.2 中打包在 cipher suite 里的职责拆分成独立、可独立协商的维度，从而让客户端在第一条消息中就尽可能传递完整能力，减少往返。

• Certificate Compression 扩展（certificate_compression_algorithms）
• 压缩算法协商（如 zlib、brotli、zstd）
• 压缩对象与防 CRIME 考量

RFC 8879 通过 ClientHello 中的 certificate_compression_algorithms 扩展，客户端声明它支持的压缩算法列表（如 zlib、brotli、zstd）。服务器在 Certificate 消息时若采用压缩，则选择客户端支持的一种算法，对完整证书链内容进行压缩（压缩对象是证书链本身，且压缩发生在握手阶段，作用于待发送的证书链数据），并在消息中携带算法标识。压缩能显著减小根证书链（有时数百 KB）的传输体积，从而减少握手包数与首字节延迟，尤其在证书链较长、带宽受限的移动网络下收益明显。同时，由于证书内容非敏感数据且压缩发生于握手阶段，CRIME 风险可控。

本质是"压缩对象是证书链而非用户可控的机密输入"，因此不引入 CRIME 类泄露。协商通过扩展完成，客户端不支持时服务器回退到明文证书，保持兼容。

• 记录层最大明文 2^14 + 1 字节（16384+1）限制
• 分片（fragmentation）与重组
• 大握手消息（Certificate）与证书压缩的协同

TLS 记录层将明文数据切分为不超过 2^14+1 字节（约 16384 字节）的片段，每个片段独立加封成记录（含 AEAD 标签与序列号）。大握手消息（如长达数十 KB 的证书链）会被拆成多条握手记录发送，接收端按握手消息头重组；大应用数据（如上传）同样被分片，便于加密、流式处理与错误隔离。超长记录会被拒绝，且实现可能限制记录大小。分片带来的影响是：超长证书会因分成多条记录而增加握手包数，因此在移动网络下证书压缩（RFC 8879）能减少包数；而应用数据分片则有利于增量加密与内存控制，但单条记录过大也可能造成接收缓冲压力。

记录层分片是"为安全与可处理性而设的硬上限"，它把加密单元与上层消息解耦，使每个记录独立加密、可独立重传与校验，是大消息传输的基本抓手。

• AEAD 已涵盖 MAC 功能，无需独立 MAC 算法
• SHA256 作为 HKDF 的 hash 函数用于密钥派生
• 命名中 hash 部分与加密算法解耦

在 TLS 1.3 中，由于只使用 AEAD 模式（GCM、ChaCha20-Poly1305），认证（完整性）由 AEAD 的认证标签完成，不再需要独立的 MAC 算法。命名中的 SHA256 因此只扮演 HKDF 的 hash 函数角色，用于 HMAC-HKDF-Extract 与 HKDF-Expand 派生各阶段密钥（如 handshake secret、traffic secret）。套件名把"AEAD 加密算法"与"HKDF hash"并列，二者记录的是协议的两种不同原语：前者确定数据加密，后者确定密钥派生参数。这样实现可精确知道用哪个 hash 计算 HKDF 与 transcript hash，而不含 MAC 语义。

这是协议简化的体现——MAC 与加密合并为 AEAD，hash 独立承担密钥派生与 transcript 摘要，避免 TLS 1.2 中加密算法与 MAC 算法任意组合带来的歧义。

• Finished 使用 traffic key 的 HMAC 而非 AEAD
• Finished 在密钥切换前验证握手完整性
• Finished 由 handshake traffic secret 派生出 verify_data

TLS 1.3 的 Finished 消息内容是一个 verify_data，它是用当前握手方向的 traffic key（即 client/server handshake traffic secret）对完整握手 transcript 计算 HMAC 得到的摘要。原因在于 Finished 既要验证握手完整性，又要作为"再握手密钥"的输入，它本身是握手最后一条用 handshake key 保护的消息，随后双方才切换到 application traffic secret。若用 AEAD 加密，则需要在 Finished 中携带额外密钥派生信息，且 AEAD 标签验证与 transcript 绑定的语义不如 HMAC 直观；HMAC 直接绑定 transcript 与方向密钥，语义清晰、可独立验证，且便于后续从 Finished 消息派生 resumption master secret。

Finished 的 HMAC 本质是"握手 transcript 的认证器"，它把之前所有握手消息（含公钥、扩展、证书）绑定到密钥，防止中间人篡改；HMAC 而非 AEAD 使其作为纯摘要可被独立使用（如派生 resumption_secret）。

• key schedule 的 Extract/Expand 与 Label 区分
• transcript hash 把每阶段密钥绑定到握手上下文
• 防止密钥重用导致的跨阶段攻击

TLS 1.3 的 key schedule 由 HKDF-Extract 与 HKDF-Expand（带不同 Label）组成，每个阶段秘密（Early Secret、Handshake Secret、Master Secret）都通过 derive_secret 从上一阶段秘密与当前 transcript hash 派生。derive_secret 把 Label（如 "derived"、"c hs traffic"、"s hs traffic"、"c ap traffic"、"res master"）作为 HKDF-Expand 的 info 参数，使不同用途的密钥互不相同；而 transcript hash 把密钥绑定到确切的握手消息序列，任何消息变化（如不同扩展、不同证书）都会改变派生结果。这样即使两个连接共享相同 PSK 或 ECDHE 输入，也会因 transcript 不同而派生不同密钥，从而避免跨会话、跨阶段的密钥重用。

"Label + transcript hash" 的组合是密钥分域的关键范式：Label 区分同一阶段内不同用途（收发方向、early/handshake/app），transcript 区分不同连接与不同阶段，实现"一密钥一上下文"。

• master secret 在 TLS 1.2 中默认只依赖 ClientHello.random 与 ServerHello.random
• session resumption 复用时密钥不绑定 transcript 的交叉泄露风险
• 防止 master secret 被重放到不同会话

在标准 TLS 1.2 中，master secret 由 ClientHello.random 与 ServerHello.random 结合 premaster secret 派生，而会话恢复会使新会话的 master secret 只依赖两个 random 值，不绑定完整握手 transcript。RFC 7627 通过在 ClientHello 中协商 extended_master_secret 扩展，使 master secret 的派生输入中额外加入完整握手 transcript 的 hash，从而把 master secret 绑定到具体握手上下文。这防止了"馈送攻击"（一个被滥用的凭证把某个连接的 master secret 重放到另一个会话/证书）以及 session resumption 复用被篡改的 master secret 的问题。

核心是"密钥必须绑定到它参与验证的 transcript"，否则同样的 premaster 可在不同上下文被重用，破坏握手的完整性绑定与认证隔离。

• early_data 重放风险的本质
• single-use ticket 使每次恢复使用一次性 PSK
• max_early_data_size 限制 0-RTT 数据量

0-RTT 数据在客户端首次连接时随 ClientHello 提前发送，攻击者可复制并重放这段密文，因此天然存在重放风险。为缓解，服务端签发 NewSessionTicket 时使用 single-use 语义：ticket 内的 PSK 只允许成功恢复一次，重放时服务端因 ticket 已被使用而拒绝或仅允许幂等操作。同时服务端在 NewSessionTicket 中通过 max_early_data_size 字段声明允许的 early data 上限，客户端据此限制 max_early_data_size 的上限，避免一次重放携带过多数据。服务端通常还会维护以 client_random 或加密 nonce 为键的 anti-replay 缓存，检测重复的 early 数据并丢弃。

single-use 限制的是"哪个 PSK 可被复用"，max_sent 限制的是"一次重放影响的量"，两者共同把重放从"任意数据"压缩为"一次性、有界、建议幂等"的场景，剩余风险交由应用层幂等处理。

• ECH 的 outer/inner ClientHello 双层结构
• public_name 与共享 ECH 密钥加密 inner
• 隐藏 SNI 与证书访问

ECH 将 ClientHello 拆分为 outer 与 inner 两层：outer ClientHello 是明文的、可公开部分，包含 public_name（一个公开的假名 hostname，如 CDN 的公共域名）与用于加密 inner 的 ECH 配置；inner ClientHello 才是真实内容，包含真实的 SNI、ALPN、key_share 等，使用 ECH 配置中分发的公钥加密后嵌入 outer 的 encrypted_client_hello 字段。任何能解析 ECH 配置（即持有对应公钥）的服务器都能解密 inner 得到真实 SNI，而中间人只能看到 outer 的 public_name，无法得知真实目标域名，从而隐藏 SNI 以防止基于 SNI 的流量审查与指纹。

ECH 的本质是"把敏感的能力协商字段藏进可加密的 inner 层"，公开层只暴露无差别的 public_name，使网络观察者无法区分访问的不同后端，达到与 ESNI 一致但更强的隐私目标。

• 客户端预生成 key_share 消除 1.2 的 2-RTT
• 合并消息、减少握手步骤
• 0-RTT 基于 PSK 恢复的前提

TLS 1.2 的完整握手需要 2-RTT（客户端与服务器各一次往返），因为服务器要先选择密钥组，客户端再发送其公钥。TLS 1.3 让客户端在 ClientHello 中预先生成并附带 key_share（ECDHE 公钥），服务器拿到后立即能派生共享密钥，从而把完整握手压缩为 1-RTT，并省略了 1.2 中 ChangeCipherSpec 等冗余消息。0-RTT 更进一步：在客户端已持有有效 PSK（来自之前会话的 NewSessionTicket 或外部 PSK）的前提下，客户端可在第一条 ClientHello 之后立即发送用 early traffic secret 加密的应用数据，从而把"首次数据传输"提前到 0-RTT。前提是：客户端已建立过会话并缓存 PSK，且 psk_key_exchange_modes 支持 psk_ke/psk_dhe_ke，同时服务端允许 early data。

1-RTT 靠"预先分享公钥"实现，0-RTT 靠"预先分享 PSK"实现。两者都是"把协商所需信息提前到第一条消息"，以牺牲部分安全性（PFS、重放）换取延迟收益。

• ECDHE 的一次性临时密钥与 PFS
• 静态 RSA 私钥长期保留导致历史流量可解密
• 静态 RSA 的 padding oracle 风险

(EC)DHE 每次握手都生成一次性临时私钥（ephemeral），会话密钥由双方临时私钥与对方临时公钥通过 DH 计算得出，私钥在握手结束后即可丢弃。因此即使服务器长期私钥（证书私钥）泄露，攻击者也无法回溯解密历史会话的密钥，这就是前向保密（PFS）。静态 RSA 密钥交换则是把 premaster secret 用服务器证书的 RSA 公钥加密后发送，服务器用长期私钥解密；一旦长期私钥泄露，所有历史流量全能解密，无 PFS。此外静态 RSA 的 PKCS#1 v1.5 padding 在解密失败时泄露信息，引发 Bleichenbacher 攻击，因此 TLS 1.3 彻底移除静态 RSA 密钥交换，强制使用 ECDHE。

PFS 的本质是"用来加密数据的密钥与长期认证密钥分离"。ECDHE 用临时密钥做数据加密，长期密钥只做签名认证，泄露长期密钥不影响历史数据；静态 RSA 则把两者耦合，故被废弃。

• 0-RTT 数据在握手完成前已发送，无随机性绑定
• 攻击者可复制重放同一密文
• 幂等性要求：仅执行无副作用或可重复的安全操作

0-RTT 数据在客户端首次发送时即用 early traffic secret 加密，该密钥在客户端与服务端建立连接前就已确定，且不包含用于防重放的新随机协商值。攻击者可截获这段密文并完整重放给服务端，服务端无法通过密钥机制区分，因此 0-RTT 天然存在重放风险。为安全使用，应用层必须保证可重放的数据操作是幂等的：即同样操作执行一次与多次结果一致，且无副作用（如只读查询、非破坏性写入、幂等键控制的请求）。涉及状态变更、扣款、下单等非幂等操作绝不应放在 0-RTT 中，应改为 1-RTT 以保证安全。

0-RTT 的权衡是"用安全换取延迟"。协议层只能通过 single-use ticket、anti-replay 缓存限制重放面，真正的语义安全必须由应用层通过幂等处理来兜底。

• AEAD 单一机制提供机密性与完整性
• CBC/RC4 的历史攻击（padding oracle、BEAST）
• 压缩移除消除 CRIME

TLS 1.3 只保留 AEAD 类套件（AES-GCM、ChaCha20-Poly1305），因为 AEAD 在单一步骤中同时提供机密性与认证，不存在 CBC 模式下"加密与认证分离"导致的 padding oracle（BEAST、Lucky13）、MAC 顺序错误（MAC-then-Encrypt）等问题，也移除了 RC4 这类弱流密码。压缩机制因 CRIME 攻击（利用压缩后长度变化泄露机密）被移除。攻击面收窄体现在：不再有可被错误配置选中的弱套件组合、不再有 CBC 填充与压缩侧信道、密钥更新与 nonce 管理更严格，从而实现"更少可被攻击的选项"。这使实现更简单、审计更易，历史漏洞类别（Bleichenbacher、BEAST、CRIME、Lucky13）被结构性消除。

"收窄攻击面"的核心策略是"去除冗余与可组合的弱原语，只保留经实践验证的 AEAD 原语 + HKDF + ECDHE"。协议选项越少，出错概率与可利用面越小。

• TLS 1.2 中证书、Finished 等明文可见
• TLS 1.3 用 handshake traffic secret 加密
• 隐藏的元数据：证书、扩展、指纹

TLS 1.2 在 ChangeCipherSpec 之前，Certificate、Finished 等握手消息均明文传输，中间人可观察证书链、扩展、指纹等元数据。TLS 1.3 移除了 ChangeCipherSpec（仅保留兼容性空消息），从 ServerHello 之后立即用 handshake traffic secret 加密所有服务器握手消息，客户端 Finished 也加密。这隐藏了：具体使用的证书链（防止基于证书的指纹识别）、支持/选择的扩展细节、握手指纹（client/server hello 其余部分）、以及部分密钥协商信息。攻击者无法通过旁路观察证书与扩展来对服务器或客户端做版本、算法、站点指纹，增强了隐私与抗审查能力。

从 ServerHello 起加密是"能加密就加密"原则的体现——一旦 ECDHE 共享密钥就绪，后续所有消息立即加密，把握手元数据从网络可见面中移除。

• supported_versions 完成版本协商与降级防护
• key_share 提供 ECDHE 密钥材料
• Finished 用 HMAC 认证握手 transcript

supported_versions 扩展让客户端声明支持的版本列表，服务器选择最高共同版本并回送 ServerHello.version，完成版本协商；若服务器检测到降级（客户端请求 1.3 但 ServerHello 回 1.2），会写入特定降级 sentinel 值，客户端据此发现降级攻击。key_share 携带客户端 ECDHE 公钥，服务器选择并返回自己的 key_share，双方据此派生共享密钥，进而派生出 handshake traffic secret。Finished 由该 handshake traffic secret 对完整握手 transcript 计算 HMAC，客户端用服务器 Finished 验证服务器确实拥有私钥并完整接收握手，服务器用客户端 Finished 做同样验证，从而完成双向握手认证（配合 CertificateVerify 的签名认证）。

三者的分工是：supported_versions 决定"用什么协议的密钥派生规则"，key_share 提供"密钥材料"，Finished 提供"认证与完整性"——三个环节缺一不可，共同构成一次可信的握手。

• 0-RTT 缺少防重放的新随机性
• 服务端 anti-replay 缓存
• 限制可放入 0-RTT 的操作类型

0-RTT 数据在握手完成前就已发送，其密钥在客户端与服务端之间已事先确定，不依赖本次握手新生成的随机数来绑定防重放，因此攻击者可复制截获的密文并原样重放给服务端，服务端无法仅凭密钥区分真伪。服务端应通过 anti-replay 缓存（记录 client_random 或 early 数据 nonce）检测重复，并将 0-RTT 限流；同时应限制可提前执行的业务操作，只允许幂等、无副作用或可安全去重的请求（如只读查询、缓存预热、幂等键控制的写入），涉及状态变更、支付、下单等操作必须推迟到 1-RTT 连接建立后执行，避免重放造成重复扣款或重复提交。

这是"协议层限制重放面 + 应用层语义幂等"的双层防护。0-RTT 适合"可重试、可重放无害"的请求，不适合任何有副作用的操作。

• RSA 密钥交换无 PFS 的本质
• RSA 私钥长期持有导致历史流量可解密
• TLS 1.3 强制 ECDHE 实现 PFS

TLS 1.2 的 RSA 密钥交换把 premaster secret 用服务器证书公钥加密，服务器用长期 RSA 私钥解密。由于长期私钥需要长期保存，一旦泄露，攻击者可解密所有用该私钥保护的历史会话流量，无法提供前向保密。同时 RSA 的 PKCS#1 v1.5 padding 存在 Bleichenbacher 类 padding oracle 风险。TLS 1.3 因此彻底移除 RSA 密钥交换，强制使用 ECDHE 临时密钥交换：每次握手生成一次性临时私钥，会话密钥只由临时密钥派生，长期私钥仅用于签名认证，即使泄露也只能伪造而不影响历史会话解密，从而把 PFS 作为强制要求，保证"过去的安全不被未来的泄露破坏"。

PFS 成为强制，是因为"证书私钥可能随时泄露"应作为默认威胁模型。密钥交换只用临时密钥、认证只靠长期私钥签名，二者分离是实现 PFS 的工程范式。

• HSTS 头只能保护已访问过的站点
• HSTS preload 名单的全局域名列表
• preload 名单的提交与更新机制

HSTS 头（Strict-Transport-Security）只在浏览器收到该响应头后生效，因此对从未访问过的站点，首次访问仍走 HTTP，存在被劫持降级为 HTTP 的风险。HSTS preload 名单（如 Chrome 的 hsts-preload 名单）由浏览器维护的全局域名列表，把已列出的域名强制使用 HTTPS，覆盖首次访问。申请方式：站点需满足 HSTS 头包含 preload 指令且 max-age 足够长（通常 ≥31536000 秒）、includeSubDomains 等条件，然后向 hstspreload.org 提交，经审核后合并进 Chromium 的 preload 分发。更新机制是浏览器版本更新时随版本分发新名单，不能即时生效，因此撤回 preload 需要较长时间（因为浏览器必须等旧版本过期）。

preload 的代价是"难以撤销"与"全局生效"，因此申请条件严格。它解决的是"首次访问无 HSTS 保护"的窗口，但更新依赖浏览器版本迭代，实时性差。

• HTTP-01：通过在 80 端口提供 token 文件验证域名控制
• DNS-01：通过 TXT 记录验证，支持通配符
• TLS-ALPN-01：通过 443 端口 ALPN 验证

HTTP-01 挑战要求 CA 能通过 HTTP 访问 http://domain/.well-known/acme-challenge/token，因此服务器必须直接可写该路径，适用于直连服务器、无 CDN 前置或能对 CDN 配置回源的情况；但对 CDN 后置站点，若 CDN 无法转发该路径或证书由 CDN 托管，则不可行。DNS-01 挑战要求域名的 DNS TXT 记录 _acme-challenge.<domain> 能被 CA 验证，不依赖服务器端口与拓扑，因此支持通配符（*.example.com），也适用于 CDN 后置——只要用户能控制 DNS 且 CA 能查询。TLS-ALPN-01 挑战通过 443 端口 TLS 握手中的 ALPN 扩展 acme-tls/1 提供 token，要求服务器能处理该 TLS 会话，适用于支持此回应的服务器，但同样受端口/网络可达性限制。因此：通配符证书必须用 DNS-01；CDN 后置且无法控制服务器路径时优先 DNS-01（或 CDN 支持的 ACME 集成）。

选择的核心是"谁控制验证所需资源"。DNS-01 通过 DNS 控制权验证，最通用且支持通配符；HTTP-01 与 TLS-ALPN-01 依赖服务器可达性与端口，受 CDN 与拓扑限制。

• 根证书信任锚的安装与分发
• 域内 GPO 推送 vs 独立设备管理
• 中间证书链随非叶子节点分发

私有 PKI 签发的证书由企业根 CA 签发，客户端必须信任该根证书才能验证链。同步方式包括：域环境下通过组策略（GPO）自动将根证书推送到所有域成员（AD CS 的证书模板与自动注册），配合 Active Directory 证书注册点；非域环境（Linux、移动设备、容器）则通过 MDM/EMM、配置管理（Ansible、SaltStack、Puppet）或部署时把根证书写入系统信任库（如 /etc/ssl/certs、Windows 证书存储、Java truststore）。跨域场景还需确保中间证书链随服务器分发（Leaf 服务器需提供完整链到根），并保证客户端信任根即信任链。Vault PKI 与 CFSSL 可配置签发中间 CA 并搭配信任根分发，同时用短期证书与自动续期减少根泄露风险。

根证书是信任锚，必须"安全、一致、可撤销"地分发到每个客户端。域内用 GPO 自动分发最可靠，跨域/混合环境用配置管理与信任库注入，并配合证书生命周期管理。

• CRL DP：X.509 扩展，指向证书撤销列表
• OCSP responder URL：Authority Information Access 扩展
• 在线 vs 离线撤销检查、缓存与失效时间

CRL 分发点（CRL DP）位于证书的 CRLDistributionPoints 扩展中，指向存放撤销列表（CRL）的 URL，客户端可下载 CRL 离线判断证书是否被撤销；OCSP responder URL 位于 Authority Information Access（AIA）扩展中，指向 OCSP 响应服务器，客户端在线查询单张证书的撤销状态。CRL 是"批量、离线"（可缓存、可镜像），撤销可见性有延迟（直到下次 CRL 发布）；OCSP 是"在线、单张"但响应延迟高、有隐私与可用性（responder 不可用）问题。协同策略：优先使用 OCSP stapling（服务器把 OCSP 响应随握手送出）保证时效与减少延迟，服务器应缓存并更新 OCSP 响应；OCSP 不可用时回退到 CRL 缓存；CRL 可配置较短的 nextUpdate 配合缓存，两者都考虑吊销时间窗口（如 24-72 小时）内的残余风险。

CRL 与 OCSP 是互为补充的撤销机制：CRL 适合离线批量、OCSP 适合在线实时，时效用 nextUpdate/thistUpdate 控制；stapling 把"在线检查"变成"服务器预缓存签名响应"，兼顾时效与隐私。

• AEAD nonce = 静态 IV 与序列号（或明文的 implicit nonce）异或
• 收发方向使用不同的 traffic secret
• 密钥更新的方向独立性

TLS 1.3 记录层使用 AEAD 时，nonce 由静态 IV（来自 traffic secret 派生）与记录序列号组合构造：通常为 IV 与序列号（8 字节）的异或（例如 nonce = XOR(static IV, seq_num)），保证每个记录 nonce 唯一且不重用。收发方向使用不同的 traffic secret（client_key 与 server_key 各自独立派生），因此客户端与服务器的加密密钥、IV、序列号各自独立，互不干扰。密钥更新（key_update）时，每个方向独立地把 traffic secret 与更新标签派生为新 secret，客户端与服务器各自推进自己的方向，保证收发方向的密钥序列不冲突、可独立更新，避免单方向更新影响另一方向。

"nonce 由静态 IV 与序列号构造"保证同一密钥下 nonce 只增不减、不重用；"收发方向独立"保证双方各自管理密钥与序列号，避免共享状态导致的同步错乱与密钥重用。

• 各阶段失败的错误特征与握手阶段
• 服务器日志与客户端错误
• 诊断工具（openssl s_client、tcpdump）

握手失败可分层定位：SNI 不匹配通常表现为服务器返回未知名/拒绝连接，或客户端收到与 SNI 不符的证书，服务器日志显示无匹配 server_name。ALPN 不兼容表现为 TLS 握手成功但应用层报 no application protocol，客户端收到 ALPN 协商失败（服务器基于 ALPN 判断 h2 是否支持）。证书链问题表现为证书验证失败（untrusted、hostname mismatch、链不完整），报 "certificate verify failed"。签名算法不兼容表现为服务器无法用客户端支持的 signature_algorithms 签名，或客户端不认可服务器签名算法，报 unsupported signature algorithm。密钥份额不兼容表现为服务器无法匹配 key_share，发送 HelloRetryRequest 后客户端重发 key_share，过多重试则报 key_share 不匹配。工程上可用 openssl s_client -alpn、-servername、-tls1_3 等分参数复现，配合服务器端 debug 日志（TLS version、cipher、alert）与抓包（tcpdump）定位具体阶段。

定位思路是"按握手阶段逐层排查"：先看版本协商，再看 key_share，再看 ALPN/SNI，最后看证书与签名。每种失败对应不同 alert 与日志关键字，结合工具可精确切片。

• 证书弱签名算法与协议版本降级之间的关系
• 浏览器对 SHA-1 等弱算法的禁用策略
• TLS 1.2 回退路径的安全代价

浏览器发现证书链含 SHA-1 根或弱签名算法时，通常不会自动回退到更低版本协议，而是根据信任策略拒绝或降级信任该证书。现代浏览器将 SHA-1、MD5 等弱签名算法视为不可信，即使连接使用 TLS 1.3，只要证书链使用 SHA-1 签名，浏览器也会报证书错误而非协商 TLS 1.1/1.0。若部署确实需要回退到 TLS 1.2（比如为了兼容某弱签名证书），安全代价是：TLS 1.2 缺少 TLS 1.3 的降级防护与 AEAD-only 强制，可能允许 CBC 套件、静态 RSA 等弱配置，且 NSS/Chrome 等会因 SHA-1 证书直接拒绝连接。因此正确做法是更换证书签名算法（如 RSA-PSS、ECDSA P-256），而非回退协议版本。

证书签名算法与协议版本是两个独立维度，弱签名算法应通过"证书策略"解决（拒绝/替换），而不是通过"协议降级"解决，因为降级会同时引入更多安全风险。

• 路径构建（path building）：从叶子找到信任锚的候选链
• 路径验证（path validation）：按 RFC 5280 验证候选链
• 交叉签名产生多条链的原因

路径构建是从末端实体证书出发，通过 issuer 字段向上寻找直到某个信任锚（根证书）的候选证书链集合的过程；路径验证则对每条候选链按 X.509 路径验证规则（RFC 5280：签名、有效期、Name Constraints、Key Usage、Basic Constraints、撤销等）逐证书校验，最终选择一条满足所有约束的链。交叉签名（cross-signing）指同一把 CA 私钥签发的证书，被多个根用不同名称/属性交叉签名，从而形成多条名称与信任关系不同的候选根。因此同一叶子证书可能对应多条可达信任锚的链，路径构建需枚举所有候选，路径验证需从中选出一条同时满足所有约束（如 Name Constraints、信任锚匹配）的链。

构建是"找路"，验证是"验路"。交叉签名让"找路"产生多条路径，验证则用约束条件（尤其 Name Constraints 与信任锚）筛选出唯一正确路径，保证互操作与安全。

• 各签名算法的密钥大小与签名/验证性能
• 硬件加速（HSM、TLS 加速卡）的兼容性
• 生态兼容性与部署取舍

RSA-PSS 密钥较大（2048/4096 位），签名较慢、验证较快，但几乎被所有旧 CA、Web 服务器与硬件（HSM、TLS 加速卡）支持，兼容性最好，适合需要广泛互操作的部署。ECDSA P-256 密钥小（256 位）、签名与验证都很快，存储与带宽占用小，广泛支持并有硬件加速，是 Web 证书与 TLS 的主流选择。Ed25519（EdDSA）基于 Curve25519，密钥极小、签名与验证性能极佳、实现简单且侧信道稳健，但硬件加速支持相对有限，且部分旧 CA/浏览器/HSM 支持仍不完善，适合新系统与高性能场景。Ed448 是 Ed25519 的 448 位增强版，安全强度更高但密钥与性能开销更大，部署较少。取舍在于：兼容性优先选 RSA-PSS，性能与生态平衡选 ECDSA P-256，追求极简与安全选 Ed25519，高安全需求选 Ed448。

选择签名算法是"安全强度、性能、生态兼容"的三角权衡。证书签名场景中，兼容性（CA 与浏览器支持）往往比原始性能更重要，因此 ECDSA P-256 与 RSA-PSS 是主流，Ed25519 正在快速普及。

• 缩短有效期以限制泄露影响与简化撤销
• 自动续期（ACME）与证书生命周期管理
• 监控告警的关键节点（到期前续期、续期失败）

Let's Encrypt 使用 90 天有效期，是为了限制证书私钥泄露的影响面（泄露后 90 天内即失效，无需依赖撤销），并推动证书自动续期成为常态，减少人工管理的过期故障。它通过 ACME 协议自动化签发与续期，配合 certbot 等客户端定时续期（通常到期前 30 天开始尝试）。关键告警节点应布置在：证书到期前 30 天（续期开始）、到期前 14 天（续期失败告警）、到期前 7 天（紧急告警）、以及日常的续期失败、SAN 变更、私钥权限异常等。监控应覆盖证书剩余有效期、续期任务执行状态、ACME 挑战成功与否、CA 可达性，以及证书链完整性。

90 天有效期的核心是"以自动化为前提的安全策略"——把证书恢复为"可频繁轮换的短生命周期凭据"，从而减少撤销依赖并降低泄露风险。监控必须围绕"续期成功"这一关键事件前置布置。

• TLS 1.2 与 1.3 的 cipher suite 协商差异
• HelloRetryRequest 是 TLS 1.3 的机制
• 版本兼容性

在 TLS 1.2 中，cipher suite 协商由客户端在 ClientHello 中列出候选，服务器直接选择并在 ServerHello 中回送，无需额外的重试消息。HelloRetryRequest 是 TLS 1.3 才引入的机制，用于请求客户端重新发送 key_share（当服务器不支持客户端提供的密钥组）或重发收到异常消息的情况。TLS 1.2 没有 HelloRetryRequest，因为它的密钥交换不依赖客户端预先生成的 key_share（没有"预生成公钥"这回事），服务器选择 cipher suite 后直接进入 ServerKeyExchange 阶段即可。因此该问题本质是版本差异：TLS 1.2 用 ServerHello 完成 cipher 协商，TLS 1.3 用 HelloRetryRequest 处理 key_share 不匹配，而不能在 1.2 中等到 HelloRetryRequest。

HelloRetryRequest 是 1.3 为"客户端预生成 key_share 但服务器不匹配"这一场景设计的额外往返恢复机制，而 1.2 的 cipher suite 协商天然不需要它，两者对应不同的协议阶段与设计。

• MAC-then-Encrypt 与 Encrypt-then-MAC 的顺序差异
• CBC padding oracle 攻击（Padding Oracle、BEAST、Lucky13）
• 工程教训：认证与加密的顺序会影响安全

TLS 1.2 的 CBC 套件（如 TLS_RSA_WITH_AES_128_CBC_SHA）默认采用 MAC-then-Encrypt 顺序：先计算 MAC 附加到明文，再整体加密（密文=Encrypt(plaintext||MAC)）。这一顺序在解密时若 padding 校验失败，会暴露 padding 是否合法，从而被 BEAST、Lucky13 等 padding oracle 攻击利用，从明文长度与 padding 错误信息中恢复数据。Encrypt-then-MAC（先加密再对密文计算 MAC）则能在解密前先验证 MAC，避免暴露 padding oracle，因此更安全。这两种顺序的对比是 TLS 工程的重要教训：认证与加密的组合顺序必须选择"先加密后认证"（Encrypt-then-MAC），且即使如此，CBC 的 IV 管理、padding 校验仍需统一错误处理，避免时序侧信道。TLS 1.3 直接用 AEAD 消除了这一顺序问题。

教训是"加密与认证的组合顺序决定是否泄露 padding oracle"。MAC-then-Encrypt 让解密填充错误可被观测，Encrypt-then-MAC 通过先验 MAC 规避，AEAD 则从协议层面根本解决。

• RSA 密钥交换的 PKCS#1 v1.5 padding 处理
• Bleichenbacher 攻击基于 padding 错误的时间/错误信息差异
• 缓解：constant-time、统一错误处理、TLS 1.3 移除

TLS_RSA_WITH_AES_128_GCM_SHA256 使用 RSA 密钥交换，客户端把 premaster secret 用 RSA 公钥加密后发送，服务器解密时校验 PKCS#1 v1.5 padding。若服务器对 padding 校验失败与成功采用不同的错误信息或响应时间，攻击者可通过构造大量 RSA 密文并观察服务器行为差异，逐一侵入 premaster secret，这就是 Bleichenbacher 攻击。现代实现的缓解包括：解密后无论 padding 是否合法都统一处理（constant-time 比较、随机化 premaster）、统一错误响应、限制重试次数，以及部署认证加密（AEAD）与 TLS 1.3 移除 RSA 密钥交换。由于 TLS 1.3 彻底移除静态 RSA 密钥交换，Bleichenbacher 类攻击在 1.3 中不再适用。

风险源于"RSA 密文解密后的 padding 校验结果可被观测"。缓解关键是"让 padding 校验失败与成功在时间与错误上不可区分"，从根上消除 oracle。

• TLS 1.3 的降级防护机制
• ServerHello.random 中的 downgrade sentinel 值
• 客户端检测降级

TLS 1.3 在 ServerHello.random 中预置降级哨兵值（downgrade sentinel）：当服务器声明支持 TLS 1.3 但实际协商 TLS 1.2 时，ServerHello.random 的最后 8 字节会写入固定哨兵字节（TLS 1.2 为 44 4F 54 47 52 44 0A 4E）；TLS 1.1/1.0 用另一哨兵。客户端若本身支持 TLS 1.3，却在 ServerHello 中看到这些哨兵值，即表明存在降级攻击（中间人把 1.3 握手拆成 1.2），从而终止连接。同时，客户端在 supported_versions 扩展中声明支持的版本，服务器依据它选择最高版本；若服务器明明可从 supported_versions 看到 1.3 却回 1.2，且随机数含哨兵，客户端即判定降级。这样通过"服务端能力声明 + 哨兵值"双向检测降级 dance。

降级防护的核心是"服务端在知道客户端支持更高版本的情况下，若回退到低版本，必须留下可验证的哨兵标记"，客户端据此识别中间人压低版本的行为。

• ALPN：协商应用协议（h2、http/1.1）
• ALPS：在握手时携带应用层设置（如 HTTP/2 SETTINGS）
• QUIC 与 TCP 上发送时机与应用层的差异

ALPN（Application-Layer Protocol Negotiation）在 ClientHello 中协商应用协议（h2、http/1.1），是 TCP 与 QUIC 上 TLS 握手都有的机制，决定后续应用层协议。ALPS（application_settings）是 TLS 1.3 的扩展，允许在握手阶段就携带应用层参数（如 HTTP/2 的 SETTINGS、MAX_CONCURRENT_STREAMS 等），从而在第一个应用数据发送前完成参数协商，省去单独的应用层 SETTINGS 往返。在 TCP 上，ALPN 协商后仍需在 HTTP/2 连接开始后通过 SETTINGS 帧交换参数；而在 QUIC 上，握手往往与 0-RTT 结合，ALPS 能让客户端在 0-RTT 数据中直接使用正确的 SETTINGS，避免因参数不同步造成的 0-RTT 拒收。工程上 ALPS 提升"参数协商效率"，ALPN 提升"协议选择"，两者互补。

ALPN 回答"用哪个协议"，ALPS 回答"该协议的初始参数是什么"。在 QUIC/0-RTT 场景下，ALPS 让客户端在早数据中即用正确参数，减少协商失败与延迟。

• OCSP stapling 让服务器在握手时附带 OCSP 响应
• 省去客户端在线查询 OCSP 的往返
• multi-staple 附带多张证书的 OCSP 响应

OCSP stapling（status_request 扩展）让服务器在 TLS 握手（Certificate 消息）中附带它预先向后端 OCSP responder 获取的 OCSP 响应，客户端无需在握手后额外发起 OCSP 查询来校验证书撤销状态，从而节省一次（甚至多次）网络往返，减少握手延迟。OCSP multi-staple（status_request_v2）扩展则允许服务器在一条握手消息中附带证书链中多张证书（如叶子与中间证书）的 OCSP 响应，为每条可能被验证的链提供完整撤销信息，避免客户端因某张证书缺 OCSP 响应而回退到在线查询或 CRL。工程价值是：撤销状态检查被"预取 + 缓存 + 随握手送达"，兼顾时效性、隐私（客户端不向 CA 暴露访问哪个站点）与低延迟。

stapling 把"在线撤销查询"从客户端（每次连接）移到服务器（预取缓存），是典型的"集中预取 + 分发给所有客户端"模式，显著降低延迟与隐私泄露。

• CertificateRequest 在服务端请求客户端证书时的作用
• signature_algorithms：服务端可接受的客户端证书签名算法
• certificate_authorities：服务端接受的 CA 集合

在 mTLS（双向认证）中，服务端发送 CertificateRequest 请求客户端证书，其中携带两个扩展引导客户端选择：signature_algorithms 声明服务端可接受的客户端证书及其签名算法（如 ECDSA P-256、RSA-PSS），客户端据此只选择签名字法匹配的证书；certificate_authorities 声明服务端信任的 CA 列表（以 DN 或权威机构名称标识），客户端据此从本地证书库中筛选出由这些 CA 签发的证书，避免发送服务端不接受的证书。两者共同帮助客户端在没有交互的情况下自动选出最合适的客户端证书，减少因证书不匹配导致的握手失败与重试。

这两个扩展是"服务端能力与信任声明"，让客户端在无需用户选择的情况下精准匹配证书，是 mTLS 自动化的关键，也避免客户端暴力尝试所有证书造成的握手延迟。

• 后量子 KEM（ML-KEM）与经典 ECDHE 的混合
• key_share 中同时携带两类密钥材料
• 混合密钥派生与安全性

X25519MLKEM768 是 TLS 1.3 的后量子混合密钥交换方案，把经典的 X25519 ECDHE 与后量子 KEM ML-KEM-768 结合，以抵御未来量子计算机对经典 ECDHE 的破解。部署流程中，客户端在 key_share 中同时提供 X25519 公钥与 ML-KEM-768 的封装公钥，服务器在 key_share 中回送自己的 X25519 公钥与 ML-KEM 密文（封装结果）；双方分别通过 X25519 得到共享密钥 S1、通过 ML-KEM 解密得到共享密钥 S2，再通过 SHA-256 或 HKDF 将两者混合（concatenate + hash）得到最终 ECDHE 共享密钥，作为 TLS 1.3 key schedule 的输入。混合确保即使一方算法被攻破，另一方仍提供安全，且 ML-KEM 密文与公钥大小增加使 key_share 更大，需注意 ClientHello 体积与握手延迟。

混合的核心是"密码学多样性"——同时依赖经典与后量子算法，用哈希组合密钥，保证"至少一个算法安全"即安全。部署需考虑 key_share 增大导致的握手消息体积增加。

• false start：客户端在收到服务器 Finished 前就发送应用数据
• 0-RTT：客户端在首次消息时就发送应用数据
• 两者的延迟收益与安全取舍

false start 允许客户端在服务器发送 Finished 之前（即在收到 ServerHello 后、确认服务器身份前的某个安全点）就发送应用数据，通常节省一个 RTT；它依赖 ECDHE 已完成密钥协商，且应用数据只发往已部分验证的服务器，安全性上存在"在完整认证前发送"的轻微风险，但 TLS 1.3 中 false start 已通过协议流设计（客户端在 ServerHello 后即可发送 application data）被大部分吸收。0-RTT 则更进一步，客户端在第一条 ClientHello 时就用缓存 PSK 发送早期数据，节省首个 RTT。取舍上：0-RTT 延迟最优但有重放风险且无 PFS；false start 延迟较好但已认证语义更弱。兼容性上，0-RTT 需要客户端与服务器都支持 early data 且持有 PSK，false start 也需双方支持，且都需谨慎处理非幂等请求。

false start 与 0-RTT 都在"提前发送数据"换取延迟，但一个在握手中途、一个在握手之初，安全前提不同；0-RTT 更激进（重放、无 PFS），需应用层幂等兜底。

• 无状态 resumption：ticket 携带加密密钥，服务器无需存储
• ticket key 在边缘节点间的共享与轮换
• 多机房的一致性

CDN 采用无状态 session resumption：服务器签发 NewSessionTicket 时，把会话密钥用共享的 ticket key（带 AEAD）加密进 ticket 本身，客户端之后提交此 ticket，任何持有相同 ticket key 的边缘节点都能解密并恢复会话，无需跨机房同步会话状态。工程关键是多机房/边缘节点必须共享同一套 ticket key（通常通过集中式 KMS/密钥分发服务下发），否则在不同节点提交的 ticket 无法解密。ticket key 需要定期轮换（如每 24 小时生成新 key、保留旧 key 一小段时间供在途 ticket 解密），轮换流程要保证"旧 key 只用于解密新 ticket 用新 key 加密"，从而实现无缝切换。多机房还需保证 ticket lifetime 与 key 轮换时间一致，避免客户端在 key 被轮换后仍持旧 ticket 导致恢复失败（此时回退到完整握手）。

无状态 resumption 用"共享密钥 + 自包含 ticket"替代"分布会话状态"，牺牲一点点密钥更新的安全性（ticket key 泄露影响所有加密的 ticket），换取多机房一致性无需同步。合理轮换 ticket key 是平衡安全与可用性的关键。

• max_early_data_size 字段在 NewSessionTicket 中声明
• 限制单次重放影响的量
• 与 0-RTT 重放风险的管理

服务端在 NewSessionTicket 中通过 max_early_data_size 字段声明允许的 early data（0-RTT 数据）最大字节数，客户端据此限制发送量。常见上限为 16KB（即一条记录层可承载的最大数据量），工程意义在于：限制单次 0-RTT 重放可携带的数据量，把重放攻击的"影响面"控制在有界范围内；同时避免客户端一次性发送过多未认证数据导致服务器处理负担与内存风险。16KB 也恰好对应 TLS 记录层最大明文大小，使 early data 可落在单条记录中，便于实现与处理。该限制反映"0-RTT 只用于发送少量、可安全重放的请求头或小载荷"的工程定位。

max_early_data_size 是"重放影响面收敛"的协议级控制。把 0-RTT 数据限制在 16KB 量级，既满足实际小请求需求，又避免重放造成大范围副作用。

• 不同网络 RTT 的差异（4G 高 RTT、Wi-Fi 6E 低 RTT）
• 0-RTT 节省 RTT 的模型
• 延迟收益与 RTT 的关系

TLS 握手延迟正比于 RTT 与握手所需往返数。完整握手（1-RTT）耗时约 1 个 RTT（加上处理时间），0-RTT 则把数据发送提前到首个消息，节省约 1 个 RTT。在 4G 网络下 RTT 较高（通常 30-100ms 甚至更高），1-RTT 握手延迟明显，0-RTT 可显著节省数十毫秒，对移动端首屏体验收益大；而 Wi-Fi 6E 的 RTT 很低（几毫秒到十几毫秒），0-RTT 节省的绝对毫秒级微不足道，但对在线游戏、即时交互等超低延迟场景仍有意义。建模时可用"总延迟 = 握手RTT数 × RTT + 处理时间"，0-RTT 收益 = 节省的 RTT 数 × RTT，并考虑 0-RTT 的重放风险权衡（低延迟场景更高收益，但需幂等）。因此在 RTT 高的网络（4G、卫星）0-RTT 收益显著，在 RTT 极低的网络（Wi-Fi 6E、有线）收益相对有限。

0-RTT 收益与 RTT 成正比，模型是"节省的往返数 × RTT"。移动蜂窝网络 RTT 高、0-RTT 收益大，超低延迟网络收益小但仍可结合其他策略（如预连接）使用。

• key_share 中客户端未提供服务器支持的组
• HelloRetryRequest 携带服务器选择的 named_group
• 客户端重发 key_share 的容错流程

当服务器的 key_share 中不包含客户端提供的任何组（或客户端未提供 key_share）时，服务器发送 HelloRetryRequest，并在其中携带它选择的 named_group（如 X25519），请求客户端用该组重新生成并发送 key_share。客户端收到后，用指定的组重新生成 ECDH 公钥，在第二个 ClientHello 中携带新的 key_share，从而保证密钥协商成功。这是对"客户端预生成 key_share 但服务器组偏好不匹配"这一情况的工程容错：它用一次额外往返（HelloRetryRequest 往返）换取"客户端不必预先猜中服务器组"的灵活性，同时保留了 1-RTT 的协商效率。若客户端无法支持服务器选择的组，则中止握手。

HelloRetryRequest 是"预生成 key_share 的兜底机制"，让客户端在首次猜错服务器组时可及时纠正，代价是额外一次往返，但比让客户端永远预生成所有组更节省带宽。

• TLS 1.2 Session Tickets：客户端恢复，密钥派生基于 master secret
• TLS 1.3 PSK：统一为 PSK 机制，密钥派生绑定 transcript
• 前向保密与密钥派生差异

TLS 1.2 的 Session Tickets 让客户端持有一个加密的 ticket，恢复时服务器解密 ticket 得到与原始会话相关的 master secret，后续密钥从这个 master secret 派生，但未把新会话的密钥绑定到新握手 transcript，且提供较低的前向保密（取决于实现）。TLS 1.3 将恢复统一为 PSK 机制：NewSessionTicket 中携带的 PSK 与外部 PSK 一样，作为 key schedule 的输入，通过 HKDF 从 PSK 派生 Early Secret 并逐级派生 Handshake/Application traffic secret，且每个阶段的密钥都通过 HKDF-Expand 用 Label 与 transcript hash 绑定，确保每次会话的密钥都是独立派生、绑定到具体握手上下文的。根本差异在于：TLS 1.3 的 PSK 恢复走统一的、绑定 transcript 的 key schedule，且支持 psk_dhe_ke（PSK+ECDHE）提供前向保密；TLS 1.2 的 ticket 恢复更接近"直接复用 master secret"，密钥派生与 transcript 绑定较弱。

TLS 1.3 把 PSK 提升为 key schedule 的一等公民，用 HKDF 与 transcript 绑定保证每会话密钥独立，并支持可选的 ECDHE 混合以获得 PFS，这是相对 1.2 ticket 恢复的根本改进。

• ticket lifetime 的配置与含义
• anti-replay 机制（single-use、0-RTT 重放）
• 兼容性迁移

TLS 1.2 的 SessionTicket 通常有较长的 lifetime（如默认 24 小时或更长），服务器用它加密会话状态，客户端持有 ticket 以恢复，但缺少明确的 anti-replay 机制（ticket 可被重放，虽然通常只影响会话恢复而非数据）。TLS 1.3 的 NewSessionTicket 在配置中使用 ticket_lifetime 字段声明有效期，且为支持 0-RTT 引入了更强的 anti-replay 要求：服务端应使用一次性（single-use）ticket 或维护 anti-replay 缓存，防止 early data 被重放。兼容性工程上，迁移时需保证：TLS 1.2 与 1.3 的 ticket 格式与密钥不同，需分别管理；ticket lifetime 需与 0-RTT 的 max_early_data_size、client 端缓存策略协同；服务端轮换 ticket key 时，旧 ticket 在在途生效期内应能解密（旧 key 保留窗口），否则客户端恢复失败回退到完整握手。

两者的差异是"1.2 侧重恢复成功率、1.3 侧重安全（anti-replay）"。兼容性关键是统一管理 ticket 生命周期、密钥轮换与 anti-replay 状态，避免新旧协议语义冲突。

• 中间盒（middlebox）对 TLS 1.3 的兼容问题
• session ID 兼容模式
• 与 TLS 1.2 会话的伪装

TLS 1.3 引入 session ID 兼容模式（middlebox compatibility mode），是因为大量中间盒（防火墙、负载均衡、IDS）基于 TLS 1.2 的握手特征（如 ChangeCipherSpec、session ID 非空）做解析与状态跟踪，遇到 TLS 1.3 的加密握手可能错误处理或丢包。为兼容，TLS 1.3 客户端在 ClientHello 中模拟一个"可恢复的 TLS 1.2 会话"：发送一个伪 session ID、发送一条空 ChangeCipherSpec 消息，使中间盒误以为这是它熟悉的 TLS 1.2 会话恢复，从而正常转发。服务器在 ServerHello 中回显该 session ID 并同样发送空 ChangeCipherSpec，扮演"会话被恢复"的形态，让中间盒继续放行。这样在保持 TLS 1.3 真正安全握手的同时，兼容了不支持 1.3 的中间盒。

该模式是"为兼容旧中间盒而做的协议伪装"，用空的 session ID 与 ChangeCipherSpec 让中间盒误判为 1.2 会话，避免其破坏 1.3 握手，代价是额外发送两条空消息。

• key schedule 的 Extract/Expand 阶段
• 从 ECDHE 共享密钥派生 handshake secret / traffic secret
• HKDF 的 Extract 与 Expand 作用

TLS 1.3 的 key schedule 基于 HKDF（HMAC-based Key Derivation Function）。首先用 HKDF-Extract 从 ECDHE 共享密钥（或 PSK）提取出 initial secret，再通过 HKDF-Expand-Label 用不同 Label 逐级派生：Early Secret（早期）、Handshake Secret（根据 ECDHE 共享密钥与 transcript 派生）、Client/Server Handshake Traffic Secret（分别用于收发握手消息的加密）、Master Secret（在握手完成后派生）、Client/Server Application Traffic Secret（用于应用数据加密）。每一级都通过 HKDF-Expand 用 Label（如 "c hs traffic"、"s hs traffic"、"c ap traffic"、"s ap traffic"、"res master"）与 transcript hash 绑定，确保方向与用途区分。HKDF 的角色是：Extract 提供"打散并压缩熵"（把可变输入均匀化），Expand 提供"按 Label 与上下文扩展出不同用途的密钥"，两者结合保证密钥独立、不可预测、可区分。

HKDF 是密钥分层的数学引擎：Extract 把共享秘密压缩成伪随机中间产物，Expand 用 Label+transcript 扩展出每个阶段、每个方向的独立密钥，从而支撑"一密钥一用途一上下文"的安全设计。

• TLS 1.3 把会话恢复收敛为 PSK
• session ticket 派生 PSK（resumption PSK）
• 外部 PSK 与 resumption PSK 的区别

TLS 1.3 把会话恢复统一为 PSK 机制：服务器在握手后发送 NewSessionTicket，其中包含用 resumption_master_secret 派生的 PSK（resumption PSK）。客户端在后续连接中把该 PSK 放入 ClientHello 的 pre_shared_key 扩展，服务器解密校验后恢复会话。session ticket 与外部 PSK 的区别在于来源与生命周期：session ticket 是"服务端签发、从 resumption_master_secret 派生、用于上次会话恢复"的 PSK，有明确的 lifetime 且绑定服务端 ticket key；外部 PSK 是"带外（out-of-band）手动配置、共享双方"的 PSK，如企业预共享密钥，通常无自动签发流程、生命周期由管理端控制。两者在握手时都作为 PSK 输入 key schedule，但 binder 计算都基于对 PSK 的 HMAC，且 resumption PSK 通常配合 psk_dhe_ke 提供 PFS，外部 PSK 则往往纯 PSK。

统一为 PSK 让"恢复"与"预共享认证"共用同一套密钥派生逻辑，简化协议。区别本质是"PSK 由谁签发、怎么管理"：ticket 由服务器动态签发用于恢复，外部 PSK 由管理员静态配置用于认证。

• HRR 的单一往返机制
• 客户端收到 HRR 后只重发 key_share，不重新握手
• 避免完整重握手

当客户端提供的 key_share 不被服务器接受（服务器需要的组不在其中）时，服务器发送 HelloRetryRequest，并在其中携带所选 named_group。客户端收到后，不重新开始完整握手，而是仅用该组重新生成 key_share，并在第二个 ClientHello 中重发（同时保留其他扩展），从而以"一次额外往返"恢复协商，而不是推倒重来。这避免了"客户端预生成所有组的 key_share"带来的带宽浪费，也避免了传统协商中"服务器组选择后客户端再重新完整握手"的多次往返。工程上，客户端通常预生成一个最常用组（如 X25519）的 key_share，绝大多数情况无需 HRR；只有当服务器偏好其他组时才触发 HRR，把额外往返控制在极少数情况。

HRR 的核心价值是"用一次可控的额外往返换取带宽节省与兼容性"，且只在客户端预生成组不匹配时才发生，是优化平均握手延迟（绝大多数 1-RTT）的工程手段。

• cert-manager 签发证书并写入 Secret
• Secret 命名空间隔离与副本分发
• 镜像仓库信任链（roots、registries）

cert-manager 在 Kubernetes 中通过 ACME/CA 签发证书，并把证书与私钥写入指定的 Secret（通常与工作负载同命名空间）。联动时需注意：Secret 是命名空间隔离的，若要跨命名空间使用（如多个服务共享同一证书），需通过 Secret 复制（如 Reflector 或复制 controller）或集中管理；证书链（leaf + intermediate）需作为完整链写入 Secret（tls.crt 含完整链），供 Ingress/Service Mesh 使用。镜像仓库信任链方面，若集群内镜像拉取走私有仓库（如 Harbor），需把仓库 CA 根证书注入到每个节点的容器运行时信任库（如通过 containerd 的 certs.d 或 daemon 配置），保证节点能验证仓库 TLS；这与 cert-manager 签发的服务证书是两条独立信任链——服务证书由工作负载信任，仓库证书由节点/容器运行时信任，但都可统一由 cert-manager 或私有 PKI 管理（如用 Vault 签发仓库根证书并通过 kubelet 分发）。联动点是：统一私有 PKI 的根证书需同时分发到"客户端信任工作负载"与"节点信任仓库"两个层面。

cert-manager 解决"服务证书生命周期"，镜像仓库信任链解决"节点到仓库的 TLS"。两者共享同一私有 PKI 根时，需通过 Secret 分发（服务侧）与节点信任库配置（仓库侧）联动，确保端到端信任一致。

• 三种模式：纯 PSK、纯 DHE、PSK+DHE
• Early Secret 从 PSK 派生
• Handshake Secret 从 ECDHE 共享密钥派生

TLS 1.3 key schedule 的输入是 PSK 与 ECDHE 共享密钥（依据模式）。纯 PSK 模式下只有 PSK 参与；纯 DHE 模式下 PSK 用零值（empty PSK）填充；PSK+DHE 模式两者都参与。流程：首先用 HKDF-Extract(PSK, 0) 得到 Early Secret，从它派生 Early Traffic Secret 与 Binder Key；随后用 HKDF-Extract(ECDHE 共享密钥, Early Secret-derived "derived" secret) 得到 Handshake Secret，从它派生 Client/Server Handshake Traffic Secret；握手完成后，用 HKDF-Extract(0, Handshake Secret-derived "derived" secret) 得到 Master Secret，从它派生 Application Traffic Secret 与 resumption_master_secret。三种模式的区别在于是否有 ECDHE 参与：纯 PSK 无 ECDHE（无 PFS），纯 DHE 无 PSK（PRE 为空），PSK+DHE 两者合并（有 PFS 且支持恢复）。

key schedule 是"分层、可组合"的：PSK 决定 Early/Master 相关秘密，ECDHE 决定 Handshake Secret 也提供 PFS。模式选择决定"是否引入 ECDHE 临时密钥"，从而决定是否获得前向保密。

• SNI：目标域名
• ALPN：应用协议
• supported_groups：支持的椭圆曲线/密钥组

ClientHello 的四个扩展传达：SNI 用于指示目标域名（服务端据此选择对应证书与虚拟主机）；ALPN 声明客户端支持的应用协议（如 h2、http/1.1），服务端选择并回送；supported_groups 声明客户端支持的密钥协商组（如 X25519、P-256），服务端从中共选；signature_algorithms 声明客户端认可的证书/握手签名算法，服务端据此选择证书并签名。服务端回退策略：若 SNI 无匹配，回退到默认证书（可能证书不匹配）；若 ALPN 无共同项，回退到 http/1.1 或终止握手；若 supported_groups 不匹配，发送 HelloRetryRequest 要求客户端换组；若签名算法不匹配，回退到更弱但与客户端兼容的签名或终止握手。回退等级应保证"最弱回退不破坏安全"。

这四个扩展是握手能力协商的"协商输入"，服务端按"选择 + 回退"逻辑处理。回退要平衡兼容性与安全，一般不降级到弱于可接受底线的算法。

• Must-Staple（tls-feature 扩展）的作用
• 缺失时的处理策略
• 可用性权衡

OCSP Must-Staple（证书的 tls-feature 扩展）要求服务器在 TLS 握手时提供 OCSP stapling 响应，否则浏览器会拒绝连接或视为证书无效。它把"撤销状态检查"从可选的在线查询变成强制的握手内附带，提升安全性。缺失时，浏览器的处理策略不完全一致：多数遵循 RFC 7633 的浏览器会拒绝握手（视为证书不可用），因为证书声明了必须 stapling 却未提供；也有部分实现采取"软失败"（回退到在线 OCSP 或 CRL）以保可用性。工程上，使用 Must-Staple 的站点必须保证 OCSP 响应服务可靠、可缓存且更新及时，否则一旦 stapling 缺失会导致大面积连接失败；因此常配合 CDN/边缘的 OCSP 预取与缓存，以及把 Must-Staple 与短生命周期证书结合。

Must-Staple 把"撤销及时性"从可选提升为强制，代价是引入"stapling 缺失即失败"的可用性风险，因此部署时需保证 OCSP 响应的高度可用。

• 服务端 ticket key 轮换后旧 ticket 无法解密
• 回退到完整握手
• 前向保密通过 ECDHE 保证

当客户端持有旧 session ticket，但服务端已轮换 ticket key（旧 key 被移除且不再保留），服务端无法解密该 ticket，无法进行 PSK 恢复。此时服务端可忽略该 PSK，回退到完整握手（1-RTT 的 ECDHE 密钥交换），客户端与服务端重新协商；若客户端提供 psk_dhe_ke，服务端可把 PSK 与 ECDHE 结合，但若 ticket 无法解密则整个 PSK 作废，走纯 ECDHE。前向保密由 ECDHE 的一次性临时密钥保证：即使 ticket key 轮换导致旧会话状态失效，新握手仍用 ECDHE 生成临时密钥，服务器长期私钥的泄露不影响新会话密钥。为减少回退，服务端通常保留旧 ticket key 一小段"优雅窗口"（只用于解密、不用于签发新 ticket），使在途旧 ticket 能成功恢复，窗口过后才完全移除。

ticket key 轮换后，旧 ticket 失效回退到完整握手是正常行为，PFS 由 ECDHE 提供。保留旧 key 解密窗口可在"安全轮换"与"恢复成功率"间平衡。

• CT 日志与 SCT（签名证书时间戳）
• SCT 嵌入方式（TLS 扩展、X.509 扩展、OCSP）
• Chrome 的 CT 策略要求

Certificate Transparency 把证书的签发记录到公开、可审计的日志中，CA 在签发时把证书提交给日志，并获得日志签名的 SCT（Signed Certificate Timestamp）。SCT 被嵌入证书（通过 X.509 扩展、TLS 扩展或 OCSP stapling）随证书交付给客户端。Chrome 的 CT 策略要求证书链必须携带足够数量的 SCT（通常来自不同日志、满足一定数量），否则 Chrome 会拒绝信任该证书。这影响证书申请流程：CA 需在签发时提交日志并获取足够 SCT；部署时需确保 SCT 正确嵌入（如签名时用 CA 提供的 SCT，或通过 OCSP stapling 传递），并确认 SCT 覆盖 Chrome 要求的日志数量与组合。证书管理需监控 SCT 的时效与日志可用性，确保 CT 合规。

CT 是"让证书签发可审计"的机制，SCT 是日志的签发凭证。Chrome 的 CT 策略把"必须携带有效 SCT"变成证书被信任的硬性要求，因此 CA 签发与部署必须满足 SCT 数量与来源要求。

• SAN：证书绑定的域名/身份
• Name Constraints：CA 对子证书名称范围的限制
• Key Usage：私钥用途

SAN（Subject Alternative Name）声明证书绑定的具体域名、IP 或邮箱，决定证书可对哪些 hostname 生效。Name Constraints 在中间 CA 证书中声明其签发的子证书名称必须落在指定范围（如只允许 *.example.com），防止 CA 越权签发任意域名。Key Usage 限制私钥可用于的密码学操作（如 digitalSignature、keyEncipherment、keyCertSign），防止私钥被用于非预期场景。Extended Key Usage（EKU）限制证书可被用于的用途（如 serverAuth、clientAuth、codeSigning），防止服务器证书被用作客户端证书或代码签名。四者共同形成"名称 + 层级 + 密钥用途 + 应用用途"的多维约束，浏览器在验证时需同时满足所有约束，超出任一限制即视为无效。

SAN 定"能证明谁"，Name Constraints 定"CA 能签发谁"，Key Usage 定"私钥能做什么"，EKU 定"证书能用于什么"。四者正交互补，构成证书信任的完整边界。

• SPIFFE ID 作为工作负载身份
• SVID（SPIFFE Verifiable Identity Document）证书
• 短期证书与自动轮换

SPIFFE 定义了一种标准化的工作负载身份格式（SPIFFE ID，如 spiffe://example.org/ns/default/sa/payment），把微服务身份抽象为统一 URI。SPIRE 是 SPIFFE 的实现，为每个工作负载签发 SVID（通常是 X.509 证书，内含 SPIFFE ID 作为 SAN），并确保证书仅绑定到经过验证的工作负载。服务网格（如 Istio、Linkerd）通过 SPIRE 获取 SVID 证书，用于 mTLS 双向认证：每个服务用 SVID 证书向对端证明自己的 SPIFFE ID，对端验证证书链与 SPIFFE ID 归属。SVID 通常签发为短期证书（如几小时到一天），配合自动轮换（SPIRE Agent 定期向 Server 申请新证书并下发注入 workload），实现"身份自动更新、私钥短期有效"——即使私钥泄露影响面也小，且无需人工管理轮换。这使工作负载身份认证、授权与证书生命周期完全自动化。

SPIFFE ID 提供"统一的身份命名"，SVID 提供"可验证的身份凭证"，短期证书 + 自动轮换提供"身份凭证的安全生命周期"。三者结合实现服务网格中零人工干预的 mTLS 身份管理。

• OCSP stapling 的及时性与隐私
• CRL 的批量与可用性
• 短生命周期证书的撤销简并

三种机制各有侧重：OCSP stapling 由服务器预取 OCSP 响应随握手附带，及时性较好且不向 CA 暴露客户端访问的站点（隐私好），但依赖 OCSP responder 可用性与缓存更新，缺失时可能软失败。CRL 是批量、离线的撤销列表，可缓存、可镜像，但撤销可见性有延迟（下次发布）且列表增长有下载负担。短生命周期证书（如 24 小时-7 天）把"撤销"简化为"到期失效"：证书很快过期，即使被撤销也很快自然失效，无需频繁查询撤销状态，从而降低对 OCSP/CRL 的依赖，同时提升安全（私钥泄露影响有限）。平衡策略：高安全场景用短生命周期证书 + OCSP stapling（及时撤销），敏感场景辅以 CRL 兜底；隐私敏感场景用 stapling 避免泄露；可用性优先时用缓存 + 软失败回退。三者结合：短生命周期减少撤销压力，stapling 提供及时性 + 隐私，CRL 作为离线兜底。

撤销的"及时性、隐私、可用性"三者常互相矛盾：在线查询及时但泄露隐私、批量 CRL 隐私好但延迟高、短生命周期牺牲证书时长换取撤销简化。工程上按场景组合选择。

• OCSP stapling 缺失的原因（回源失败、缓存过期）
• must-staple 的严格处理
• 软失败回退策略

大规模 CDN 中，边缘节点需要向 OCSP responder 回源获取 OCSP 响应并缓存；若 CDN 回源失败、responder 不可达或缓存过期，stapling 响应会缺失。此时客户端处理取决于策略：must-staple 证书要求必带 stapling，缺失时严格客户端会拒绝连接（安全优先，但会牺牲可用性）；软失败则回退到在线 OCSP 查询或 CRL 检查（可用性优先，但有额外延迟与隐私泄露）。工程上 CDN 的兜底策略是：边缘节点预取并长时间缓存 OCSP 响应（在响应更新前复用），多机房互为备份回源，配置 OCSP 响应失败时的降级（如使用旧缓存响应、或临时回退到 CRL）。客户端侧则根据证书是否 must-staple 与安全要求选择硬失败或软失败，并配合 anti-staple 检测（防止攻击者移除 stapling 逼客户端回退到可观测的在线查询）。

兜底的关键是"在安全与可用性间找平衡"。CDN 用预取缓存 + 多源提高 stapling 可用率，客户端用 must-staple 硬失败或软失败回退，并防 stapling 移除攻击。

• 旧会话恢复（ticket key / PSK 处理）
• 链文件顺序（leaf + intermediate）
• 私钥权限保护

轮换服务证书时需处理：旧会话恢复——保留旧 ticket key/PSK 一小段解密窗口，使旧会话在轮换后仍能恢复，避免全部客户端回退到完整握手造成冲击；链文件顺序——证书配置（tls.crt）必须按"叶子证书 + 中间证书"顺序拼接，且需包含完整链到根，顺序错误会导致握手失败；私钥权限——私钥文件应仅服务进程可读（如 0600/600），存放于受保护路径，避免泄露；灰度回滚——将新证书按百分比灰度发布（如先 10% 流量），观察握手失败率、证书错误告警，若异常迅速回滚到旧证书（旧证书需保留至新证书稳定）。同时可配合 ACME 自动轮换与监控到期时间，确保轮换窗口内无空档。

轮换是"引入新证书、平稳过渡、可回退"的过程：旧钥匙的解密窗口保证恢复不中断，链顺序与私钥权限保证可用与安全，灰度 + 回滚降低风险。

• HKDF-Extract 与 HKDF-Expand-Label 的交替
• 各阶段秘密与 Label 的对应
• 派生链的完整顺序

TLS 1.3 key schedule 的派生链如下：先从 PSK 用 HKDF-Extract(PSK, 0) 得到 Early Secret；Early Secret 用 HKDF-Expand-Label ("ext binder"/"res binder") 派生 Binder Key，用 ("c e traffic") 派生 Client Early Traffic Secret；随后用 HKDF-Extract(ECDHE 共享密钥, Early Secret 的 "derived" 派生) 得到 Handshake Secret；Handshake Secret 用 ("c hs traffic"/"s hs traffic") 派生 Client/Server Handshake Traffic Secret；握手完成后用 HKDF-Extract(0, Handshake Secret 的 "derived") 得到 Master Secret；Master Secret 用 ("c ap traffic"/"s ap traffic") 派生 Client/Server Application Traffic Secret，用 ("res master") 派生 resumption_master_secret。每一步的 Label 作为 HKDF-Expand-Label 的 info，区分用途与方向。

派生链是"Extract 打散、Expand 按 Label 分域"的交替过程：PSK 经 Extract 得 Early Secret，经 Expand 得 Binder Key 与早期 traffic；再加入 ECDHE 经 Extract 得 Handshake Secret，经 Expand 得握手 traffic；最后经 Extract 得 Master Secret，经 Expand 得应用 traffic 与 resumption。每个 Label 保证同一阶段内不同用途（收发、early/handshake/app）的密钥互不混淆。

• resumption_master_secret 从 Master Secret 派生
• NewSessionTicket 中的 ticket 与该秘密的关系
• 安全设计：ticket 不暴露主密钥

TLS 1.3 在握手完成后，从 Master Secret 用 HKDF-Expand-Label ("res master") 派生 resumption_master_secret。服务器在发送 NewSessionTicket 时，ticket 内容不是直接暴露 resumption_master_secret（或主密钥），而是服务端用 ticket key 加密"会话状态 + 与该 resumption_master_secret 相关的 PSK 材料"封装而成。客户端拿到 ticket 后，在后续连接中把 ticket 作为 PSK 提交；服务端解密 ticket 恢复出 PSK，再把它作为 key schedule 的 PSK 输入。设计要点是：ticket 只携带"可恢复该会话的加密凭证"，主密钥（resumption_master_secret）本身不直接暴露给客户端，客户端无法从中推导主密钥，从而保护会话安全；且每次 NewSessionTicket 的 ticket 都绑定到特定 resumption_master_secret，防止跨会话滥用。

ticket 是"服务端加密的 session 状态 + PSK 凭证"，resumption_master_secret 是"派生该 session PSK 的源"。客户端只持有加密 ticket，握手凭证由服务端通过解密恢复，主密钥保密。

• key_update 消息与 update_traffic_key
• 密钥更新时对 traffic secret 的 HMAC 派生
• 2^24 次限制的原因

TLS 1.3 允许任一方在任意时刻发送 KeyUpdate 消息来更新 traffic key，而不需要重新握手。收到 KeyUpdate 后，发送方用当前 traffic secret 经 HMAC 派生新 traffic secret（即 update_traffic_key），并更新发送密钥；序列号重置。工程作用：定期更新密钥以限制单密钥加密数据量，降低密钥泄露影响与密码学分析风险。单密钥加密记录数受 AEAD 安全上限约束（AES-GCM 约 2^24.5 条），达到上限前应通过 KeyUpdate 或重新握手更换密钥，RFC 8446 并未规定 KeyUpdate 消息总数上限。

KeyUpdate 是"轻量密钥轮换"，避免重握手。2^24 上限是"安全 + 实现"的折中，既允许充分的密钥更新，又防止无限更新带来的状态管理风险。

• 预先生成 key_share 支持 1-RTT/0-RTT
• 服务器选择后再生成会多一次往返
• 延迟优化

TLS 1.3 让客户端在 ClientHello 中预先生成并携带 key_share（ECDHE 公钥），从而在服务器收到 ClientHello 后立即能派生出共享密钥，无需等待客户端再生成，实现 1-RTT 握手（甚至配合 0-RTT）。若允许服务器先选择 group 再让客户端生成，则需要一次额外往返（服务器选 group → 客户端生成并发送公钥 → 服务器计算密钥），使完整握手退化为 2-RTT，且无法实现 0-RTT。因此强制预生成 key_share 是为延迟优化而设计，代价是客户端需预生成一个（最常用）组，若服务器偏好其他组则用 HelloRetryRequest 兜底修正（额外一次往返，但只在少数情况发生）。

预先生成 key_share 是"把密钥协商信息提前到第一条消息"以换取 1-RTT/0-RTT 的延迟收益，是 TLS 1.3 相对 1.2 的核心优化之一。

• external PSK 与 resumption PSK 的来源
• binder 计算（PSK binder / resumption binder）
• 差异

TLS 1.3 的 PSK 分两类：external PSK 是带外（out-of-band）手动配置的共享密钥，如企业预共享密钥，用于双方事先约定的认证；resumption PSK 是会话恢复时由服务器签发的（来自 NewSessionTicket），用于无状态恢复。两者的 binder 计算差异在于：PSK binder 的 Label 不同——external PSK 使用 "ext binder" Label 计算 ClientHello 的 binder，resumption PSK 使用 "res binder" Label 计算。binder 是客户端用 PSK 对 ClientHello 计算 HMAC 的产物，放于 pre_shared_key 扩展中，服务器据此验证客户端确实持有该 PSK。两者都从 PSK 派生初始 binder key，但用不同 Label 区分以避免混淆，且 external PSK 通常无 service-issued 的会话状态，resumption PSK 绑定特定会话。

binder 用不同 Label（ext vs res）区分两类 PSK，防止外部 PSK 与恢复 PSK 的 binder 混淆，同时都验证"客户端持有 PSK"这一事实。

• 0-RTT 用 PSK 直接派生 early secret
• 无 ECDHE 参与故无临时密钥
• PFS 需要临时密钥

0-RTT 的 early data 使用 early traffic secret，该秘密从 PSK 直接派生（Early Secret = HKDF-Extract(PSK, 0)），而没有 ECDHE 临时密钥参与。前向保密要求加密密钥来自一次性临时密钥，握手后临时私钥即丢弃，故长期密钥泄露不影响历史数据。但 0-RTT 的密钥完全来自 PSK（它可能被长期保存或可被重放），一旦 PSK 泄露，攻击者可解密所有使用该 PSK 派生的 0-RTT 数据，且无法通过"丢弃临时密钥"提供保护。因此 0-RTT 只依赖 PSK 而无 ECDHE 提供的 PFS，其 early data 不满足前向保密。这解释了为何 0-RTT 只能用于非敏感、可重放的数据。

PFS 的本质是"密钥来自临时密钥"。0-RTT 的 early secret 完全来自 PSK（无 ECDHE 参与），PSK 可长期持有，故不满足 PFS，且存在重放风险。

• SCT 嵌入手法（TLS 扩展 vs X.509 扩展）
• 旧客户端对 X.509 嵌入 SCT 的兼容
• 兼容性策略

SCT 可嵌入不同位置：TLS 扩展（握手时通过 ServerHello 的 signed_certificate_timestamp 扩展携带）、X.509 证书扩展（直接在证书的 CT 扩展中嵌入 SCT）或 OCSP 响应。从 TLS 扩展迁移到 X.509 扩展时，旧客户端（不支持解析证书中 SCT 扩展的）可能无法直接从证书中提取 SCT，从而无法满足 CT 验证要求，甚至忽略该证书的 SCT。但 X.509 嵌入的 SCT 是"证书自带"，无额外握手开销且对不支持 TLS SCT 扩展的客户端也可见；不过旧客户端若未按 CT 策略处理证书内嵌 SCT，可能因无法验证 SCT 而拒绝或降级。兼容性策略：采用 X.509 嵌入的同时，可保留 TLS 扩展或 OCSP stapling 作为备选，保证旧客户端仍能获取 SCT；或者接受"旧客户端可能不验证 CT"的事实，依赖浏览器新版本默认支持证书内嵌 SCT。

迁移的关键是"客户端能否从新位置获取并验证 SCT"。X.509 嵌入让 SCT 随证书走，减少额外开销，但旧客户端可能不识别，需用多通道（TLS/OCSP）兼容。

• 中间 CA 私钥可签发下所有叶子证书
• 泄露影响范围与撤销
• 紧急再签发与根证书更新

中间 CA 私钥泄露后，攻击者可伪造任意由该中间 CA 签发的叶子证书（因为中间 CA 有 keyCertSign 权限），从而影响所有可信的叶子证书——攻击者可用泄露的私钥签发并冒充任意服务。因此需紧急处理：将泄露的中间 CA 证书加入 CRL/OCSP 撤销列表，客户端检测到中间 CA 被撤销则拒绝其下的所有叶子证书；同时用新的中间 CA（或根 CA）重新签发所有叶子证书，并更新服务器证书链。客户端根证书更新路径：若中间 CA 被撤销，需确保客户端信任链不含已撤销的中间 CA，必要时把新的中间 CA 正常分发；若根 CA 本身也受影响则需替换根证书并分发到所有客户端。规划时应保留根密钥离线，中间 CA 用短期证书并频繁轮换，减少单点泄露影响。

中间 CA 是"签发权限的集中点"，泄露即影响其下所有叶子。缓解靠"撤销中间 CA + 用新中间 CA 再签发 + 客户端信任链更新"，且根密钥离线、中间 CA 短期化可缩小影响面。

• DV/OV/EV 的验证强度差异
• EV 绿色标识的弱化
• 剩余的实际意义

DV（Domain Validation）只验证域名控制权，签发快、成本低，但无法验证实体身份；OV（Organization Validation）验证组织的真实存在与合法性，证书含组织名称；EV（Extended Validation）进行最严格的组织身份验证，证书含组织名称且历史上浏览器显示绿色地址栏。浏览器逐步弱化 EV 绿色标识（Chrome 等不再显示绿色地址栏，改为普通锁图标），因为绿条/绿标给人造成错误的安全感，且 EV 的额外验证对"加密通信"本身无增益。EV 剩余的实际意义：虽不再有显著 UI 殊荣，但 EV 的严格身份验证仍可用于某些信任场景（如金融机构、政府要求、特定应用对组织的强校验），部分应用仍可通过证书的 organizationName 与 EV OID 做程序化身份判断，作为"该主体确实经过严格验证"的佐证。

验证强度排序：DV < OV < EV。EV 的绿色标识弱化后，价值从"用户可见的信誉标识"转向"程序可用的严格身份验证"，对安全敏感场景仍有意义。