SSL 会话票证与会话 ID [英] SSL session tickets vs session ids

问题描述

为了提高 SSL 握手性能而不保留(短)连接，有两个众所周知的独立功能:

To improve SSL handshake performance for not retaining(short) connections there are two separate features known widely:

• TLS 会话 ID
• TLS 会话门票

在非常多的短连接会话的情况下，就性能开销而言，哪种机制更可取并且应该使用?

In case of very many short connection sessions which mechanism in terms of performance overhead is preferable and should be used?

我知道服务器需要缓存会话 ID，在负载平衡的情况下也可以轻松共享会话票证，但让我们假设有一个服务器侦听单个端口(无负载平衡)并且它接收很多 SHORT 传入 TLS连接会话.

I know server need to cache session ids, also session tickets are easily shareable in case of load balancing, but let's assume there is a single server listening on a single port(no load balancing) and it receives very many SHORT incoming TLS connection sessions.

那么在这种情况下，哪种方法(会话或票证)更可取?

So which approach (sessions or tickets) is preferable given this scenario?

推荐答案

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

When the server sends the "Server Hello" message, it can include a session identifier. The client should store it and present it in the "Client Hello" message of the next session. If the server finds the corresponding session in its cache and accepts to resume the session, it will send back the same session identifier and will continue with the abbreviated SSL handshake. Otherwise, it will issue a new session identifier and switch to a full handshake. This mechanism is detailed in RFC 5246. It is the most common mechanism because it exists since earlier versions of SSL.

在完整 SSL 握手的最后一次交换中，服务器可以包含一个New Session Ticket"消息(图中描述的握手中没有表示)，该消息将包含完整的会话状态(包括双方协商的主密钥)客户端和服务器以及使用的密码套件).因此，此状态由只有服务器知道的密钥进行加密和完整性保护.这个不透明的数据被称为会话票证.详细信息位于取代 RFC 4507 的 RFC 5077 中.

In the last exchange of a full SSL handshake, the server can include a "New Session Ticket" message (not represented in the handshake described in the picture) which will contain the complete session state (including the master secret negotiated between the client and the server and the cipher suite used). Therefore, this state is encrypted and integrity-protected by a key known only by the server. This opaque datum is known as a session ticket. The details lie in RFC 5077 which supersedes RFC 4507.

票据机制是一个 TLS 扩展.客户端可以通过在Client Hello"消息中发送一个空的Session Ticket"扩展来宣传其支持.如果服务器支持，服务器将在其Server Hello"消息中使用空的Session Ticket"扩展名进行应答.如果其中之一不支持此扩展，则可以回退到 SSL 内置的会话标识符机制.

The ticket mechanism is a TLS extension. The client can advertise its support by sending an empty "Session Ticket" extension in the "Client Hello" message. The server will answer with an empty "Session Ticket" extension in its "Server Hello" message if it supports it. If one of them does not support this extension, they can fallback to the session identifier mechanism built into SSL.

RFC 5077 确定了哪些情况需要票证而不是会话标识符.主要的改进是避免了维护服务器端会话缓存的需要，因为整个会话状态是由客户端记住的，而不是服务器.会话缓存在内存方面可能很昂贵，并且当请求跨服务器负载平衡时，可能难以在多个主机之间共享.

RFC 5077 identifies situations where tickets are desirable over session identifiers. The main improvement is to avoid the need to maintain a server-side session cache since the whole session state is remembered by the client, not the server. A session cache can be costly in terms of memory, and can be difficult to share between multiple hosts when requests are load-balanced across servers.

这篇关于SSL 会话票证与会话 ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！