The ROBOT Attack

RSA Encryption Is Vulnerable—
Choose ECC in TLS/SSL Certificates to Ensure Security

Guest article by Hanno Böck

The rebirth of an old attack

The predecessor of the ROBOT attack attack was found in 1998 by the cryptographer Daniel Bleichenbacher. It also became known as the “Million Message Attack.”

The exact details are complicated, but the basic idea of Bleichenbacher was this: By sending specially crafted faulty SSL messages to a server, he was able to learn tiny pieces of information about a ciphertext depending on what type of error the server was sending.

By sending enough messages, he could learn more and more and finally be able to fully decrypt something with the server’s private key.

A more secure cryptographic protocol

Over the years other researchers have found variations of Bleichenbacher’s attack and also improved it, so it doesn’t require “Million Messages” anymore
a few thousand are usually enough.

In 1998, SSL was officially renamed to TLS, and the first version (1.0) was the first properly standardized encryption scheme for the Internet.

TLS 1.0 contained countermeasures to Bleichenbacher’s attack. However, it turned out that the countermeasures were insufficient. Later TLS versionsthe current one is version 1.2—carried more complex countermeasures.

Vulnerability in 27 percent of Top 100 websites

What we found is that these countermeasures often aren’t implemented correctly. Attacks that are very similar to Bleichenbacher’s initial attack still work against a large number of TLS devices and hosts.

Particularly expensive appliances that are often used by large web pages were vulnerable:

Looking at the top 100 web pages (according to the Alexa Top 1 Million list), 27 of them were vulnerable when we started this research. When scanning the whole Alexa Top 1 Million list, the fraction of vulnerable web pages was around 27 percent of the top 100.

When scanning the whole Alexa Top 1 Million list, the fraction of vulnerable web pages was around 27 percent of the top 100.

Hanno Böck

Moving away from RSA encryption

TLS supports different encryption modes. The risk depends on the cipher modes used. Traditionally TLS and its predecessor SSL used RSA to encrypt a secret that was later used to secure a connection.

This traditional RSA encryption mode is most vulnerable to this attack. An attacker can simply observe and record traffic and subsequently use the vulnerable server to decrypt that data.

Forward secrecy as a better cipher mode

But the TLS ecosystem has mostly moved to better cipher modes. These still use RSA, but not for encryption. Instead, RSA is used as a signature algorithm, and the encryption key is negotiated with a key exchange algorithm.

These modes have a significant advantage: They provide a property called “forward secrecy.” That means that even if the key of a server gets stolen by an attacker, this doesn’t allow the attacker to decrypt traffic from the past. The forward secrecy cipher modes use Diffie Hellman or Elliptic Curve Diffie Hellman.

The use of forward secrecy in practice

It turns out that these forward secrecy modes also have advantages when it comes to Bleichenbacher attacks. While it is still possible to attack these modes, it’s far more challenging.

An attacker would have to perform the whole attack during a handshake, which usually takes between milliseconds and a few seconds. As the attack takes several thousand requests to a server, this is difficult to perform in practice. Furthermore, this is only possible if a server still supports the vulnerable RSA encryption mode.

RSA encryption should be updated or replaced by ECC

One conclusion we draw from our research is that the RSA encryption modes should be disabled:

Based on some observations on our servers and also based on data we got from Cloudflare, we believe that the number of legitimate Internet connections that still need these old encryption modes is very low.

Still, disabling RSA encryption can result in compatibility problems and may lock out users with old clients.

Particularly on email servers, we observed that many users with old Android versions use the old ciphers to log in. It is still better to offer TLS with RSA to those old clients than not using any encryption at all.

For those who don’t want to go that far and disable the RSA encryption modes, several vendors are providing updates. For affected devices from F5 and Radware, firmware updates are available.

Furthermore, the open-source TLS implementations from Erlang and WolfSSL have implemented fixes.

We identified more vulnerable vendors: The ROBOT web page contains a list of vulnerable vendors that will be updated once more information becomes available.

Old attacks keep coming back 

There are a few things to learn from the ROBOT attack: Like many other “famous” attacks on cryptography and TLS in the past years, it’s a new variant of an old attack.

DROWN was also a variant of Bleichenbacher’s attack, and many other attacks like BEAST, Lucky Thirteen, or Logjam were based on known weaknesses in cryptographic algorithms and constructions.

Compatibility an obstacle for a safer cipher mode

In the case of Bleichenbacher’s attack, the designers of TLS decided to propose incredibly complex countermeasures. With each new TLS version, the chapter describing these countermeasures became longer.

There would have been alternatives. There are safer RSA encryption modes, and the TLS designers could also have decided to move to forward secrecy earlier. But to retain compatibility, they decided to keep the old, dangerous RSA encryption mode.

RSA encryption will die when TLS 1.3 is introduced

With TLS 1.3, this will change. It no longer contains RSA encryption modes. However, that doesn’t necessarily mean that the risk is eliminated.

As previous research by a group of German cryptographers has shown: If the old RSA encryption modes are supported for old versions of TLS, they still pose a risk to modern protocols like TLS 1.3 or Google’s QUIC protocol.

The only safe way to get rid of ROBOT and Bleichenbacher’s attack is to fully disable RSA encryption in TLS.

Get in touch with us for a non-binding quote