# 1. 画出 TLS 1.3 的 1-RTT 完整握手消息序列（ClientHello→ServerHello+EncryptedExtensions+Certificate+CertificateVerify+Finished→(Finished)），并指出每条消息的加密时机？ A 服务器所有握手消息在 ServerHello 之后均用 handshake traffic secret 加密 ✓ 正确答案 B ClientHello 用服务器公钥加密后发送，保证机密性 C ServerHello 之后的服务器握手消息全部用 early data 密钥加密 D Finished 消息使用 application traffic secret 加密
# 2. 解释 TLS 1.3 为什么废弃了静态 RSA 密钥交换、密码套件协商、压缩，且仅保留 AEAD 模式（共 5 个注册套件，强制实现 TLS_AES_128_GCM_SHA256）？ A 密码套件协商被保留以支持更多算法组合 B TLS 1.3 保留压缩以节省带宽 C AEAD 模式被移除，改用 CBC 模式 D 静态 RSA 因无前向保密且存在 padding oracle 风险被移除 ✓ 正确答案
# 3. 解释 TLS 1.3 ClientHello 中 key_share、signature_algorithms、supported_versions、psk_key_exchange_modes 这四个扩展的工程语义？ A key_share 用于声明客户端支持的证书签名算法 B psk_key_exchange_modes 中的 psk_dhe_ke 可提供前向保密 ✓ 正确答案 C supported_versions 只允许声明一个版本 D signature_algorithms 用于提供 ECDHE 公钥
# 4. TLS 1.3 证书压缩（RFC 8879）如何协商压缩算法并减少握手体积？ A 证书压缩对象是客户端提交的机密数据，防 CRIME 是首要目标 B 压缩通过 ClientHello 的 certificate_compression_algorithms 扩展协商算法 ✓ 正确答案 C 压缩必然被服务器强制使用，客户端无法拒绝 D 证书压缩只支持 zlib 一种算法
# 5. TLS 记录层分片与最大记录大小约束如何影响大消息传输？ A 记录层不限制大小，一条记录可承载任意大消息 B 单个记录明文上限为 2^14+1 字节，超限消息需分片 ✓ 正确答案 C 分片只影响应用数据，不影响握手消息 D 记录层分片会破坏 AEAD 的完整性校验
# 6. TLS 1.3 密码套件命名 TLS_AES_128_GCM_SHA256、TLS_CHACHA20_POLY1305_SHA256 中 SHA256 部分仅用于 HKDF 而非 MAC 的工程原因？ A SHA256 仅用于 HKDF 密钥派生与 transcript hash ✓ 正确答案 B SHA256 用作数据 MAC 以校验完整性 C SHA256 用于 ECDH 密钥交换 D SHA256 决定证书签名算法
# 7. 为什么 TLS 1.3 在 Finished 消息中采用 HMAC 而不是 AEAD？请从 Finished 是握手最后一条受保护消息的角度说明？ A 它通过 HMAC 使用 handshake traffic secret 计算 transcript 摘要 ✓ 正确答案 B 它用 AEAD 加密握手消息内容 C 它不参与 resumption 密钥派生 D 它用 application traffic secret 保护
# 8. 解释 TLS 1.3 为什么在每个阶段都引入 derive_secret 函数和 transcript hash 上下文绑定，避免密钥重用？ A derive_secret 结果只依赖 PSK，与 transcript 无关 B transcript hash 仅用于证书校验 C 各阶段秘密可以安全复用同一密钥 D Label 与 transcript hash 共同绑定密钥，避免跨阶段重用 ✓ 正确答案
# 9. TLS extended_master_secret（RFC 7627）在 TLS 1.2 中绑定 master secret 与 handshake transcript 的工程原因？ A 它把 master secret 绑定到完整握手 transcript 以防跨会话重用 ✓ 正确答案 B 它让 master secret 只依赖两个 random 值 C 它移除了 session resumption 功能 D 它只影响 TLS 1.3 的密钥派生
# 10. 解释 TLS 1.3 0-RTT 模式下 early_data 的 single-use server ticket 与 max_early_data_size 字段如何限制重放？ A 0-RTT 数据完全免疫重放攻击 B max_sent 字段由服务器在握手中强制改变 C single-use ticket 使 PSK 只能成功恢复一次，配合 max_early_data_size 限制重放量 ✓ 正确答案 D 重放风险仅影响握手，不影响早数据
# 11. draft-ietf-tls-esni-17 中 Encrypted Client Hello（ECH）的 ECHClientHello.client_hello_inner/outer 分层加密如何隐藏 SNI？ A outer 包含真实 SNI，inner 只含 public_name B ECH 使中间人能看到真实 SNI C ECH 只影响证书验证，不影响 SNI D outer 用 public_name 与 ECH 公钥加密内层，隐藏真实 SNI ✓ 正确答案
# 12. TLS 1.3 相对 1.2 如何把完整握手压缩到 1-RTT，又如何在何种前提下支持 0-RTT 早期数据？ A 1.3 完整握手仍需要 2-RTT B 1-RTT 靠客户端预先生成 key_share 实现，0-RTT 靠预先持有 PSK 实现 ✓ 正确答案 C 0-RTT 不依赖任何先前会话 D 0-RTT 提供完整前向保密
# 13. (EC)DHE 密钥协商为何能为 TLS 1.3 提供完美前向保密（PFS），静态 RSA 密钥交换为何被彻底移除？ A 静态 RSA 提供前向保密，因为 premaster 用临时密钥加密 B ECDHE 的一次性临时密钥保证了 PFS，即使长期私钥泄露历史流量仍安全 ✓ 正确答案 C ECDHE 不提供前向保密 D TLS 1.3 保留静态 RSA 作为可选密钥交换
# 14. 0-RTT 早期数据为何天然存在重放风险，应用层需要满足什么幂等条件才能安全使用？ A 0-RTT 数据因为密钥新随机值而天然防重放 B 重放风险可通过更换加密算法彻底消除 C 只有幂等、无副作用的操作才适合放入 0-RTT 数据 ✓ 正确答案 D 0-RTT 适合所有业务请求
# 15. TLS 1.3 为何只保留 AEAD 类密码套件并移除 CBC、RC4、压缩等机制，攻击面如何被收窄？ A TLS 1.3 保留 CBC 模式以兼容旧实现 B 移除压缩消除了 CRIME 类侧信道攻击 ✓ 正确答案 C RC4 仍作为可选套件保留 D AEAD 只提供机密性不提供完整性
# 16. 为何 TLS 1.3 从 ServerHello 之后即对握手消息加密，相比 1.2 隐藏了哪些元数据？ A 加密握手消息不影响隐私 B TLS 1.3 仍明文传输证书 C TLS 1.3 从 ServerHello 之后即加密握手消息，隐藏证书与扩展元数据 ✓ 正确答案 D TLS 1.2 也从 ServerHello 后就加密握手
# 17. TLS 1.3 的 key_share、supported_versions 与 Finished 如何完成版本协商和握手认证？ A supported_versions 只选择版本，不参与降级防护 B Finished 不参与握手认证 C key_share 提供 ECDHE 密钥材料，Finished 认证握手 transcript ✓ 正确答案 D 版本协商由 key_share 完成
# 18. 0-RTT 数据为何可被重放，服务端应如何限制可提前执行的业务操作？ A 0-RTT 数据因密钥特殊而无法重放 B 支付类请求适合放在 0-RTT 中 C 服务端应只允许幂等无副作用操作进入 0-RTT，并配合 anti-replay 缓存 ✓ 正确答案 D 0-RTT 重放无法被任何手段缓解
# 19. TLS 1.2 的 RSA 密钥交换为何在 1.3 中被移除，PFS（完美前向保密）为何成为强制要求？ A RSA 长期私钥泄露会解密历史会话，故被移除，PFS 成为强制 ✓ 正确答案 B RSA 密钥交换提供 PFS，因 premaster 用临时密钥 C TLS 1.3 仍允许 RSA 密钥交换 D PFS 只影响证书校验不影响密钥
# 20. 跨域 HTTPS 启用 HSTS preload 后浏览器首次访问为何仍依赖首次请求，预加载名单更新机制是什么？ A HSTS 头能保护所有首次访问，无需 preload B preload 名单可即时撤回 C preload 名单通过 hstspreload.org 提交并随浏览器版本分发，首次访问仍依赖首次请求 ✓ 正确答案 D preload 使域名强制支持 HTTP
# 21. ACME 协议（RFC 8555）的 HTTP-01、DNS-01、TLS-ALPN-01 挑战类型在通配符、CDN 后置场景下如何选择？ A HTTP-01 能签发通配符证书 B DNS-01 通过 TXT 记录验证，支持通配符且适合 CDN 后置场景 ✓ 正确答案 C TLS-ALPN-01 不依赖 443 端口 D 所有挑战类型都等价
# 22. 企业私有 PKI（AD CS、CFSSL、Vault PKI）签发跨域证书链时如何同步根证书到所有客户端？ A 根证书只需安装到服务器，无需客户端信任 B 域内可用 GPO 自动推送根证书，非域环境需通过配置管理写入信任库 ✓ 正确答案 C 客户端信任中间证书即可，无需根证书 D 私有根证书必须公开到公共 CA
# 23. CRL 分发点（CRL DP）与 OCSP responder URL 在证书链中的位置差异，离线/缓存策略如何协同？ A CRL DP 指向在线查询单张证书状态的服务器 B OCSP stapling 不提供任何时效性 C CRL 与 OCSP 是完全互斥的机制 D OCSP responder URL 在 AIA 扩展中，OCSP 不可用时可用 CRL 缓存兜底 ✓ 正确答案
# 24. 记录层 nonce 如何由序列号与静态 IV 构造，密钥更新为何必须保持收发方向独立？ A 密钥更新只更新一个方向 B 收发方向共享同一密钥，序列号共用 C AEAD nonce 由静态 IV 与记录序列号构造，避免同一密钥下 nonce 重用 ✓ 正确答案 D nonce 可以任意重复
# 25. 线上出现握手失败时，如何区分 SNI、ALPN、证书链、签名算法与密钥份额不兼容？ A SNI 不匹配通常表现为证书验证失败 B key_share 不匹配不会触发 HelloRetryRequest C 所有握手失败都源于证书链问题 D ALPN 不兼容表现为握手成功但应用层无匹配协议 ✓ 正确答案
# 26. 当浏览器发现证书链包含 SHA-1 根或弱签名算法时，是否会回退到更低版本协议，回退路径的安全代价是什么？ A 现代浏览器直接拒绝 SHA-1 等弱签名证书，而非回退到低版本协议 ✓ 正确答案 B 浏览器发现 SHA-1 证书会自动回退到 TLS 1.0 C 弱签名证书可通过回退到 TLS 1.2 安全解决 D TLS 1.2 的降级防护比 TLS 1.3 更强
# 27. 路径构建与路径验证有何区别，交叉签名为何可能产生多条候选证书链？ A 路径构建是验证证书链上每条签名是否有效 B 交叉签名会生成多条候选链，路径验证需按约束筛选出唯一正确链 ✓ 正确答案 C 路径验证与路径构建完全等价 D 交叉签名只会产生一条链
# 28. RSA-PSS、Ed25519、Ed448、ECDSA P-256 在证书签名性能、密钥大小与硬件兼容性上的取舍是什么？ A RSA-PSS 密钥小、兼容性最好 B ECDSA P-256 在性能与生态兼容上取得较佳平衡，是 Web 主流 ✓ 正确答案 C Ed25519 拥有最广泛的硬件加速支持 D Ed448 密钥最小性能最优
# 29. Let's Encrypt 默认证书有效期 90 天的设计动机，自动续期与监控告警应在哪些关键节点布置？ A 90 天是为了兼容旧浏览器 B 短有效期无法自动化 C 90 天有效期不需要自动续期 D 短有效期限制私钥泄露影响，并推动自动续期，告警应布置在到期前续期阶段 ✓ 正确答案
# 30. 解释 TLS 1.2 握手阶段 cipher suite 协商为什么要求 server 发送 ServerHello 而非 HelloRetryRequest？ A TLS 1.2 用 HelloRetryRequest 协商 cipher suite B TLS 1.2 也支持 HelloRetryRequest C HelloRetryRequest 是 TLS 1.3 机制，用于请求重发 key_share，TLS 1.2 用 ServerHello 直接选择套件 ✓ 正确答案 D HelloRetryRequest 用于协商证书
# 31. TLS 1.2 的 CBC 模式（TLS_RSA_WITH_AES_128_CBC_SHA）为什么需要 MAC-then-Encrypt 或 Encrypt-then-MAC 的工程教训？ A MAC-then-Encrypt 加密更安全，因先认证后加密 B TLS 1.3 仍使用 MAC-then-Encrypt C CBC 模式不存在 padding oracle 风险 D Encrypt-then-MAC 先验证 MAC 再解密，避免 padding oracle 泄露 ✓ 正确答案
# 32. TLS_RSA_WITH_AES_128_GCM_SHA256 在 TLS 1.2 中为什么存在 Bleichenbacher 类 padding oracle 风险，以及现代实现的缓解？ A 攻击利用 padding 校验失败与成功的行为差异来推断 premaster secret ✓ 正确答案 B TLS 1.3 仍存在该风险 C 现代缓解是让 padding 校验失败时返回详细错误 D 该攻击与 RSA 密钥交换无关
# 33. TLS 1.3→1.2 版本降级攻击（downgrade dance）由 supported_versions fallback 字段如何检测？ A 服务器在 ServerHello.random 写入降级哨兵值，客户端据此识别强制降级 ✓ 正确答案 B 降级攻击无法被检测 C 降级只影响 1.3 到 1.2，不影响 1.2 到 1.1 D supported_versions 不参与降级检测
# 34. 解释 TLS 1.3 application_settings（ALPS）与 ALPN（h2、http/1.1）扩展在 QUIC 与 TCP 上的工程语义差异？ A ALPN 与 ALPS 完全等价 B ALPN 协商应用协议，ALPS 在握手阶段携带应用层参数以省去额外往返 ✓ 正确答案 C ALPS 只用于 QUIC，不用于 TCP D ALPN 在握手后仍无法确定协议
# 35. 解释 OCSP stapling（status_request_v2）与 OCSP multi-staple 在 TLS 握手阶段的工程价值与延迟节省？ A 客户端在握手后仍需在线查询 OCSP B multi-staple 只附带一张证书的响应 C 服务器在握手时附带预取的 OCSP 响应，省去客户端在线查询往返 ✓ 正确答案 D stapling 会向 CA 暴露客户端访问的站点
# 36. 解释 TLS 1.3 CertificateRequest 中 signature_algorithms 与 certificate_authorities 扩展对 mTLS 客户端证书选择的引导？ A CertificateRequest 只在客户端发起时出现 B signature_algorithms 声明客户端可用的证书 C certificate_authorities 声明服务端信任的 CA，客户端据此筛选证书 ✓ 正确答案 D 客户端证书选择与扩展无关
# 37. TLS 1.3 后量子混合密钥交换 X25519MLKEM768 在 draft-ietf-tls-ecdhe-mlkem 中的工程部署流程？ A 它只使用后量子算法，不用经典算法 B 混合后只需保留一方密钥 C 它把 X25519 与 ML-KEM-768 的共享密钥混合，抵御量子攻击 ✓ 正确答案 D ML-KEM 不增加 key_share 体积
# 38. 解释 TLS 1.3 false start 与 0-RTT 在节省 1-RTT 延迟上的工程取舍及兼容性？ A false start 比 0-RTT 更早发数据 B 0-RTT 在首次消息时就发数据，延迟最优但有重放风险且无 PFS ✓ 正确答案 C 0-RTT 提供完整前向保密 D 两者都无需应用层幂等处理
# 39. 解释 TLS session resumption 在 CDN 边缘的跨数据中心同步策略，ticket key 轮换与多机房如何设计？ A 无状态 resumption 需跨机房同步会话状态 B 边缘节点共享 ticket key 解密自包含 ticket，并定期轮换 key 以平衡安全与可用性 ✓ 正确答案 C ticket key 永不需要轮换 D resumption 只在同机房节点可用
# 40. 解释 TLS early data 的大小限制通常为 16KB，由 max_early_data_size 字段控制的工程意义？ A max_early_data_size 只影响 1-RTT 数据 B 客户端可任意扩大 early data 大小 C 16KB 限制与重放无关 D max_early_data_size 由服务端声明，限制 0-RTT 数据量以收敛重放影响面 ✓ 正确答案
# 41. TLS 握手延迟在 4G 网络与 Wi-Fi 6E 的 RTT 分布差异下，0-RTT 收益如何被建模？ A Wi-Fi 6E 上 0-RTT 收益最大 B 0-RTT 在所有网络收益相同 C 0-RTT 收益与 RTT 无关 D 0-RTT 收益 = 节省的 RTT 数 × RTT，高 RTT 网络（4G）收益更显著 ✓ 正确答案
# 42. HelloRetryRequest 在 TLS 1.3 中由 server 选择的 named_group 发起，对 client key_share 缺失的工程容错是什么？ A 客户端收到 HelloRetryRequest 后无需响应 B HelloRetryRequest 用于协商证书 C 服务器把自己选择的 named_group 放入 HelloRetryRequest，客户端据此重发 key_share ✓ 正确答案 D HelloRetryRequest 增加一个完整握手
# 43. TLS 1.3 PSK 与 TLS 1.2 Session Tickets 在跨会话密钥派生上的根本差异？ A TLS 1.3 的 PSK 恢复与 1.2 完全一样 B TLS 1.2 ticket 同样绑定新握手 transcript C TLS 1.3 的 PSK 通过统一 key schedule 并用 transcript 绑定派生，支持 psk_dhe_ke 提供 PFS ✓ 正确答案 D TLS 1.3 PSK 无法提供前向保密
# 44. TLS 1.2 SessionTicket 与 TLS 1.3 NewSessionTicket 在 ticket lifetime、anti-replay 机制上的兼容性工程？ A TLS 1.3 ticket 无 lifetime 限制 B TLS 1.2 ticket 与 1.3 ticket 可完全混用 C TLS 1.3 NewSessionTicket 引入 stronger anti-replay（single-use），并通过 ticket_lifetime 声明有效期 ✓ 正确答案 D 1.2 ticket 天然支持 anti-replay
# 45. TLS 1.3 的 session ID 兼容模式（middlebox compatibility）为何要伪装成 TLS 1.2 会话？ A 兼容模式会破坏 TLS 1.3 安全性 B 它让 TLS 1.3 真正降级到 TLS 1.2 C 它只影响客户端，不影响服务器 D 它通过伪 session ID 与空 ChangeCipherSpec 让中间盒误认为 TLS 1.2 会话以兼容 ✓ 正确答案
# 46. TLS 1.3 的 key schedule 如何从握手秘密逐级派生 handshake/application traffic secret，HKDF 在其中扮演什么角色？ A 各阶段 traffic secret 直接复用 ECDHE 共享密钥 B HKDF 只用于证书校验 C HKDF-Extract 压缩熵、HKDF-Expand 用 Label 与 transcript 扩展出各阶段 traffic secret ✓ 正确答案 D HKDF 不参与 application traffic secret 派生
# 47. 会话恢复在 TLS 1.3 中如何统一为 PSK 机制，session ticket 与外部 PSK 有何区别？ A 外部 PSK 由服务器自动签发 B session ticket 与外部 PSK 完全等价 C TLS 1.3 恢复不再使用 PSK D session ticket 由服务器从 resumption_master_secret 派生用于恢复，外部 PSK 由带外静态配置 ✓ 正确答案
# 48. HelloRetryRequest 在客户端提供的 key_share 不被服务端接受时如何避免额外往返浪费？ A HRR 与 key_share 无关 B 客户端收到 HRR 后必须完全重新握手 C HRR 总是发生，每次握手都额外一次往返 D 客户端收到 HRR 后仅重发 key_share，用一次额外往返恢复协商而非完整重握手 ✓ 正确答案
# 49. 在 Kubernetes 中以 cert-manager 自动化证书生命周期时，Secret 命名空间分发与镜像仓库信任链应如何联动？ A 镜像仓库信任链与 cert-manager 无关 B Secret 全局共享，无需处理命名空间 C Secret 是命名空间隔离的，跨命名空间需复制；仓库根证书需注入节点信任库，两条信任链需联动 ✓ 正确答案 D 节点拉取镜像不校验仓库证书
# 50. TLS 1.3 的 key schedule 如何从 PSK/DHE/PSK+DHE 派生 Early Secret、Handshake Secret 与 Master Secret？ A Early Secret 从 PSK 派生，Handshake Secret 从 ECDHE 共享密钥派生，PSK+DHE 模式提供 PFS ✓ 正确答案 B 纯 PSK 模式包含 ECDHE C Master Secret 在握手前就派生 D DHE 模式无 PSK 参与且无前向保密
# 51. ClientHello 的 SNI、ALPN、supported_groups、signature_algorithms 各自传达什么能力信息，服务端如何回退？ A supported_groups 声明签名算法 B ALPN 用于指示域名 C SNI 提供目标域名，ALPN 声明应用协议，服务端按各扩展选择并合理回退 ✓ 正确答案 D 服务端无法对不匹配的扩展回退
# 52. OCSP must-staple 扩展如何强制服务端提供 OCSP response，缺失时浏览器如何处理？ A Must-Staple 只影响服务器不生成证书 B Must-Staple 使证书无需撤销检查 C 缺失时浏览器总是回退到 HTTP D 它强制服务器在握手时提供 OCSP 响应，缺失时浏览器可能拒绝连接 ✓ 正确答案
# 53. 当客户端持有旧会话票据（Session Ticket）但服务端已轮换密钥，握手如何继续且保证前向保密？ A 轮换后 PFS 被破坏 B 旧 ticket 永不能恢复 C 旧 ticket 无法解密时回退到 ECDHE 完整握手，前向保密由 ECDHE 保证 ✓ 正确答案 D 服务端应永久保留旧 key
# 54. CT（Certificate Transparency）日志、SCT 嵌入与 Chrome 的 CT 策略如何影响证书申请与部署流程？ A SCT 是可选的，浏览器不要求 B CA 签发证书时提交日志获得 SCT，Chrome 的 CT 策略要求证书携带足够 SCT 才被信任 ✓ 正确答案 C CT 日志由客户端本地生成 D SCT 只嵌入 OCSP 响应，不嵌入证书
# 55. SAN、Name Constraints、Key Usage、Extended Key Usage 如何共同限制证书用途？ A Key Usage 决定证书域名 B SAN 决定 CA 能签发哪些子证书 C Name Constraints 限制 CA 签发的子证书名称范围，Key Usage 限制私钥用途，EKU 限制证书应用用途 ✓ 正确答案 D EKU 限制证书名称
# 56. 服务网格中的 mTLS 如何借助 SPIFFE/SPIRE 的 SPIFFE ID 与短期 SVID 证书实现工作负载身份与自动轮换？ A 服务网格 mTLS 不依赖 SPIFFE B SVID 证书是长期静态的 C SPIFFE ID 只是任意字符串，不与证书绑定 D SPIFFE ID 是统一工作负载身份，SPIRE 签发短期 SVID 证书并自动轮换，用于 mTLS 双向认证 ✓ 正确答案
# 57. OCSP stapling、CRL 与短生命周期证书如何平衡撤销及时性、隐私和可用性？ A CRL 是即时、单张的撤销查询 B OCSP stapling 兼顾及时性与隐私，短生命周期证书把撤销简化为到期失效 ✓ 正确答案 C 短生命周期证书无法自动更新 D OCSP stapling 会向 CA 暴露客户端站点
# 58. 大规模 CDN 下 OCSP stapling 可能因回源失败而缺失，客户端在 must-staple 与软失败之间应如何兜底？ A must-staple 缺失时客户端总是软失败 B CDN 用预取缓存与多源回源提高 stapling 可用率，客户端按 must-staple 或软失败策略权衡 ✓ 正确答案 C stapling 缺失对 CDN 无影响 D 客户端应总是硬失败
# 59. 轮换服务证书时，如何处理旧会话恢复、链文件顺序、私钥权限与灰度回滚？ A 私钥权限对轮换无关 B 轮换后旧会话立即全部失效 C 链文件顺序不影响握手 D 保留旧 ticket 解密窗口、保证链文件顺序与私钥权限，并灰度发布可回滚 ✓ 正确答案
# 60. 画出 TLS 1.3 HKDF-Extract/Label-Expand 派生链（PSK→Early Secret→Binder Key→Client/Server Handshake Traffic Secret→Master Secret→Application Traffic Secret），并标注每一步的 HKDF Label？ A Application Traffic Secret 由 Handshake Secret 直接派生 B Binder Key 由 Early Secret 派生，Handshake Traffic Secret 由 Handshake Secret 用 "c/s hs traffic" Label 派生 ✓ 正确答案 C Master Secret 在握手前派生 D Binder Key 由 Master Secret 派生
# 61. 解释 TLS 1.3 resumption_master_secret 与 ticket 派生链的关系，NewSessionTicket 如何只携带 resumption_master_secret 派生出的 ticket？ A resumption_master_secret 与握手无关 B ticket 直接包含主密钥 C NewSessionTicket 携带的是服务端加密的会话凭证，客户端不直接持有 resumption_master_secret ✓ 正确答案 D ticket 不由 resumption_master_secret 派生
# 62. TLS 1.3 update_traffic_key 在密钥更新（key_update）消息中的工程作用与最大 2^24 次限制？ A 密钥更新无任何次数限制 B KeyUpdate 必须重新握手 C KeyUpdate 不重置序列号 D KeyUpdate 通过 HMAC 派生新 traffic secret 更新密钥，且同一方向有 2^24 次更新上限 ✓ 正确答案
# 63. 为什么 TLS 1.3 强制要求 KeyShare 在 client 侧预先生成，而不允许 server 选择 group 后再生成？ A 预生成 key_share 导致完整握手变 2-RTT B 服务器选组后再生成会更快 C 客户端预生成 key_share 使服务器立即派生密钥，实现 1-RTT/0-RTT ✓ 正确答案 D key_share 与延迟无关
# 64. 解释 TLS 1.3 的 external PSK（out-of-band）与 resumption PSK（session ticket）两类 PSK 及它们的 binder 计算差异？ A external PSK 与 resumption PSK 的 binder 完全一样 B external PSK 用 "ext binder" Label、resumption PSK 用 "res binder" Label 计算 binder 以区分 ✓ 正确答案 C binder 不需验证客户端持有 PSK D resumption PSK 是带外配置的
# 65. 为什么 0-RTT 不能保证 forward secrecy？请从 PSK 直接派生 early secret 而无 (EC)DHE 参与的密钥学角度说明？ A 0-RTT 的 early secret 由 PSK 直接派生、无 ECDHE 参与，故不提供前向保密 ✓ 正确答案 B 0-RTT 提供完整 PFS C 0-RTT 早期数据由 ECDHE 临时密钥加密 D PSK 泄露不影响 0-RTT 数据
# 66. 当 SCT（Certificate Transparency）嵌入位置从 TLS 扩展迁移到 X.509 扩展时，旧客户端的兼容性表现如何？ A X.509 嵌入不携带 SCT B 旧客户端一定支持任何嵌入位置 C X.509 嵌入让 SCT 随证书自带，但旧客户端可能不识别，需配合 TLS 扩展/OCSP 通道兼容 ✓ 正确答案 D 迁移后旧客户端必拒绝所有证书
# 67. 中间证书（intermediate）私钥泄露后为何会影响所有叶子证书，紧急再签发与客户端根证书更新路径如何规划？ A 中间 CA 泄露可伪造其下所有叶子证书，需撤销该中间 CA 并用新中间 CA 再签发叶子证书 ✓ 正确答案 B 中间 CA 泄露只影响一张叶子证书 C 撤销中间 CA 不影响其下证书 D 根密钥离线与中间 CA 泄露无关
# 68. EV、OV、DV 证书在身份验证强度上的差异是什么，浏览器逐步弱化 EV 绿色标识后验证等级还剩什么实际意义？ A EV 绿标弱化后完全无意义 B DV 验证组织身份 C EV 与 DV 验证强度相同 D DV 只验证域名，OV 验证组织，EV 做最严格验证；EV 绿标弱化后其价值转向程序化身份验证 ✓ 正确答案
