SSL会话票证与会话ID

Question

为了提高SSL握手性能而不保留(短)连接,有两个独立的功能已广为人知:

• TLS会话ID
• TLS会话门票

在很多短连接会话的情况下,哪种机制在性能开销方面是优选的并且应该使用？

我知道服务器需要缓存会话ID,会话票据在负载平衡的情况下也很容易共享,但我们假设有一个服务器在单个端口上监听(无负载平衡),并且它接收很多SHORT传入TLS连接会话.

那么在这种情况下,哪种方法(会话或门票)更可取？

Answer 1

当服务器发送"服务器Hello"消息时,它可以包括会话标识符.客户端应该存储它并将其显示在下一个会话的"Client Hello"消息中.如果服务器在其缓存中找到相应的会话并接受恢复会话,它将发回相同的会话标识符并继续使用缩写的SSL握手.否则,它将发出新的会话标识符并切换到完全握手.这种机制在RFC 5246中有详细说明.它是最常见的机制,因为它存在于早期版本的SSL之后.

在完全SSL握手的最后一次交换中,服务器可以包括"新会话票证"消息(未在图中描述的握手中表示),其将包含完整的会话状态(包括客户端与客户端之间协商的主秘密).服务器和使用的密码套件).因此,该状态由仅由服务器知道的密钥加密和完整性保护.此不透明数据称为会话票证.详细信息在RFC 5077中,后者取代了RFC 4507.

票证机制是TLS扩展.客户端可以通过在"Client Hello"消息中发送空的"Session Ticket"扩展来通告其支持.如果服务器支持,服务器将在其"服务器Hello"消息中回答空的"Session Ticket"扩展.如果其中一个不支持此扩展,则它们可以回退到SSL内置的会话标识符机制.

RFC 5077确定了票据优于会话标识符的情况.主要的改进是避免维护服务器端会话缓存,因为客户端而不是服务器会记住整个会话状态.会话高速缓存在内存方面成本高,并且当跨服务器进行负载平衡请求时,难以在多个主机之间共享.

Answer 2

使用session-id,服务器需要跟踪以前可以在某个时间点继续的会话.这导致服务器必须执行的一些额外工作.

相反,会话票证不是标识符,而是由服务器加密的会话数据(并且只有服务器可以对其进行解密).当客户端希望继续会话时,它仍然知道预主密钥,但服务器不再知道.因此,客户端将会话票证发送到服务器,只有服务器能够解密其内容.继续会话所需的任何信息都包含在那里,因此服务器可以在不保留任何信息的情况下恢复会话.所有额外的负载都在客户端完成(通过保留pre-master secret和session-ticket).

Answer 3

在这种情况下，您只需要会话 ID，它们内置于大多数 SSL 实现中，这与 RFC 5077 票务不同，后者仍然是 TLS 扩展。