摘要

  • TLS 会话票据把恢复连接所需的状态装进客户端代持的不透明对象。客户端拥有保管和出示的机会，但服务器仍掌握解释、验真、更新和拒绝的权力。
  • “无服务器端状态”只免去了逐客户端查表，并未消灭服务器状态。票据保护密钥、有效期和跨节点共享边界更小，却可能支配更多历史会话。

一张不在柜子里的档案

传统会话恢复像寄存柜。第一次 TLS 握手结束后，服务器留下档案，再给客户端一个号码。客户端回来时报出号码，服务器从柜中找到原来的密码参数，省去完整协商。

RFC 5246 对 TLS 1.2 的描述正是如此：会话是一组可供多个连接复用的密码安全参数，会话标识符由服务器产生，用来指向仍然活跃或可恢复的状态。这个办法节省握手成本，却要求服务端保存、老化、失效和定位每条记录。

当连接可能落到不同机器，柜子就成了分布式问题。运营者要共享缓存、把客户端黏在某个节点，或者接受恢复失败。负载均衡并没有让记忆消失，只改变了寻找它的路线。

2006 年的 RFC 4507 提出了另一种安排：服务器把会话状态密封进票据，交给客户端保存。2008 年的 RFC 5077 取代前者，并强化了推荐的保护方式。客户端不再只带回柜门号码，而是带回服务器自己的加密档案。

携带并不等于拥有解释权

RFC 5077 要求客户端把票据视为不透明数据。推荐结构包含密钥名称、初始向量、加密状态和完整性校验。密文中可以包括密码套件、主秘密、时间戳及最初客户端认证的相关信息。

这里有两层边界。加密防止代持者看到敏感内容，完整性保护防止它悄悄修改身份、权限或期限。客户端保存票据，也保存相关的主秘密和参数；再次连接时出示票据，并在简化握手中证明自己确实拥有所需秘密。

因此，偷到一份票据并不自动等于能恢复会话。反过来，一份有效票据也不是应用层的永久通行证。账户可能已经停用，角色可能撤销，交易可能结束。TLS 可以确认与旧密码状态的连续性，却不能替应用决定当下还能做什么。

服务器必须能平常地说“不”

服务器若无法验证票据，或不愿继续使用旧状态，可以退回完整握手。密钥轮换、重启、跨区落点和策略变化都可能造成这种结果。拒绝说明一次优化没有命中，不等于证书必然错误，也不应等同于服务故障。

这个退出通道决定了系统能否真正轮换。如果完整握手太脆弱，运营者就会害怕撤销旧密钥；如果客户端把票据当成承诺，服务器就会被过去的状态反向锁定。可预期的回退使旧票据成为可丢弃的提示，而不是基础设施债务。

更新票据也不能跳过确认。服务器在恢复过程中发出新票据，并不能立即假定客户端已经收到并采用。发送、完成握手、下次使用是三个事件。

少数密钥形成更大的控制面

“无状态恢复”省掉的是每个客户端一条记录。服务器仍需保存票据保护密钥、识别不同密钥代次、执行期限规则，并维持当前连接。状态从数量庞大的个体记录，收缩成少量共享秘密。

收缩会集中后果。同一密钥分发到许多服务器，任一节点就能接受其他节点发出的票据，跨机器恢复更加顺畅；但每个持钥节点也进入同一个泄露半径。把密钥限定在单个区域，能缩小风险，却会让跨区客户端更常走完整握手。

RFC 5077 建议票据密钥只用于票据、可靠生成并定期更换。RFC 9325 进一步要求定期轮换，在有效期结束后销毁旧密钥，并限制票据寿命。否则，一次短暂入侵可能获得过长的可恢复历史，削弱原握手所追求的前向保密。

票据上并不只有一只钟

TLS 1.2 票据向客户端给出寿命提示。客户端到期应删除，也可提前删除；服务器则可比提示更早或更晚拒绝。提示帮助客户端决定是否继续保存，却不是未来服务的预约。

实际至少存在三只钟：客户端理解的保存期限、服务器当前接受的期限、旧保护密钥仍然可用的期限。正常轮换可能让第二只钟提前停止；错误回滚或备份恢复可能让第三只钟死而复生。

只看票据字段而不看密钥生命周期，会把一个建议误认为完整控制。

密封不能修复错误的来源

恢复安全取决于最初会话把什么事实绑定进秘密。RFC 7627 说明，较早 TLS 的主秘密没有与足够的握手上下文加密绑定。主动攻击者可能让两个会话出现同步的秘密，进而破坏依赖秘密唯一性的认证和会话恢复。

扩展主秘密把派生过程绑定到握手记录的哈希。这个修复揭示了票据的证据边界：容器再牢固，也不能替一段含义不清的历史补写来源。先前协商必须正确，之后的可携带状态才有正确意义。

TLS 1.3 把票据变成 PSK 身份

RFC 8446 用预共享密钥重新组织恢复。主握手完成后，服务器可发送 NewSessionTicket，其中含寿命、年龄混淆值、nonce 和不透明票据。下次 ClientHello 出示该身份，并用 binder 证明拥有对应 PSK。

票据声明的寿命最多七天，客户端也不得保存更久。恢复还可以加入新的临时 Diffie–Hellman 交换。RFC 9325 在需要前向保密时建议 psk_dhe_ke，使新连接不必完全依赖旧 PSK。

0-RTT 是相邻但独立的选择。票据可以只用于普通 1-RTT 恢复。并非所有票据都是一次性，关闭早期数据也不会消除票据密钥的轮换责任。

密文仍可能留下可关联的外形

RFC 5077 要求隐藏票据内容，避免泄露用户相关信息；它同时警告，同一票据反复出现可能让路径上的观察者关联多次握手。RFC 9325 也把恢复造成的客户端追踪列为隐私问题。

看不懂一个对象，不代表认不出它。发行频率、是否复用、更新节奏和寿命共同决定隐私边界。

状态移动了，权力没有随之移动

票据把可恢复的逐客户端数据交给客户端携带，降低了服务器查表和缓存压力。客户端承担保管；服务器控制验真和接受；运营者控制密钥分布；应用继续控制授权。

票据不证明人的身份，不保证某一日期前必被接受，不天然一次性，也不说明服务器没有任何状态。它真正展示的是：状态的位置可以改变，而解释状态的权力仍可保持在原边界。前提是密钥范围、到期、销毁和完整握手出口都不能被隐藏。

来源与证据限制

官方协议记录包括 RFC 4507、RFC 5077、RFC 5246、RFC 7627、RFC 8446 和 RFC 9325。关于集群密钥边界与运营激励的判断来自这些机制，并非对某个厂商部署的统计。