跳到主要内容

附录 A. 对 RFC 4507 变更的讨论

RFC 4507 [RFC4507] 通过规定一个在客户端维护的加密票据, 定义了一种在不需要维护服务器端状态的情况下恢复 TLS 会话的机制。客户端在一个 SessionTicket hello 扩展中向服务器呈交该票据。RFC 4507 中的编码使用了 TLS [RFC4346] 中规定的 XDR 风格编码。

编码中的一个错误导致规范与已部署的实现不一致。在撰写本文时, 尚无已知实现遵循 RFC 4507 中规定的编码。对 RFC 4507 的此次更新使本文档与这些当前已部署的实现保持一致。

RFC 4507 中错误的编码导致出现了两个长度字段: 一个用于扩展内容, 另一个用于票据本身。因此, 对于一个长度为 256 字节、以十六进制值 FF FF 开头的票据, 按照 RFC 4507, 该扩展的编码将如下所示:

     00 23          Ticket Extension type 35
     01 02          Length of extension contents
     01 00          Length of ticket
     FF FF .. ..    Actual ticket

本文档提出的更新反映了实现实际编码的内容, 即去掉了冗余的长度字段。因此, 对于一个长度为 256 字节、以十六进制值 FF FF 开头的票据, 按照本次更新, 该扩展的编码将如下所示:

     00 23          Extension type 35
     01 00          Length of extension contents (ticket)
     FF FF .. ..    Actual ticket

一个按照 RFC 4507 实现的服务器, 若从符合本文档的客户端收到票据扩展, 会把该票据的前两个字节解释为该票据的长度。这会导致长度字段不一致, 或者导致处理一个缺少前两个字节的票据。在第一种情况下, 服务器应当基于长度畸形拒绝该请求。在第二种情况下, 服务器应当基于票据畸形、密钥版本不正确或解密失败而拒绝该票据。基于本次更新的服务器实现, 若收到一个 RFC 4507 扩展, 会把第一个长度字段解释为该票据的长度, 并把后面的两个长度字节作为票据的头两个字节, 结果该票据会因票据畸形、密钥版本不正确或解密失败而被拒绝。

请注意, 空 SessionTicket 扩展的编码在 RFC 4507 中是含糊的。一个 RFC 4507 实现可能将其编码为:

     00 23      Extension type 35
     00 02      Length of extension contents
     00 00      Length of ticket

也可能按照本次更新相同的方式对其编码:

     00 23      Extension type 35
     00 00      Length of extension contents

希望支持 RFC 4507 客户端的服务器, 应当以收到该空 SessionTicket 扩展时所用的相同编码来响应。

服务器实现可以这样构造票据: 在票据开头包含一个能够与合法长度区分开的 cookie, 从而能够检测出 RFC 4507 实现 (如果存在的话)。例如, 如果某个实现构造的票据以十六进制值 FF FF 开头, 那么它就能确定票据从哪里开始, 并根据所出现的长度字段类型正确地确定长度。

本文档对 RFC 4507 还做了如下一些附加变更。

  • 在 3.1 节中澄清: 服务器可以允许使用票据恢复会话, 而不签发新票据。

  • 在 3.3 节中澄清: 生命周期是相对于收到该票据的时刻的。

  • 在 3.3 节中澄清: NewSessionTicket 握手消息包含在为 Finished 消息生成的散列中。

  • 在 3.4 节中澄清与 TLS 会话 ID 的交互。

  • 在第 4 节中建议对票据的完整性保护使用 SHA-256。

  • 在第 4 节中澄清可以在 StatePlaintext 结构中包含附加数据。