Site Disclaimer: F5 Networks has a TLS stack that is vulnerable to the ROBOT attack. Normally we offer vendor-neutral application threat intelligence here at F5 Labs and do not mention F5 products because our sister site, DevCentral.f5.com does such a great job of that. In this article, however, we link to a few F5-specific technical articles where appropriate.
A trio of researchers, Hanno Böck, Juraj Somorovsky, and Craig Young, dusted off the old Bleichenbacher attack against RSA key exchanges and ran it against a set of modern TLS stacks, finding that some were vulnerable. They contacted each of the vulnerable websites they found and worked with the underlying TLS stack vendors, following the proper disclosure process. They’ve published their research in a paper titled “Return of Bleichenbacher’s Oracle Threat,”1 or “how we signed a message with Facebook’s private key.”
1998 Called and it Wants its Bleichen Back
The Bleichenbacher “million message attack”—the original padding oracle attack for TLS, sends variations of ciphertext at a TLS server.2 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 eventually reconstruct the session, one bit at a time. Within that TLS session, the attacker might find user credentials, and voilà, a breach! Bleichenbacher has since been refined to the point where this version requires only tens of thousands of attempts.3
The Bleichenbacher attack raises its head in Europe every now and then. Filippo Valsorda found one in the Python-RSA library in 2016.4 A German team found one in XML encryption in 2012. Another German team wrote about optimizations for Bleichenbacher in a 2014 paper.5
What’s the Impact?
Bleichenbacher is a neat little theoretical protocol attack. However, to my knowledge, no real Bleichenbacher attack has ever been seen in the field.
As server vulnerabilities go, this one hasn’t been terrible so far. The research team followed proper disclosure protocol and notified the vendors (and some affected customers), allowing the vendors to get their patches ready and tested. There were no known attacks happening in the field (though that may change at any time).
Attackers can only recover previously recorded TLS sessions at a slow rate, perhaps a few per day. Unless they get lucky and recover an administrator password in those few attempts, the damage could be minimal.
Eighty-six percent of Internet hosts prefer forward secrecy; all modern browsers do, too.
The Bleichenbacher attack only affects RSA sessions not protected with the ephemeral keys offered by forward secrecy. All modern browsers and mobile clients have preferred ephemeral keys for several years. Google has been preferring them with their servers and software since 2012.6
The scope of this particular threat is therefore limited to legacy clients—think Windows XP users —and the clients of sites that do not offer forward secrecy.
How Does the Attack Work?
There are two threat vectors presented by the research team mentioned at the beginning of this post. The first threat vector would be to get the Bleichenbacher padding oracle to decrypt a previously recorded TLS session.
In the second, the attacker would get the server to sign an arbitrary message with its RSA private key. The obvious thing to do would be to get the oracle to sign an active TLS handshake, allowing for a real TLS man-in-the-middle attack like Logjam.7 But Bleichenbacher 2017 could (probably) not do a MitM in real time. Even a Bleichenbacher 2017 attack requires tens of thousands of messages—and that’s its biggest limitation. Running the researchers’ POC code took 12 hours on my virtual test harness. Fast server hardware gets it down to a six hours but after Logjam, administrators figured they should bound the SSL handshake by six seconds or less to avoid this kind of problem.
Mitigation Strategies for Bleichenbacher 2017
Here are our recommendations for mitigating the Bleichenbacher 2017 attack.
- If your TLS stack manufacturer has issued patches, go get them and stage your software for testing and a production push.
- Tune your TLS stack so that it will not allow TLS handshakes to be outstanding for more than five to ten seconds. This will reduce the exposure to the (already unlikely) MitM scenario.
- Consider disabling RSA handshakes and relying on elliptic curve instead (more on this below).
- For those with programmable TLS stacks, implement a rate-limit for bad handshakes.
F5 customers can and should see this DevCentral article for F5-specific details and patch download locations.
Forward Secrecy to the Rescue?
Bleichenbacher only works against RSA handshakes, so elliptic curve and Diffie-Hellman handshakes are safe. According to F5 Labs’ 2016 TLS Telemetry Report, most of the Internet already supports (and prefers) forward secrecy so, in theory, you could “virtual patch” your servers by disallowing RSA handshakes and relying on the forward-secret ciphers ECDHE and DHE to carry the day.
It is possible to measure how much of your TLS is still using RSA. See this article on DevCentral for instructions on how to get those metrics on an F5 device.
Rate Limit Bad Handshakes
If your TLS solution has a programmable data plane, install a script to rate-limit bad TLS handshakes from individual IP addresses. F5 customers can reference this technical article for F5-specific implementation notes.
Why Does This Keep Happening?
If the Bleichenbacher attack has been known since 1998, why do implementations keep falling prey to it? One reason is that TLS implementers are just nice. They write code that tries to tell you why the server rejected your message. Maybe that information would be useful to the implementer of the client side. But, have you ever tried to debug a problem where the other side wouldn’t give you any useful information?
There is a proper way to foil oracle attacks. Instead of parsing the incoming message, the implementer of the server needs to construct a copy of what it expects to find, and then compare the incoming message to the copy. If they match, great. If not, then it should return a single error code. This approach fixes padding oracles and timing oracles, too.
Will This Be the Last Bleichenbacher?
The forthcoming TLS 1.3 protocol requires forward-secret ciphers, so it will be safe from RSA Bleichenbacher attacks. But adoption of TLS 1.3 is likely to be somewhat slow, because forward secrecy isn’t free and introduces major visibility problems for enterprises with significant SSL inspection investments. Therefore, we expect TLS 1.2 and its support of RSA handshakes to be around for several more years. And at the current rate of a Bleichenbacher every couple of years, we have a few more to see.
1 
