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

The ТLS protocol, the successor of the Secure Sockets Layer (SSL) protocol, is utilized to provide privacy, data integrity, and secure traffic between communicating networks or applications.

The vulnerability that makes the SSL LUCKY 13 possible affects the TLS 1.1 and 1.2, and DTLS 1.0 or 1.2 implementations. It also affects previous versions such as SSL 3.0 and TLS 1.0.

The possibility for this attack was established by security researchers Nadhem AlFardan and Kenny Paterson. It is called LUCKY 13 due to the 13 bytes of header information contained in the TLS MAC calculation that is part of the vulnerability and makes the attack possible.  

Table of contents
  1. SSL LUCKY13 Vulnerability Information
  2. SSL LUCKY13 Security Assessment Level
  3. How Does an SSL LUCKY 13 Attack Occur?
  4. How to Protect against SSL LUCKY 13?
  5. Guides to Preventing SSL LUCKY13 Attack

SSL LUCKY13 Vulnerability Information

The vulnerability that allows the SSL LUCKY 13 to be made is due to 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 attack can recover up to 4 bits of the last byte of blocks of plaintext. 

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

SSL Lucky13 Vulnerability Prevention

SSL LUCKY13 Security Assessment Level

Security Assessment Prevent SSL LUCKY13
Security Assessment Prevent SSL LUCKY13


How Does an SSL LUCKY 13 Attack Occur?

In a nutshell, this attack relies on a difference in processing times between TLS messages that have at least two bytes of correct padding and TLS messages that have one byte of correct 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, attacker-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 from each other. Then, using the packet’s timing data, an attacker can execute a plaintext-recovery attack on the MAC check during the processing of a malformed CBC padding.

SSL LUCKY13 Diagram

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

n its most basic version, a LUCKY 13 attack requires about 223 TLS sessions to collect a whole block of TLS-encrypted plaintext. 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 any noise and perform the timing attack.

To generate the necessary TLS sessions, attackers have several options. As a result of the attacks, a TLS session that is running may be terminated. Applications that use this protocol may then attempt to reconnect and will also send cookies or authentication credentials.

Another way of generating sessions is through the use of 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.

Is it safe to use TLS?

Launching a TLS attack requires a number of conditions to be in place. Attackers need to be located on the same LAN that they are attacking and must be capable of generating enough sessions to discern the time signals of the sessions from the noise in the network. I.e. they require a very controlled environment and a lot of time for the successful execution of the attack.

As such, the SSL LUCKY 13 does not pose a grave threat to most TLS users. However, due to the widespread use of TLS, attacks against the protocol must be monitored and evaluated. 

More generally, this type of attack demonstrated flaws in the CBC ciphersuites used by TLS and DTLS protocols in certain versions. Since there are newer and better ciphers, mitigation against this type of attack can easily be achieved. 

Moreover, patches for TLS and DTLS libraries and platforms that use CBC that address this vulnerability have been developed and are widely available. This includes patches for OpenSSL, NSS, GnuTLS, PolarSSL, yaSSL, MatrixSSL, Opera, BouncyCastle, and JavaSE. 

Detect LUCKY13 Attack Vulnerability


How to Protect against SSL LUCKY 13?

Apart from patches, a number of 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:

Add random time delays

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 it can be overcome by attackers by simply increasing the number of samples that they take,

Switch to using RC4 ciphersuites 

One of the simplest mitigation techniques which you can apply is to switch from a block cipher to an RC4 stream cipher in order to avoid 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 entirely eliminate the possibility of attacks as described above. RC4 ciphersuites are widely supported in TLS implementations and are also a successful strategy against BEAST attacks. 

However, RC4 has certain 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 also only a temporary fix of the LUCKY 13 vulnerability.

Switch to authenticated encryption

Switching from MEE-TLS-CBC to AEAD ciphersuites, i.e. dedicated encryption algorithms, such as AES-GCM is also a possibility for entirely eliminating the possibility for a LUCKY 13 attack. 

This does not rule out the possibility for errors during implementation, nor the potential for the use of side-channels. Support for these ciphersuites was added in TLS 1.2 client and server implementations.

Careful implementation of MEE-TLS-CBC decryption

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.

This approach requires great care and attention and is likely to 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 also implementing the use of AEAD ciphersuites.

Guides to Preventing SSL LUCKY13 Attack

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


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 recent protocols set:

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder     on
SSLCompression          off

Then reload the Apache server configuration.

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


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

ssl_protocols TLSv1.2;
ssl_prefer_server_ciphers on;

Then restart the Nginx server.

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

See if Your Web App or API Has Security Vulnerabilities