Transport Layer Security (tls) Session Resumption

Transport Layer Security (TLS) Session Resumption without Server-Side State

Girish Mahadevan 24scs131 CSE-A

Introduction Developing a mechanism which enables the transport layer security server to resume sessions and avoid keeping per client session state. The TLS server encapsulates the session state into a ticket which is forwarded to the client for it to resume the session. A ‘TICKET’ is defined as a cryptographically protected data structure that is created by a server and consumed by it to rebuild session-specific state. The ticket is created by the TLS server and sent to the TLS client, when the TLS client wants to resume a session it presents the ticket to the TLS server. The ticket is distributed to the client using the “NewSessionTicket” TLS handshake message, this message is sent during the TLS handshake before the “ChangeCipherSpec” message, after the server has successfully verified the client's Finished message.

View

Mechanism overview The client states that the mechanism implemented is supported by including a SessionTicket TLS extension in its messages (eg. ClientHello). This extension will be empty if the client does not posses a ticket for the server. If the server wants to use this mechanism, it stores its session state (such as cipher suite and master secret) to a ticket that is encrypted and integrity-protected by a key known only to the server.When the client sends the ticket to the server it includes the SessionTicket extension with its message, then the server decrypts the received ticket and verifies the tickets validity, retrieves the current session state and resumes the client session.

Now, if the server verifies the client’s ticket successfully then it may renew the ticket by the “NewSessionTicket” Handshake message. It may also be possible that the server does not want to issue a session ticket to the client at that point of time, in this case it just finishes the handshake without issuing a session ticket or a new session ticket.If the server rejects the ticket, it may still wish to give a new session ticket after performing the full handshake. If the server rejects the ticket, it may still wish to give a new session ticket after performing the full handshake.

Session Ticket Extension If the client possesses a ticket that it wants to use to resume a session, then it includes the ticket in the SessionTicket extension in the ClientHello. If the client does not have a ticket and is prepared to receive one in the NewSessionTicket handshake message, then it MUST include a zero-length ticket in the SessionTicket extension. If the client is not prepared to receive a ticket in the NewSessionTicket handshake message then it MUST NOT include a SessionTicket extension unless it is sending a nonempty ticket it received through some other means from the server. If the server fails to verify the ticket, then it falls back to performing a full handshake. If the ticket is accepted by the server but the handshake fails, the client SHOULD delete the ticket.

Implementation Then mechanism which would be developed can be implemented in the following situations:  Servers handling a large number of transactions from different users  Servers that desire to cache sessions for a long time  Embedded servers with little memory

Expected Execution It can be done using a single system where we can open multiple CHILDS (clients) and using the connection program we can restrict one of the child’s from accessing the server and then we can resume the connection using our mechanism. Platform Usage: C, Linux