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.⁶

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.⁷ 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.

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.