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 non-
empty 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