In light of documented TLS vulnerabilities and implementation bugs, understanding known attack vectors becomes a necessity.
What’s in a name: an overview of TLS vulnerabilities
Exploits in the wild may target flaws in the TLS protocol, including weak cryptographic primitives, or specific implementation errors, cross-protocol vulnerabilities or any combination of the above.
Conceptual flaws in TLS and the resulting exploits
TLS vulnerabilities are a dime a dozen—at least so long as obsolete versions of the protocol are still in active deployment.
Some major attack vectors arise from conceptual flaws in the TLS standard itself. Features prone to vulnerabilities include protocol downgrades, connection renegotiation, and session resumption. Incomplete or vague specifications, particularly when it comes to cross-protocol interactions (i.e. between TLS and application protocols such as HTTP) engender some serious vulnerabilities, particularly in case of cross-protocol attack vectors against TLS, of which there are a few.
TLS 1.3 (see final draft) is the first version of the protocol that disallows renegotiation as well as protocol downgrades and upgrades that gave rise to the likes of POODLE and LOGJAM.
A 3SHAKE attack requires a honest client to connect to a malicious server and present a client credential. After obtaining the credential, the malicious server can then impersonate the client at any other server that accepts the same credential. To that end, the malicious server performs a man-in-the-middle (MiTM) attack on three successive handshakes between the honest client and another server, and succeeds in impersonating the client on the third handshake.
The attack exploits a lack of cross-connection binding of TLS session resumption on new connections. It works against servers which perform certificate-based authentication of the client and support both resumption and renegotiation.
Variations of the attack can compromise other TLS-based authentication mechanisms that do not rely on renegotiation, such as PEAP, SASL (SCRAM, GS2), and Channel ID.
To mitigate these types of attacks, TLS 1.3 disallows renegotiation.
TLS Renego MITM
In a TLS Renego MITM attack, an adversary makes a TLS connection that was first attempted by a legitimate client. The attacker can either establish the connection before the client does, or effectuate the attack using session renegotiation. Mutual certificate-based client authentication connections are unfortunately not immune.
The most glaringly nonsensical conceptual flaw was evident in SSL v2. The MITM attacker could simply create a false termination message, splice into the SSL session, and deceive the parties into thinking their communication was still “secure”.
Vendors have patched up the vulnerability in accordance with RFC 5746 .
POODLE (Padding Oracle On Downgraded Legacy Encryption, CVE-2014-8730) is a man-in-the-middle attack that relies on a protocol downgrade from TLS 1.0, 1.1 or 1.2 to SSLv3.0 to attempt a brute-force attack against CBC padding.
THE FIX: TLS 1.3 offers protection against POODLE by disallowing a protocol downgrade.
The LOGJAM attack relies on a downgrade of vulnerable TLS connections to 512-bit export-grade cryptography that uses weak DH Groups.
THE FIX: TLS 1.3 offers protection against LOGJAM by disallowing export-grade ciphers.
The FREAK (Factoring RSA Export Keys) attack involved tricking servers into negotiating a connection with a previous version of TLS (such as SSLv2) using cryptographically weak 512 bit encryption keys.
THE FIX: TLS 1.3 offers protection against FREAK by disallowing a protocol downgrade.
TLS vulnerabilities resulting from weak cryptographic primitives
Many known TLS vulnerabilities result from weak cryptographic primitives, which TLS 1.3, thankfully, did away with.
In TLS up to version 1.2, some block ciphers can operate in cipher block chaining mode (CBC for short). CBC was thought to counteract manipulation as the data integrity of each block depends on the proper encryption of the block before it. The CBC IV for each record except the first is the previous records’ last ciphertext block. Faulty implementations of CBC in TLS 1.0 allowed for the emergence of the BEAST attack. The prevalence of those faulty implementations prompted the removal of CBC from TLS 1.3.
When using a block cipher, the length of all plaintext messages must be a multiple of the cipher’s block size; a length discrepancy requires padding extending the message length so it fits the last block). Depending upon the algorithm, the padding section typically derives from the plaintext in some way. During the decryption, padding is verified; invalid padding produces an error. An attacker can manipulate padding in order to trigger errors and timing differences based on these modifications to try to guess the contents of the message. This so-called padding oracle attack in TLS up to version 1.2 can compromise the plaintext.
In TLS 1.3, CBC is disallowed and the compulsory use of AEAD cipher suites eliminates vulnerabilities associated with padding oracle attacks.
Sweet32, an attack on 64 bit block ciphers
This attack can compromise critical data that is being sent repeatedly, such as an authentication token contained in every request. This is particularly true with persistent HTTP connections (in HTTP/1.1, Keep-Alive), as those allow for the exchange of a large number of HTTP requests without rekeying.
Mitigation involves disabling Triple-DES-based cipher suites (3DES).
ROBOT or Return of Bleichenbacher’s Oracle Attack
ROBOT (Return of Bleichenbacher’s Oracle Attack) leverages insecure padding modes (such as RSA PKCS #1 v1.5), which open up the possibility of signature forgery. This is yet another reemergence of Bleichenbacher’s CRYPTO’98.
As if there hadn’t been enough of those already (see page 4):
- Bleichenbacher (CRYPTO 1998)
- Klima et al. (CHES 2003)
- Jager et al. (ESORICS 2012)
- Degabriele et al. (CT-RSA 2012)
- Bardou et al. (CRYPTO 2012)
- Zhang et al. (ACM CCS 2014)
- Meyer et al. (USENIX Security 2014)
- Aviram et al. (DROWN, USENIX Security 2016)
THE FIX: TLS 1.3 disallows the insecure key transport mechanism known as RSA-PKCS#1 v1.5.
LUCKY13 is a cryptographic timing attack against implementations of TLS up to and including 1.2 when using the CBC mode of operation of a bulk cipher. It is a variation on Serge Vaudenay‘s padding oracle attack that was previously believed fixed. A variant of the LUCKY13 attack may work, at least in theory, against the open source implementation of TLS known as s2n that was developed by Amazon Security Labs.
Vaudenay‘s attack relies on the attacker’s ability to distinguish bad_record_mac and decryption_failed errors.
THE FIX: Enable TLS 1.3, disallow CBC crypto suites in TLS 1.2, disable older versions of TLS. In addition to disallowing CBC ciphers, TLS 1.3 uses the bad_record_mac alert for all deprotection failures. This should guard the connection from side channel attacks like Vaudenay’s and LUCKY13.
In an attempt to patch up the LUCKY13 vulnerability, the developers of OpenSSL/LibreSSL inadvertently introduced a new bug: LUCKYminus20.
TLS implementation vulnerabilities
TLS vulnerabilities resulting from faulty implementations abound. Some of them give rise to cross-layer protocol attacks and/or side channel attacks.
Combine several such vulnerabilities, and you have a disaster in the making.
BEAST (Browser Exploit Against SSL/TLS)
BEAST is primarily a client-side vulnerability in TLS 1.0. This cross-layer protocol attack leverages weaknesses in cipher block chaining (CBC) to enable man-in-the-middle attacks against TLS. It allows the attacker, given a sufficient number of guesses, to obtain authentication credentials, URL-based session tokens or HTTP session cookies.
Faulty CBC padding in TLS 1.0
Prior to encryption with a block cipher, the server will use an initial chaining vector (ICV or IV, short for initialization vector) blocks to mask plaintext data so that the encryption is not deterministic. The client will do so as well with the data it sends over and an Initialization Vector of its own.
With CBC, an active man-in-the-middle (MITM) attacker can predict the IV blocks, then make guesses about what the plaintext looked like and validate those assumptions. The attacker cannot decrypt the traffic, but given a sufficient number of correct guesses, will inevitably come across some form of authentication credentials.
BEAST (documented in 2011) is a client-side exploit. The original server-side mitigation technique involved enforcing the use of RC4 suites (RC4 stands for Rivest Cipher 4), but these, unfortunately, come short of expectations (see Bar Mitzvah, RC4 NOMORE). TLS 1.1 and 1.2 may or may not be immune to BEAST. (Old, supposedly closed TLS vulnerabilities have been resurfacing in new scenarios on a more or less regular basis.)
THE FIX: TLS 1.3 connections are immune to this TLS vulnerability because the use of CBC is disallowed.
CRIME and TIME
CRIME (Compression Ratio Info-leak Made Easy) is a cross-layer protocol attack that includes a compression side-channel attack against HTTPS. It leverages information leaked by TLS compression on messages sent from the client to the server. CRIME can recover targeted parts of the plaintext given a MiTM access.
In March 2013 at the Black Hat (EU), Tal Be’ery presented an extension of CRIME named TIME. It debuted two new enhancements: it used CRIME for server-to-client messages and did not require a MiTM situation by exploiting TCP window sizes. The first of these two modifications gave rise to BREACH (see further down).
THE FIX: CRIME is ineffective against TLS 1.3 because TLS 1.3 disables TLS-level compression.
To verify if a server is vulnerable to CRIME on port 443:
openssl s_client -connect domainname.com:443
In the output of this command, look for TLS compression; if enabled, the server is vulnerable to CRIME.
BREACH, also known as A BREACH beyond CRIME (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, CVE-2013-3587), was “inspired” by the CRIME exploit, but represents a separate vulnerability.
A BREACH attack relies on HTTP-level compression to read out a user session secret (such as a CSRF token) from the body of a HTTP response that reflects it; it works regardless of the TLS version used and is effective against any cipher suite. One way to mitigate it relies on disabling HTTP-level compression entirely.
To verify if a server is vulnerable, run:
openssl s_client -connect domainname.com:443
In the output, look for signs of enabled HTTP compression such as deflate (“Accept–Encoding: compress, gzip”).
An attack combining elements of BREACH and CRIME became known as HEIST.
From TIME to HEIST
An attack dubbed TIME, first presented at Black Hat EU in 2013, failed to garner media attention. It soon resurfaced as HEIST at the Black Hat USA conference in August of 2016.
HEIST (HTTP Encrypted Information Can Be Stolen Through TCP-Windows) refers to a set of novel techniques that bring network-level attacks against TLS to the browser in the spirit of CRIME and BREACH (but this time, using the Fetch API). The attack techniques behind HEIST span over multiple layers: browser, HTTP, TLS and TCP.
One of the best ways to mitigate HEIST involves disabling third-party cookies in the web browser. While most browsers support this feature, it has to be activated client-side, by the end user.
Disabling compression (on the server side) does not provide complete protection as it does not address other length-based attack vectors.
SLOTH (Security Losses from Obsolete and Truncated Transcript Hashes) is is the name given to a group of TLS vulnerabilities that facilitate collision attack techniques against weak-hash-based transcripts. The name refers to the laziness of administrators who leave these TLS vulnerabilities in place.
Do NOT use vulnerable hash functions (that currently means, no MD5 and SHA-1 hashes). Thankfully, TLS 1.3 did away with those as well.
DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) is a cross-protocol attack effective against a server that uses the same private key as the same or even any other server with SSLv2 activated. For example, an attacker can use SSLv2 on a mail server to get it to leak its private key, which will then break the stronger encryption on a web server that also uses the same key.
SMACK (State Machine AttaCKs) like FREAK (Factoring RSA Export Keys) stands for server impersonation exploits against mainstream browsers that target faulty implementations of weak export cipher suites.
A flaw in a TLS library by the German semiconductor firm Infineon Technologies makes a variety of devices vulnerable to the ROCA attack when they exchange RSA keys.
ROCA (“Return of the Coppersmith Attack“, CVE-2017-15361) is facilitated by a cryptographic weakness that allows an attacker to recover the private key from the public key in key pairs that were generated by devices with the vulnerability. Only the knowledge of a public key is necessary; the attacker does not need physical access to the vulnerable device.
Also, the ROCA vulnerability does not depend on a weak or a faulty random number generator. All RSA keys generated by a faulty chip are vulnerable to the attack.
The source of the ROCA vulnerability is a conceptual bug in RSALib, a software library provided by Infineon. Its implementations include cryptographic smart cards, Trusted Platform Modules (TPM), various chipsets and other “secure” hardware.
TLS vulnerabilities resulting from certificate-based exploits
A variety of attack vectors against TLS relate to certificate vulnerabilities.
In 2018, researchers at Fidelis Security uncovered such a a flaw in the certificate exchange during the TLS handhake.
Covert transfer of executables via X.509 extensions
During the TLS handshake, the server submits its certificate to the client (and, optionally, vice versa). By placing arbitrary binary data within the certificate. The data transferred via X.509 extensions could include a malicious binary; when traversing the internet over TLS negotiation traffic, it will likely bypass detection methods that do not inspect certificate values. This opens up the possibility of using TLS connections for command-and-control (CnC) communication. Jason Reaves, a threat research principal engineer at Fidelis Security, writes in his analysis:
X.509 certificates have many fields where strings can be stored…The fields include version, serial number, Issuer Name, validity period and so on. The certificate abuse…takes advantage of this fact to hide data transfer inside one of these fields. Since the certificate exchange happens before the TLS session is established there appears to never be data transfer, when in reality the data was transferred within the certificate exchange itself.
The proof of concept uses self-signed certificates. Unless you want to check for executables that may be hiding within such certificates, reject self-signed certificates.
“Researchers continue to find novel ways to abuse protocols and RFC implementations to achieve difficult-to-detect data transfer methods,” said Reaves. Indeed they do.
This above list is by no means all-inclusive.
Vulnerable versions of the TLS protocol and weak cryptographic primitives are a recipe for a never-ending wave of cyber security incidents. TLS vulnerabilities may well keep you at the edge of your seat unless you take things into your own hands to close known attack vectors.
How to mitigate known TLS vulnerabilities
First things first: how do you know that your server is affected? Why, run some diagnostics, of course.
Worthwhile TLS diagnostics utilities
The Swiss company High-Tech Bridge SA offers a nifty TLS configuration test online at:
Qualys SSL Labs can test both your web servers and user agents:
There are also a couple of interesting scripts in the public domain, for example this one on Superuser.
TLS vulnerability fixes
Here is what you can do to mitigate any TLS vulnerabilities your tests uncover (the following is based on CloudFlare‘s and Qualys SSL Labs‘ recommendations):
- deactivate all versions of SSL as well as TLS 1.0 and 1.1; activate TLS 1.2 and 1.3
- turn off header compression in TLS (SPDY 3.1 is obsolete); TLS 1.3 has no header compression
- turn off the RC4 stream cipher (Rivest Cipher 4 also known as ARC4 or ARCFOUR, short for Alleged RC4)
- disallow renegotiation with clients
- get rid of export-grade ciphers (this alone will safeguard your server e.g. from FREAK)
- disallow insecure padding modes in TLS 1.2 (such as RSA PKCS#1 v1.5)
- disable vulnerable CBC MAC-then-Encrypt modes to guard from Vaudenay, Lucky13, POODLE, LuckyMinus20, and other attack vectors
- activate support for TLS_FALLBACK_SCSV, a protocol extension that prevents MITM attackers from forcing a protocol downgrade; current versions of OpenSSL offer this feature out of the box, but it only works if both the client and the server support it
Selecting cipher suites is not as easy as it looks. For more on closing TLS vulnerabilities, see “TLS 1.3 (with AEAD) and TLS 1.2 cipher suites demystified: how to pick your ciphers wisely“.
Perfect forward secrecy in TLS 1.3: fact or fiction?
TLS 1.3 offers perfect forward secrecy (with the exception of connections using 0-RTT session resumption). This feature protects data exchanged in one session from being decrypted with a compromised key in a later session.
Forward Secrecy refers to a key exchange in which the shared key that encrypts the data flow between two parties is not related to their public/private key pair.
Perfect Forward Secrecy requires that in addition to offering Forward Secrecy, new shared keys are generated for each conversation and are independent of each other.
TLS 1.3 offers perfect forward secrecy except in case of 0-RTT session resumption.
Also, perfect forward secrecy relies on the assumptions that:
- the mathematical challenge that must be solved in order to generate session keys is too complicated to perform in real time (hence, you want to pick your cipher suite wisely)
- in the event that the session keys do get compromised, attackers are unable to retroactively decode prerecorded communications because those rely on other, unrelated session keys that have been already discarded
[…] A BREACH attack relies on HTTP-level compression to read out a user session secret (such as a CSRF token) from the body of a HTTP response that reflects it; it works regardless of the TLS version used and is effective against any cipher suite. One way to mitigate it relies on disabling HTTP-level compression entirely. via […]