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扩展。