Skip to main content

TLS Session Resumption

The extra latency and computational costs of the full TLS handshake impose a serious performance penalty on all applications that require secure communication. To help mitigate some of the costs, TLS provides an ability to resume or share the same negotiated secret key data between multiple connections.

Session Identifiers 

The first Session Identifiers (RFC 5246) resumption mechanism was introduced in SSL 2.0, which allowed the server to create and send a 32-byte session identifier as part of its "ServerHello" message during the full TLS negotiation which we discuss in TLS Handshake. 
Internally, the server could then maintain a cache of session IDs and the negotiated session parameters for each peer. In turn, the client could then also store the session ID information and include the ID in the "ClientHello" message for a subsequent session, which serves as an indication to the server that the client still remembers the negotiated cipher suite and keys from previous handshake and is able to reuse them. Assuming both the client and the server are able to find the shared session ID parameters in their respective caches, then an abbreviated handshake can take place. Otherwise, a full new session negotiation is required, which will generate a new session ID.





Leveraging session identifiers allows us to remove a full roundtrip, as well as the overhead of public key cryptography, which is used to negotiate the shared secret key. This allows a secure connection to be established quickly and with no loss of security, since we are reusing the previously negotiated session data.


In practice, most web applications attempt to establish multiple connections to the same host to fetch resources in parallel, which makes session resumption a must-have optimisation to reduce latency and computational costs for both sides.



          Most modern browsers intentionally wait for the first TLS connection to complete before opening new connections to the same server: subsequent TLS connections can reuse the SSL session parameters to avoid the costly handshake.
However, one of the practical limitations of the Session Identifiers mechanism is the requirement for the server to create and maintain a session cache for every client. This results in several problems on the server, which may see tens of thousands or even millions of unique connections every day: consumed memory for every open TLS connection, a requirement for session ID cache and eviction policies, and nontrivial deployment challenges for popular sites with many servers, which should, ideally, use a shared TLS session cache for best performance.

 None of the preceding problems are impossible to solve, and many high-traffic sites are using session identifiers successfully today. But for any multiserver deployment, session identifiers will require some careful thinking and systems architecture to ensure a well operating session cache.


Session Tickets

To address this concern for server-side deployment of TLS session caches, the "Session Ticket" (RFC 5077) replacement mechanism was introduced, which removes the requirement for the server to keep per-client session state. Instead, if the client indicated that it supports Session Tickets, in the last exchange of the full TLS handshake, the server can include a New Session Ticket record, which includes all of the session data encrypted with a secret key known only by the server.
This session ticket is then stored by the client and can be included in the SessionTicket extension within theClientHello message of a subsequent session. Thus, all session data is stored only on the client, but the ticket is still safe because it is encrypted with a key known only by the server.
The session identifiers and session ticket mechanisms are respectively commonly referred to as session cachingand stateless resumption mechanisms. The main improvement of stateless resumption is the removal of the server-side session cache, which simplifies deployment by requiring that the client provide the session ticket on every new connection to the server—that is, until the ticket has expired.

Source - oreilly.com




Popular posts from this blog

Availability of 5 GHz WLAN Channels in India under unlicensed band

Availability of 5 GHz WLAN Channels in India under unlicensed band  In India, Wireless Planning and Coordination Wing of Department of Telecom, under Ministry of Communication takes care of licensing of radio frequencies.  In the latest National Frequency allocation plan 2018 (https://dot.gov.in/sites/default/files/NFAP%202018.pdf), Government of India (GoI), exempted the licensing requirements of the following radio frequency ranges for wireless usage and a gazette notification has also published for this (https://dot.gov.in/sites/default/files/License%20Exemption%20in%205%20GHz%20G_S_R_1048%28E%29%20dated%2022nd%20October%2C%202018_0.pdf)  -- 1.  5150-5250 2. 5250-5350 3. 5470-5725 4. 5725-5875 References
Read more

Why we have IPv6 after IPv4..... Where is IPv5 ?

IP or Internet Protocol, is the primary network protocol used on the Internet, introduced by Vint Cerf and Bob Kahn in 1974. IP version 0 to 3 was introduced and used between 1974 and 1979. After changes and refinements in initial IP protocol, version 4 was introduced in 1981, commonly known as IPv4, described in RFC 791 , which become the backbone of Whole Internet in no time. (IPv4 is know as v4 because it is the fourth version of IP not because it has 4 octets, which is a common myth). TCP/IP Protocol was designed as a part of project ARPANET, whose aim was to interconnect various universities and research institutes of USA. But with the dot com boom, TCP/IP grows like anything and its become a victim of its own success. In Early 90's, expert realized that we will exhaust the whole IPv4 number very soon and there is a need for a new protocol, which should be enough in size to serve the internet community for at least 30-40 years. This lead to new version of Internet Protoco...
Read more

Shouldn't India have a Root Server ???

A Root name server is a name server for DNS root zone. Every new DNS query resolved by our local resolver first goes to Root Name Server and then root name server directs it to required domain server. This means that if in any case, root name servers goes down, then whole internet goes down (don't worry this cannot be done so easily as most of root name servers are running on Anycast and located all over the world). Recently, an anonymous group posted, to target these 13 root name severs and to bring them down by DDOS attack on 31st March 2011, to protest against SOPA and PIPA. But as expected, they didn't succeed. The last time someone seriously tried to take out the root servers was about 4 or 5 years ago and they managed to take down six out of thirteen servers. I am not saying that it could not be done but it would be tough. Every root name server is operated by different organization (except 'A' and 'J' which are operated by VeriSign) but they all po...
Read more