Almost all servers have weak cryptographic protocol configurations. They support deprecated SSL/TLS versions and weak cipher suites, providing an opportunity for network attackers to decrypt client-server communication.
For twelve years, the standard internet encryption has been Transport Layer Security (TLS) 1.2.
Following its roots takes us back to the first version of the Secure Sockets Layer (SSL) protocol. It was developed in 1995 by Taher Elgamal, who was the chief scientist at Netscape.
SSL 2.0 and 3.0 quickly followed but also had issues.
TLS is a cryptographic protocol that provides secure communications over computer networks.
TLS provides secure communication between web browsers, end-user facing applications and servers by encrypting the transmitted information, preventing eavesdropping or tampering attacks.
Asymmetric encryption is used during the “handshake”, which takes place prior to any data being sent.
TLS 1.2 protocol took multiple round trips between client and server, while TLS 1.3 is a much smoother process that requires only one trip. TLS 1.3 has been around since 2018.
Released by the Internet Engineering Task Force and offering greater security, it remains the de facto security standard for all communication over the internet.
It removes many of the problematic options of previous TLS versions.
What is TLS vulnerability?
TLS vulnerability usually refers to vulnerabilities that arise due to using outdated versions of TLS or SSL before it. TLS versions are updated with time, and it is best advised to update to the latest version available.
The main vulnerabilities that arise are:
Conceptual Flaws Vulnerabilities
POODLE ATTACK
POODLE (Padding Oracle On Downgraded Legacy Encryption), is a completely functional name, but still a terrible one. POODLE started as an SSL 3.0 exploit and was also a threat to the TLS protocols if the TLS versions retained backwards compatibility with 3.0.
Craig Young, a computer security researcher, found vulnerabilities in TLS 1.2 that permits attacks like POODLE due to the continued support for an outdated cryptographic method: cipher block-chaining (CBC).
The flaws cause man-in-the-middle (MITM) attacks on a user’s encrypted Web and VPN sessions. This was the so-called Zombie POODLE exploit.
GOLDENDOODLE is a variant of POODLE with a much faster and more powerful crypto-hacking mechanism.
How to avoid Zombie POODLE and GOLDENDOODLE
The best solution for Zombie POODLE and all other TLS CBC padding oracles is to disable the use of TLS CBC ciphers.
Reducing the priority level of these ciphers can also help prevent real-world attacks.
The attacker cannot typically force the selection of a specific cipher and a CBC padding oracle attack occurs only if the client/server normally negotiates a vulnerable cipher.
FREAK ATTACK
FREAK (“Factoring RSA Export Keys”) is an SSL/TLS implementation attack when RSA key exchange is being used to securely negotiate pre-master-secret.
Currently known as ‘FREAK,’ this vulnerability (CVE-2015-0204) allows attackers to intercept HTTPS connections between vulnerable clients and servers and enforce them to use ‘export-grade’ cryptography.
This export-grade cryptography includes out-of-date encryption key lengths that can then easily be decrypted.
During the 90s, the U.S. government set up rules for the export of encryption systems by utilizing “strong” encryption strength of the RSA encryption keys to a maximum of 512 bits in any Secure Socket Layer (SSL) implementations targeted for export.
The rules changed eventually.
The “export” cipher suites stopped being used and by the year 2000, browsers were able to use a higher-security SSL.
Security researchers revealed that the old export-grade cryptographic suites are still being used.
They discovered that servers that support RSA export cipher suites could allow a man-in-the-middle (MITM) to trick the client and server into using older and weak 40- and/or 56-bit export cipher suites to downgrade their connection.
That MITM could then use today’s computing power to crack the keys in just a few hours.
To tumble into this attack: The Server must support RSA export cipher suites (e.g: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, etc) and the client must do one of the following:
must offer an RSA export suite or
must be using Apple Secure Transport or
must be using a vulnerable version of OpenSSL or
must be using Secure Channel (Schannel)
Once the encryption of the session is cracked, the MITM can steal any ‘secured’ personal information from the session.
How to avoid FREAK Attack
Server-Side: Disable support for all export-grade cipher suites on servers. We also recommend disabling support for all known insecure ciphers (not just RSA export ciphers), support for ciphers with 40- and 56-bit encryption, and enable forward secrecy.
Client-Side: Vulnerable clients include software that relies on OpenSSL or Apple’s Secure Transport (i.e., Chrome, Safari, Opera, Android and BlackBerry stock browsers), or Windows Secure Channel/Schannel (i.e. Internet Explorer). Older versions of OpenSSL should be upgraded immediately to the latest releases.
Weak Cryptographic Primitives - TLS Vulnerabilities
SWEET32: BIRTHDAY ATTACK
Sweet32 Birthday attack does not affect SSL Certificates; it affects the block cipher triple-DES.
Security of a block cipher depends on the key size (k). So the finest attack against a block cipher is the integral key search attack which has a complexity of 2k.
Even though when block ciphers are used to encrypt abundant data using modes of encryption such as CBC, the block size (n) also plays a big part in determining its security.
There is a high chance of a simple birthday attack when a CBC mode of encryption is used in which after 2n/2 blocks of data are encrypted with the same key, the collision between two ciphers blocks is expected.
Collision is when different inputs produce the same output. This data combines with several conditions and can be used to extract plain text of the encrypted data.
Sweet32 affects the Triple DES cipher ,which is also vulnerable as RC4 cipher.
The DES ciphers (and triple-DES) are 64-bit block ciphers. This enables an attacker to send ample amounts of traffic during the same TLS connection, creating a collision.
With this collision, the attacker is able to bring back information from a session cookie.
How to avoid a SWEET32 Birthday Attack
Websites that support 3DES are vulnerable to a SWEET32 Birthday attack. So check whether the website supports 3DES and check the cipher suites for 3DES.
Consider the following to mitigate SWEET32:
Prefer minimum 128-bit cipher suites
Limit the length of TLS sessions with a 64-bit cipher, which could be done with TLS renegotiation or closing and starting a new connection
Disable cipher suites using 3DES
The researchers have stated that SWEET32 is comparable to the attacks on RC4.
Hopefully, this means that the web browsers should offer 3DES as a fallback-only cipher, in order to avoid the usage of it in servers that support AES but prefer 3DES.
BLEICHENBACHER WITH THE ROBOT ATTACK
In 1998, Daniel Bleichenbacher discovered PKCS #1 v1.5 padding error messages sent by a Transport Layer Security (TLS) stack running on a server.
This could enable an adaptive-chosen ciphertext attack that fully breaks the confidentiality of TLS when used with RSA encryption.
ROBOT is the return of a 19-year-old vulnerability that allows performing RSA decryption and signing operations with the private key of a TLS server.
Bleichenbacher estimated that it takes about one million queries to decrypt an arbitrary ciphertext. Therefore, the attack was also named “million message attack”-original padding oracle attack for TLS.
The TLS server attempts to decrypt each one, and sends back one of two error codes: either the decrypt failed, or the padding was messed up.
By trying thousands of variations of a message containing a third-party’s TLS session, and differentiating between the two error codes, an attacker could ultimately reconstruct the session, one bit at a time.
Within that TLS session, the attacker can find out sensitive information such as user credentials.
Bleichenbacher has since been refined to the point where this version requires only tens of thousands of attempts.
The threat vectors:
Bleichenbacher padding oracle to decrypt TLS session which is previously recorded
The attacker would get the server to sign an arbitrary message using its RSA private key
The Bleichenbacher attack only affects RSA sessions not protected with the ephemeral keys offered by forward secrecy.
How to mitigate BLEICHENBACHER with the ROBOT attack
Update the server according to the patch provided by the vendors.
Disable RSA key exchange ciphers (recommended). If you don’t prefer to disable RSA key exchange ciphers, the server should at least support forward secrecy with modern browsers. (keep RSA ciphers last)
TLS Implementation Vulnerabilities
1. BEAST ATTACK
BEAST stands for (Browser Exploit Against SSL/TLS). The BEAST attack was discovered by Phillip Rogaway in 2002, but was considered to be impractical to exploit because it required a huge number of attempts to discover any useful information.
The first POC of the vulnerability was published in 2011. At that time, most websites still used TLS 1.0 or an earlier version of SSL – considered as vulnerable.
An attacker who is sniffing TLS 1.0 traffic can inject data into it.
If the attacker knows about the type of data being sent and where it is located in the message, they can inject a specially crafted data block and check whether the resulting encrypted block is the same as the corresponding block in the actual message stream.
If so, then the attacker has discovered the plaintext block. If not, they can try again and again with different likely values.
How to avoid BEAST Attack
Make sure to allow only TLS 1.1 or TLS 1.2, as they fixed the underlying TLS 1.0 vulnerability.
Actually mitigated in 2006 in the TLS 1.1 specification. Unfortunately, nearly all websites and major browsers still support TLS 1.0. In Windows Server 2008 R2, TLS 1.0 was disabled by default but it can be enabled.
By common agreement, Google’s Chrome, Microsoft’s Internet Explorer (IE) and Edge, and Mozilla’s Firefox decided to disable support for TLS 1.0 and 1.1 early in 2020.
2. CRIME ATTACK
CRIME attack is used to extract session tokens protected by the SSL/TLS protocol.
CRIME exploits the data compression feature of SSL and TLS. Compression is at the SSL/TLS level, so both the header and body are subjected to compression.
SSL/TLS and SPDY use a compression algorithm called DEFLATE, the most common compression algorithm used, which compresses HTTP requests by eliminating duplicate strings.
CRIME takes advantage of the method in which duplicate strings are eliminated to guess session tokens by systematically brute-forcing them.
Every instance of a duplicate string is replaced by a pointer to the first occurrence of the string.
Thus more redundancy in data needs more compression and thus smaller will be the length of the HTTP request. The attacker exploits this logic.
How to avoid CRIME Attack
All major web browsers have either been patched or do not support SSL/TLS/SPDY compression at all.
So the client level compression should be disabled as per the industry standard. Ensure that connection to a host’s web page uses these browser versions or higher:
- Internet Explorer: No versions of IE support SSL/TLS Compression
- Chrome: 21.0.1180.89
- Firefox: 15.0.1
- Opera: 12.01
- Safari: 5.1.7
3. BREACH ATTACK
BREACH attacks HTTP responses compressed using the common HTTP compression, otherwise known as content encoding, which is much more common than TLS-level compression.
To be vulnerable to a BREACH attack, a web application must:
Be hosted on a server that uses HTTP-level compression
Reflect user-input in HTTP response bodies
Reflect a secret (such as a CSRF token) in HTTP response bodies
An attacker with the ability to inject partially chosen plaintext into a victim’s requests and measure the size of encrypted traffic, can take advantage of information leaked by compression to recover targeted parts of the plaintext.
By injecting plaintext into an HTTPS request and observing the length of compressed HTTPS responses, an attacker is able to iteratively calculate and derive plaintext secrets from an SSL stream.
How to Mitigate BREACH Attack
Disabling HTTP compression
Separating secrets from user input
Randomizing secrets per request
Masking secrets (effectively randomizing by XORing with a random secret per request)
Protecting vulnerable pages with CSRF
Length hiding (by adding a random number of bytes to the responses)
Rate-limiting the requests
Conclusion
In short, to protect against all known and unknown TLS downgrade attacks, the best thing is to update your systems to the latest version of TLS.
That way, it won’t support any backward compatibility.
It becomes possible to safely disable the server support for all TLS protocols except TLS 1.3. This protocol does not consist of any major vulnerabilities as the older versions and is safe to use, as of now.
