1038
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中
最後更新：2017-09-04 00:32:23