1. Support Center
  2. SSL / TLS Vulnerabilities
  3. Vulnerabilities requiring reconfiguration

Harden TLS Session Resumption

The TLS session resumption functionality is misconfigured. This opens attackers the possibility to steal existing TLS sessions from other users.

Security Assessment




This article contains guidelines and code snippets for Apache and Nginx on how to fix TLS Session Resumption security vulnerabilities.

Vulnerability Information

The TLS session resumption functionality is misconfigured. This opens attackers the possibility to steal existing TLS sessions from other users.

Generally, the TLS session resumption functionality speeds up client reconnections, as no full TLS handshake needs to take place. Instead a value known from a previous session is used to verify the authenticity of the connection. If the server does not rotate or renew its secrets properly, the session resumption breaks perfect forward secrecy.


To disable TLS session resumption, follow one of our guides. There exist further possibilities to harden the session resumption feature, but are based on scheduled restarts of the webserver. Relate the "Further Reading" for more information.


On Apache you need insert the SSLOpenSSLConfCmd directive into the virtual host configuration in /etc/apache2/sites-enabled/domain.conf or /etc/httpd/sites-enabled/domain.conf:

<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>

ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www

SSLEngine on

SSLCertificateFile /etc/ssl/new.pem
SSLCertificateKeyFile /etc/ssl/privkey.key

SSLOpenSSLConfCmd Options -SessionTicket


For Nginx, update the configuration file which is usually located at /etc/nginx/nginx.conf, /etc/nginx/sited-enabled/yoursite.com (Ubuntu / Debian) or /etc/nginx/conf.d/nginx.conf (RHEL / CentOS). Add thessl_session_ticketsdirective to the server section:

server {
listen 443;
server_name example.org;

root /usr/share/nginx/www;
index index.html index.htm;

ssl on;
ssl_certificate /etc/ssl/new;
ssl_certificate_key /etc/ssl/privkey.key;

ssl_session_tickets off;


To meet all these security goals, we first start an in-memory key generator daemon that generates a fresh, timestamped key every hour. Keys are encrypted in order that only our nginx servers can decrypt them. Then with CloudFlare’s existing secure data propagation infrastructure, ticket keys replicate from one master instance to any or all of our PoPs round the world. Each host periodically queries the local copy of the database through a memcached interface for fresh encryption keys for this hour. To summarize, the key generation daemon generates keys randomly and rotates them hourly, and keys are distributed to any or all hosts across the world securely without being written to disk.

There are some technical details still worth mentioning. First, we want to tackle distributed clock synchronization. as an example, there may well be one host thinks it is UTC 12:01pm while other hosts still think it UTC 11:59am, the faster-clock host might start encrypting session tickets with the key of 12:00pm while other hosts couldn't decrypt those tickets because they don’t know the new key yet. Or the fast-clock host might find the key's not yet available due to propagation delay. instead of dedicating efforts for synchronization, we solve the problem by breaking the synchronization requirement. The key daemon generates keys one hour ahead and each host would opportunistically save the key for the next hour (if there's any) as a decryption-only key. Now even with one or more faster-clock hosts, session resumption by ticket still works without interruption because they will still decrypt session tickets encrypted by the other.

Also we set the session ticket lifetime hint to be 18 hours, the same value for SSL session timeout. Each server also keeps ticket keys for the past 18 hours for ticket decryption.

For more information about Crashtest Security visit crashtest-security.com

Scan For Free