By integrating cybersecurity and complex architectures in the IT field, we cannot appreciate enough the unprecedented security developed by Netscape Corporation.
Besides developing Navigator, the browser that would change the way the Internet was used by the masses, it also pioneered the Secure Sockets Layer (SSL) Protocol that enabled privacy and consumer protection.
The underlying technology used for their browsers at that time, Navigator and Communicator, still powers today’s security standard, Transport Layer Security (TLS).
Back in 1996, Washington Post published an article in which they speculated that Netscape might one day turn into a challenge for Microsoft, due to the fact that the software startup was growing very fast. It seems like they were right since, years later, the source code used for Netscape Navigator 4.0 would lead to the creation of Mozilla and its Firefox browser. This is one of the best alternatives to Google Chrome which, in 2016, managed to dethrone Internet Explorer, the browser created by Microsoft.
Although all modern browsers are using the SSL and TLS protocols pioneered by Netscape Corporation, these protocols had their fair share of vulnerabilities over the years. So, remember that using the latest browser, without any other security solution, doesn’t mean that you are protected against the latest attacks.
Here are some of the most prominent attacks involving breaches of the SSL/TLS protocols that had surfaced in recent years:
The Padding Oracle On Downgraded Legacy Encryption (POODLE) attack was published in October 2014 and exploits two aspects: the fact that some servers/clients still support SSL 3.0 for interoperability and compatibility with legacy systems and a vulnerability within SSL 3.0 that is related to block padding.
The client initiates the handshake and sends a list of supported SSL/TLS versions. An attacker intercepts the traffic, performing a man-in-the-middle (MITM) attack, and impersonates the server until the client agrees to downgrade the connection to SSL 3.0.
The SSL 3.0 vulnerability is in the Cipher Block Chaining (CBC) mode. Block ciphers require blocks of fixed length. If data in the last block is not a multiple of the block size, extra space is filled by padding. The server ignores the content of padding. It only checks if padding length is correct and verifies the Message Authentication Code (MAC) of the plaintext. That means that the server cannot verify if anyone modified the padding content.
An attacker can decipher an encrypted block by modifying padding bytes and watching the server response. It takes a maximum of 256 SSL 3.0 requests to decrypt a single byte. This means that once every 256 requests, the server will accept the modified value. The attacker does not need to know the encryption method or key. Using automated tools, an attacker can retrieve the plaintext character by character. This could easily be a password, a cookie, a session or other sensitive data.
The Browser Exploit Against SSL/TLS (BEAST) attack was disclosed in September 2011. It applies to SSL 3.0 and TLS 1.0 so it affects browsers that support TLS 1.0 or earlier protocols. An attacker can decrypt data exchanged between two parties by taking advantage of a vulnerability in the implementation of the Cipher Block Chaining (CBC) mode in TLS 1.0.
This is a client-side attack that uses the man-in-the-middle technique. The attacker uses MITM to inject packets into the TLS stream. This allows them to guess the Initialization Vector (IV) used with the injected message and then simply compare the results to the ones of the block that they want to decrypt.
The Compression Ratio Info-leak Made Easy (CRIME) vulnerability affects TLS compression. The compression method is included in the Client Hello message and it is optional. You can establish a connection without compression. Compression was introduced to SSL/TLS to reduce bandwidth. DEFLATE is the most common compression algorithm used.
One of the main techniques used by compression algorithms is to replace repeated byte sequences with a pointer to the first instance of that sequence. The bigger the sequences that are repeated, the higher the compression ratio.
All the attacker has to do is inject different characters and then monitor the size of the response. If the response is shorter than the initial one, the injected character is contained in the cookie value and so it was compressed. If the character is not in the cookie value, the response will be longer.
Using this method an attacker can reconstruct the cookie value using the feedback that they get from the server.
The Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) vulnerability is very similar to CRIME, but BREACH targets HTTP compression, not TLS compression. This attack is possible even if TLS compression is turned off. An attacker forces the victim’s browser to connect to a TLS-enabled third-party website and monitors the traffic between the victim and the server using a man-in-the-middle attack.
Heartbleed was a critical vulnerability that was found in the heartbeat extension of the popular OpenSSL library. This extension is used to keep a connection alive as long as both parties are still there.
The client sends a heartbeat message to the server with a payload that contains data and the size of the data (and padding). The server must respond with the same heartbeat request, containing the data and the size of data that the client sent.
The Heartbleed vulnerability was based on the fact that if the client sent false data length, the server would respond with the data received by the client and random data from its memory to meet the length requirements specified by the sender.
Leaking unencrypted data from server memory can be disastrous. There have been proof-of-concept exploits of this vulnerability in which the attacker would get the private key of the server. This means that an attacker would be able to decrypt all the traffic to the server. Server memory may contain anything: credentials, sensitive documents, credit card numbers, emails, etc.
This relatively new cryptographic attack can break encrypted TLS traffic, allowing attackers to intercept and steal data previously considered safe and secure.
This downgrade attack works even against the latest version of the TLS protocol, TLS 1.3, released in 2018 and considered to be secure.
This cryptographic attack is a variation of the original Bleichenbacher Oracle attack and represents yet another way to break RSA PKCS#1 v1.5, the most common RSA configuration used to encrypt TLS connections nowadays. Besides TLS, this new Bleichenbacher attack also works against Google’s new QUIC encryption protocol as well.
The attack leverages a side-channel leak via cache access timings of these implementations in order to break the RSA key exchanges of TLS implementations.
Even the newer version of the TLS 1.3 protocol, where RSA usage has been kept to a minimum, can be downgraded in some scenarios to TLS 1.2, where the new Bleichenbacher attack variation works.
In most cases, the best way to protect yourself against SSL/TLS-related attacks is to disable older protocol versions. This is even a standard requirement for some industries. For example, June 30, 2018, was the deadline for disabling support for SSL and early versions of TLS (up to and including TLS 1.0) according to the PCI Data Security Standard. The Internet Engineering Task Force (IETF) released advisories concerning the security of SSL. Deprecation of TLS 1.0 and 1.1 by IETF is expected soon.