Forum Discussion
JW_48389
Nimbostratus
NimbostratusTLS Session Resumption (Session IDs / Session Tickets)
Hi,
I've been testing some the TLS Session Resumption features on the F5 LTM and have some questions around Session IDs (cache is done on the F5) and Session Tickets (cache is done on the client side).
Over 70% of the traffic on my company's website comes from Chrome, so all the tests I've done have been using it. I've been able to successfully send Session Tickets back to the Client by enabling them on the Client SSL profile, but even then, I've never seen Chrome send those back when reconnecting.
Does anyone know if/when does Chrome use this feature for session resumption?
As a side note, I've tried disabling the use of Session IDs by setting the Cache Size and Cache Timeout options to 0, but even though I'm not seeing the F5 send any session IDs to the client, after some attempts at reconnecting, I start seeing the client use Session IDs which are recognised by the LTM. This is strange to me as I don't see any Server Hellos with said Session IDs being sent to the Client for that VIP (I'm capturing traffic on the client using Wireshark).
Help is highly appreciated!
After some experimentation, I concluded that Chrome does in fact use the session tickets to re-establish SSL connections.
Also, the session IDs the client uses when it reconnects are derived from the session ticket it receives.
Taken from the RFC:
3.4. Interaction with TLS Session ID
If a server is planning on issuing a session ticket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server rejects the ticket and falls back to the full handshake then it may include a non-empty Session ID to indicate its support for stateful session resumption. If the client receives a session ticket from the server, then it discards any Session ID that was sent in the ServerHello.
When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. Since the client generates a Session ID, the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. 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. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case, the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages.
JW_48389After some experimentation, I concluded that Chrome does in fact use the session tickets to re-establish SSL connections.
Also, the session IDs the client uses when it reconnects are derived from the session ticket it receives.
Taken from the RFC:
3.4. Interaction with TLS Session ID
If a server is planning on issuing a session ticket to a client that does not present one, it SHOULD include an empty Session ID in the ServerHello. If the server rejects the ticket and falls back to the full handshake then it may include a non-empty Session ID to indicate its support for stateful session resumption. If the client receives a session ticket from the server, then it discards any Session ID that was sent in the ServerHello.
When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. Since the client generates a Session ID, the server MUST NOT rely upon the Session ID having a particular value when validating the ticket. 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. Alternatively, the client MAY include an empty Session ID in the ClientHello. In this case, the client ignores the Session ID sent in the ServerHello and determines if the server is resuming a session by the subsequent handshake messages.