The ROBOT attack is the rebirth of an old attack that endangers the security of TLS and HTTPS connections. It affects devices from multiple different vendors and depending on the situation allows the decryption of traffic and in some situations the impersonation of servers. The attack was discovered by a team including the author of this text.
The rebirth of an old attack
The predecessor of this 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.
The introduction of 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” any more, 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 versions – the current one is version 1.2 – contained more complex countermeasures.
We found the vulnerability in 27 percent of Top 100 of Alexa Top 1 Million list
What we found is that these countermeasures often aren’t implemented correctly. Attacks that are very similar to Bleichenbacher’s original 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 top 100.
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 than RSA encryption
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 big 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 replaced by ECC or be updated
One conclusion we draw from our research is therefore that the RSA encryption modes should be disabled. Based on some observations on our own 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 come with 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.
Also 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 ROBOT. Like many other “famous” attacks on cryptography and on 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 as an obstacle for a safer cipher mode
In the case of Bleichenbacher’s attack the designers of TLS decided to propose countermeasures that were incredibly complex. 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 in order 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.
TRUSTZONE SSL Labs
Testur your https-public domain for free using the TRUSTZONE SSL Labs and get a full report of how secure you are.
Your TLS configuration guide for OpenSSL
You can look at the OpenSSL TLS configuration guide, the modern profile recommended by Mozilla already comes without the problematic RSA cipher suites.
Your TLS configuration guide for Microsoft IIS
Powershell script to configure your IIS server with Perfect Forward Secrecy and TLS 1.2.
- Run the script from this guide.
- The box below shows in the final part ‘PKCS’ which should be removed if you want to disable RSA encryption.