What is SSL LUCKY 13
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, provides 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 of the LUCKY 13 attack was established by security researchers Nadhem AlFardan and Kenny Paterson. It is called LUCKY 13 due to the 13 bytes of the header information in the TLS MAC calculation that is part of the vulnerability and makes the attack possible.
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 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 is able to read the plaintext of a TLS encrypted session. This can result in the loss of sensitive information.
SSL LUCKY13 Security Assessment Level
CVSS Vector: AV:N/AC:H/AU:N/C:P/I:N/A:N
How Does an SSL LUCKY 13 Attack Occur?
In a nutshell, 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 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, 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 from each other. Then, using the packet’s 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 any 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 attempt to reconnect and 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 some conditions to be in place. Attackers need to be located on the same LAN that they are attacking and must generate 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 to execute the attack successfully.
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 cipher suites used by TLS and DTLS protocols in specific versions. However, since there are newer and better ciphers, mitigation against this attack can be easily achieved.
Moreover, patches for TLS and DTLS libraries and CBC platforms 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.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
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 attackers can overcome it by simply increasing the number of samples that they take.
Switch to using RC4 cipher suites
One of the simplest mitigation techniques you can apply is switching 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 eliminate the possibility of attacks described above. RC4 cipher suites 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 for the LUCKY 13 vulnerability.
Switch to authenticated encryption
Switching from MEE-TLS-CBC to AEAD cipher suites, i.e., dedicated encryption algorithms, such as AES-GCM, is also a possibility for entirely eliminating the possibility of a LUCKY 13 attack.
This does not rule out the possibility for errors during implementation, nor the potential for using side-channels. TLS 1.2 client and server implementations added support for these cipher suites.
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 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 also implement the use of AEAD cipher suites.
Guide 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.
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 recent 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 offThen 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.
