Prevent SSL LUCKY13 attacks

The SSL LUCKY13 is a cryptographic timing attack that can be used against implementations of the TLS and DTLS protocols using the Cipher Block Chaining mode of operation. This can also be considered a type of man-in-the-middle attack.

Security assessment

CVSS vector: AV:N/AC:H/AU:N/C:P/I:N/A:N

Vulnerability information

The vulnerability that allows the SSL LUCKY 13 to be made is a flaw in the SSL/TLS specification rather than due to issues in specific implementations.

The attack can be considered a more advanced type of padding oracle attack that exploits different calculation times depending on the plaintext being padded with one or two bytes or containing incorrect padding.

Under OpenSSL, the attack allows a full plaintext recovery, whereas, for GnuTLS, a partial plaintext recovery attack can be conducted. In the latter case, an attacker can recover up to 4 bits of the last byte of plaintext blocks.

As a result of a successful attack, an attacker exploiting this vulnerability can read the plaintext of a TLS encrypted session. This can result in the loss of sensitive information.

Occurrence of LUCKY13 attacks

This attack relies on a difference in processing times between TLS messages with at least two bytes of correct padding and TLS messages with one byte of proper padding (or incorrectly formatted padding). Transport Layer Security messages with two bytes of padding are processed somewhat faster, and this difference can be detected when the arrival of TLS error messages is timed.

To establish this difference, attack-generated ciphertexts are sent to the same place in the plaintext stream during several TLS sessions. This generates an error message in the network as a response.

By repeatedly launching an attack and carefully analyzing the responses, these different padding conditions can be distinguished. Then, using the packet timing data, an attacker can execute a plaintext-recovery attack on the MAC check while processing a malformed CBC padding.

Timing Attack results in long (red) and short (blue) fake padding (AlFardan & Paterson, 2013).

A LUCKY 13 attack requires about 223 TLS sessions to collect a whole block of TLS-encrypted plaintext in its most basic version. This can be reduced several times, and under the best circumstances, an attacker needs 2¹³ TLS sessions to recover one plaintext byte. This is premised on the condition that the attacker is close to the target (i.e., in the same network as the webserver) to reduce noise and perform the timing attack. To generate the necessary TLS sessions, attackers have several options. As a result of the attacks, a running TLS session may be terminated. Applications that use this protocol may then attempt to reconnect and send cookies or authentication credentials.

Another way of generating sessions is through malware on the client-side. This is akin to a BEAST attack though it does not need to circumvent the same-origin policy because it is not a form of injection attack.
In DTLS sessions, attacks can even be executed within a single session with the help of amplification techniques that make the timing signals more pronounced and easier to spot.

Protect against SSL LUCKY13 attacks

Apart from patches, several mitigation techniques exist that will allow you to protect yourself from this type of attack. These mitigation techniques were put forward by AlFardan & Paterson, who made this vulnerability known. They include:

• Adding random time delays to the CBC-mode decryption process to frustrate statistical analysis is a possible countermeasure you can take. However, it is not particularly effective if implemented solely since attackers can overcome it by increasing the number of samples they take.
• Switching from a block cipher to an RC4 stream cipher avoids the need for plaintext padding (i.e., CBC-mode encryption) altogether. This cannot be implemented under Datagram Transport Layer Security (DTLS). Switching a stream cipher will eliminate the possibility of attacks as described above. RC4 cipher suites are widely supported in TLS implementations and successful against BEAST attacks. However, RC4 has specific cryptographic weaknesses when used in TLS that must be accounted for. RC4, when used in TLS, contains single-byte biases which are not discarded before the encryption. This allows for remote attacks to be conducted, such as the Bar-mitzvah attack. For this reason, switching to RC4 is only a temporary fix for the LUCKY 13 vulnerability.
• Switching from MEE-TLS-CBC to AEAD cipher suites, i.e., dedicated encryption algorithms, such as AES-GCM, is also possible for eliminating the possibility of a LUCKY 13 attack. However, this does not rule out the chance for errors during implementation, nor the potential for using side-channels. TLS 1.2 client and server implementations added support for these cipher suites.
• Modifying the CBC-mode decryption procedure is the final mitigation strategy proposed by AlFardan & Paterson. Its intended purpose is to remove the timing side-channel by ensuring a uniform processing time for all ciphertexts under this mode. In other words, the processing time must only be related to the size of the ciphertext and not to the plaintext (and its padding). This is achieved by ensuring that the MAC processing amount does not differ regardless of what the underlying plaintext indicates as the message length. However, this approach requires great care and attention and will likely present a challenge. For this reason, the most viable long-term mitigation strategy for avoiding SSL LUCKY 13 attacks is to avoid using TLS in CBC-mode and implement the use of AEAD cipher suites.

Prevent attacks

In addition to the above countermeasures, you can prevent the LUCKY13 attack using the following Transport Layer Security configuration in Apache and Nginx.

Apache

With apache, the SSL/TLS configuration is stored in /etc/apache2/mods-enabled/ssl.conf. If you use Let's Encrypt, the configuration may reside in /etc/letsencrypt/options-ssl-apache.conf. To enable only ciphers with high encryption and current protocols set:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1  
SSLCipherSuite          ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256  
SSLHonorCipherOrder     on  
SSLCompression          off

Then reload the Apache server configuration.

Note that this limits the cipher suites and protocol versions to recent SSL/TLS versions, which might exclude users with older browsers.

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 following directive to the server section:

ssl_protocols TLSv1.2;  
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';  
ssl_prefer_server_ciphers on; 

Then restart the Nginx server.

Note that this limits the cipher suites and protocol versions to recent SSL/TLS versions, which might exclude users with older browsers.