原创文章：来自nginx中session ticket重用Session提高https性能分析
https会话建立初次使用session ticket的SSL握手流程如下:
Client Server
ClientHello
(empty SessionTicket extension)-------->
ServerHello
(empty SessionTicket extension)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1: Message Flow for Full Handshake Issuing New Session Ticket
If the server successfully verifies the client's ticket, then it MAY renew the ticket by including a NewSessionTicket handshake message after the ServerHello in the abbreviated handshake. The client should start using the new ticket as soon as possible after it verifies the server's Finished message for new connections. Note that since the updated ticket is issued before the handshake completes, it is possible that the client may not put the new ticket into use before it initiates new connections. The server MUST NOT assume that the client actually received the updated ticket until it successfully verifies the client's Finished message.
而session重用时SSL握手简化为如下步骤:
Client Server
ClientHello
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2: Message Flow for Abbreviated Handshake Using New Session
Ticket
使用session ticket机制可以提高ssl握手的效率,并节约有效的服务器计算资源.(另外一种是使用session cache)
nginx中使用 ssl_session_ticket_key file; 指令来配置用于加密或解密SSL session_ticket的密钥, 如果用了多个指令文件,则仅第一个指令文件中的密钥用来加密; 其它的密钥文件,并且第一个密钥文件都可以用做解密.
一般nginx.conf 中配置如下
ssl_session_ticket_key encode_decode.key; ssl_session_ticket_key decode.key;
encode_decode.key用于加密ticket 也用于解密ticket
decode.key用于解密曾用decode.key加密过的ticket;
如果nginx.conf中没有配置key文件,则openssl默认会生成随机数的key,生成的时机: (keys are randomly generated when SSL context is initialized).
session ticket机制综述
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.
session tickets are an optional TLS extension and therefore, the support is not as widespread as for session identifiers. Support for tickets was added in OpenSSL 0.9.8f (October 2007)
TLS 和session ticket机制相关的RFC文档
- TLS 1.0 defined in [RFC2246]
- TLS 1.1 defined in [RFC4346]
- TLS 1.2 defined in [RFC5246]
- RFC5077 Transport Layer Security (TLS) Session Resumption without Server-Side State January 2008 目前用的是RFC5077,取代RFC4507
- SessionTicket TLS [RFC4507] 被RFC5077取代
- TLS扩展字段的规定 https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
- Extensions: Extension Definitions [RFC6066]
- 握手阶段最后一条由server发出的NewSessionTicket消息的格式(RFC 5077)如下, 可以是全握手时发出,也可以是简要握手时发出
NewSessionTicket消息的格式:
struct {
uint32 ticket_lifetime_hint;
opaque ticket<0..2^16-1>;
} NewSessionTicket;
ticket_lifetime_hint: The value indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order relative to when the ticket is received.
RFC5077推荐的ticket消息格式如下:
The ticket is structured as follows:
struct {
opaque key_name[16];
opaque iv[16];
opaque encrypted_state<0..2^16-1>;
opaque mac[32];
} ticket;
followed by the length of the encrypted_state field (2 octets) and its contents (variable length).
上述结构encrypted_state未加密明文内容如下:
struct {
ProtocolVersion protocol_version;
CipherSuite cipher_suite;
CompressionMethod compression_method;
opaque master_secret[48];
ClientIdentity client_identity;
uint32 timestamp;
} StatePlaintext;
enum {
anonymous(0),
certificate_based(1),
psk(2)
} ClientAuthenticationType;
struct {
ClientAuthenticationType client_authentication_type;
select (ClientAuthenticationType) {
case anonymous: struct {};
case certificate_based:
ASN.1Cert certificate_list<0..2^24-1>;
case psk:
opaque psk_identity<0..2^16-1>; / from [RFC4279] /
};
} ClientIdentity;
注: 而在openssl 的实现中 session 共享的信息用结构体ssl_session_st来表示
或SSL_SESSION_ASN1, 使用i2d_SSL_SESSION()函数生成需要加密的ticket.
问题1 如果session ID 和session ticket都在client hello提供时以那个为准起作用?
答案: 以session ticket为准.详细的解释如下,
rfc5077 3.4. Interaction with TLS Session ID 做了说明如下:
If a ticket is presented by the client, the server MUST NOT attempt to use the
Session ID in the ClientHello for stateful session resumption.
openssl代码中利用session ticket或session ID恢复session的处理实现逻辑:
ssl3_get_client_hello(SSL *s) -->
根据sessionID或ticket查找session的函数 ssl_get_prev_session()-->
根据ticket解密session信息tls1_process_ticket()-->
利用全局ctx ticket_key或应用层即nginx tlsext_ticket_key_cb回调解密 tls_decrypt_ticket()
如果上述解ticket失败或没有ticket则调用lh_SSL_SESSION_retrieve() 根据session id取cache中的信息恢复
如果openssl本身cache中没找到则根据session id从应用层nginx回调函数get_session_cb()中查找;并SSL_CTX_add_session(s->session_ctx, ret);//将外部的cache加入到openssl中