TLS Session Resumption

TLS session resumption allows a client that has connected before to continue with previously negotiated secrets instead of performing a full handshake. It is implemented with session IDs, where the server keeps state, or session tickets, where the server hands the client an encrypted blob to present next time. TLS 1.3 uses pre-shared keys derived from tickets.

Why it matters

A full handshake costs round trips and CPU for asymmetric crypto. Resumption trims both, which helps visitors on high-latency mobile links and reduces load on busy servers. It is one of the reasons repeat requests to the same host feel quicker.

There is a security side. Tickets are encrypted with a server-side ticket key. If that key lives for weeks or is shared carelessly, it weakens the forward secrecy of resumed sessions. Across multiple servers, tickets only resume if all of them share the key or you use a shared session cache.

Example

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
ssl_session_tickets off;

You can test with openssl s_client -connect example.com:443 -reconnect, which reconnects several times and reports Reused or New.

Common mistakes

• Running a load-balanced pool without a shared ticket key, so resumption rarely succeeds.
• Never rotating ticket keys.
• Setting excessively long lifetimes.

Related

• TLS handshake
• Forward secrecy
• TLS 1.3

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.