某支付接口计划使用 TLS 1.3 的 0-RTT Early Data 降低重复连接延迟。安全评审认为转账请求不应直接放在 0-RTT 数据中，主要原因是（）。
0-RTT 早期数据可以加密，但协议层无法在所有部署条件下天然保证每份早期数据只被接受一次。若转账、下单等非幂等操作被重放，可能产生重复业务影响。
选项分析
错误。0-RTT 早期数据仍受会话密钥保护，核心风险不是明文，而是可能被重放。
正确。非幂等请求若被重复接受，可能造成重复扣款、重复下单等业务后果。
错误。TLS 握手仍会完成服务器身份认证，0-RTT 的主要限制不是自动取消认证。
错误。协议不按图片或业务参数划分数据，限制来自安全语义而不是文件类型。
本题为什么容易错
不少同学看到 TLS 就默认“加密以后什么攻击都解决了”。TLS 解决传输机密性和完整性，但 0-RTT 是否可重放还要单独判断。
简短答案
TLS 1.3 的 0-RTT Early Data 为什么不适合直接执行转账，正确答案是 B（攻击者可能重放已捕获的早期数据，使非幂等操作被重复执行）。0-RTT 早期数据可以加密，但协议层无法在所有部署条件下天然保证每份早期数据只被接受一次。若转账、下单等非幂等操作被重放，可能产生重复业务影响。
易混淆概念对比表
| 概念 | 本题判断 | 区别要点 | 记忆提示 |
|---|---|---|---|
| 0-RTT 数据一定使用明文传输 | 本题干扰项 | 错误。0-RTT 早期数据仍受会话密钥保护，核心风险不是明文，而是可能被重放。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 攻击者可能重放已捕获的早期数据，使非幂等操作被重复执行 | 本题正确答案 | 正确。非幂等请求若被重复接受，可能造成重复扣款、重复下单等业务后果。 | 看到题干核心场景时优先联想到它 |
| 0-RTT 会自动关闭服务器身份认证 | 本题干扰项 | 错误。TLS 握手仍会完成服务器身份认证，0-RTT 的主要限制不是自动取消认证。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
| 0-RTT 只允许传输图片，不能传输业务参数 | 本题干扰项 | 错误。协议不按图片或业务参数划分数据，限制来自安全语义而不是文件类型。 | 看到该词不要急着选，先判断是否真正解决题干问题 |
本题易混淆选项怎么区分
- 0-RTT 数据一定使用明文传输：错误。0-RTT 早期数据仍受会话密钥保护，核心风险不是明文，而是可能被重放。
- 0-RTT 会自动关闭服务器身份认证：错误。TLS 握手仍会完成服务器身份认证，0-RTT 的主要限制不是自动取消认证。
- 0-RTT 只允许传输图片，不能传输业务参数：错误。协议不按图片或业务参数划分数据，限制来自安全语义而不是文件类型。
知识点详解
TLS 1.3 的 Early Data 允许客户端基于先前会话恢复信息，在握手完全结束前发送应用数据。它能减少延迟，但早期数据的唯一性难以在所有分布式部署中得到强保证。服务端通常应限制可接受的请求类型、设置反重放窗口或共享状态，并让转账、创建订单等高风险操作走完整握手或使用可靠的业务幂等机制。0-RTT 被禁用并不会影响普通 1-RTT TLS 连接的安全通信。
备考速记
0-RTT 省的是往返时间，不自动省掉重放风险。
TLS 1.3 在Early Data场景中的作用
TLS 1.3在本题中的核心价值，是解决“某支付接口计划使用 TLS 1.3 的 0-RTT Early Data 降低重复连接延迟。安全评审认为转账请求不应直接放在 0-RTT 数据中，主要原因是（）”这个场景问题。复习时不要只背选项名称，还要理解它为什么适用于该场景，以及它能解决哪类安全、流程或管理问题。
同类题怎么考
- 判断哪些接口适合使用 0-RTT。
- 比较加密、防篡改、防重放和幂等分别解决什么问题。
TLS 1.3 在信息安全工程师软考中的考法
软考选择题通常不会只考概念定义，还会把TLS 1.3放到Early Data场景中，要求判断它的作用、适用范围或与相近概念的区别。遇到这类题时，先抓住题干中的业务场景，再看哪个选项最能解决该场景下的核心问题。
解题思路
这道题要抓“转账”两个字。0-RTT 的价值是客户端在恢复会话时提前发送数据，少等一次往返；代价是服务端接收早期数据时，对重放的防护条件更苛刻。查询商品这类幂等操作被重复一次，业务结果通常不变；转账重复一次，后果就完全不同。所以工程上要限制 Early Data 的用途，并在业务层继续做幂等和防重放。
考点定位
不要把机密性和防重放混为一谈。数据已加密，只能说明旁观者不易看懂，并不等于同一份合法密文不能再次提交。
易错提醒
- 把带副作用的 POST 请求全部允许使用 Early Data。
- 只依赖边缘节点去重，没有考虑多节点、时间窗口和状态同步。
- 认为业务幂等可以替代所有协议层重放缓解措施。
备考提示
- 复习时把查询、修改、转账三个请求按重复执行后果分类。
- 看到 0-RTT 时同时想到低延迟、会话恢复、重放风险和幂等限制。
你可能还想了解
- TLS 1.3 的 0-RTT 数据是否加密？
- 哪些 HTTP 请求适合使用 Early Data？
- 业务幂等和协议防重放有什么区别？
本文小结
TLS 1.3的0-RTT早期数据可以加密，但可能被重放。查询类幂等请求风险较低，转账、下单等非幂等操作不宜直接使用，仍需完整握手和业务防重。