Skip to main content

Harden TLS session resumption

The TLS session resumption functionality is misconfigured. This opens attackers the possibility to steal existing TLS sessions from other users. This section contains guidelines and code snippets for Apache and Nginx on fixing TLS Session Resumption security vulnerabilities.

Security assessment​

Security_Assessment_HardenTLSSessionResumption

CVSS vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

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 occur. Instead, a value known from a previous session is used to verify the authenticity of the connection. However, if the server does not rotate or renew its secrets properly, the session resumption breaks perfect forward secrecy.

Prevent attacks​

To disable TLS session resumption, complete the following configurations. Further possibilities exist to harden the session resumption feature but are based on scheduled restarts of the webserver.

Apache​

On Apache you need insert the SSLOpenSSLConfCmd directive into the virtual host configuration in /etc/apache2/sites-enabled/domain.confor/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  
    </VirtualHost>  
</IfModule>

Nginx​

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 the ssl_session_tickets directive 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;  
}

DAST Essentials uses an in-memory key generator daemon that generates a new, timestamped key every hour to meet these security goals. Keys are encrypted so that only the nginx servers can decrypt them. Then, with the CloudFlare secure data propagation infrastructure, ticket keys replicate from one master instance to any or all of the PoPs worldwide. 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. It rotates them hourly, and keys are securely distributed to any or all hosts worldwide without being written to disk.

There are some technical details still worth mentioning. First, configure distributed clock synchronization. As an example, there may well be one host who thinks it is UTC 12:01 pm while other hosts still think it is UTC 11:59 am. The faster-clock host might start encrypting session tickets with the key of 12:00 pm, 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 is not yet available due to propagation delay. Instead of dedicating efforts to 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. 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, the session ticket lifetime hint is set to 18 hours, the same value for SSL session timeout. This is because each server keeps ticket keys for ticket decryption for the past 18 hours.

Last updated on