9

February 9, 2019: Source: New TLS encryption-busting attack also impacts the newer TLS 1.3

"Seven researchers from all over the world found --yet again-- 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."

Is TLS_ECDHE_RSA, and DHE_RSA, also affected? Or only TLS_RSA? If not please explain why.

Windows update example:

fe2.update.microsoft.com.nsatc.net offered
TLS_ECDHE_RSA_WITH_AES128_GCM_SHA384
x25519

EC Diffie-Hellman Server Params
                Curve Type: named_curve (0x03)
                Named Curve: x25519 (0x001d)
                Pubkey Length: 32
                Pubkey: e3267867db92a040eae6ea57bdb8e042680fa2e95da1e983...
                Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                Signature Length: 256
14

This article is poorly written. First, by this time, it's old news: the attack was made public over two months ago. Oddly there doesn't seem to have been a thread about this attack here before, but there was one on Cryptography Stack Exchange which you can read for an introduction to how the attack works.

A second way in which this article is misleading is that this attack does not impact TLS 1.3 in itself. It impacts servers that support TLS 1.3 and older versions, if the attacker manages to downgrade the connection.

“The most common RSA configuration used to encrypt TLS connections” is also misleading. It's technically true, in that it is the only TLS configuration that uses RSA for encryption, but in fact most TLS configurations that use RSA use it for signature, not for encryption.

The attack works only against TLS_RSA cipher suites, i.e. against cipher suites that have RSA in their name but not DHE or ECDHE. It attacks RSA decryption. Cipher suites that use RSA signature, or that don't use RSA at all, are not affected.

In order to perform the direct attack, the attacker has to convince the victims to use TLS ≤1.2 with an RSA-decryption cipher suite. It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites. The client then sends a value encrypted with the server's public key, and the attacker must decrypt it to continue talking to the client. Normally decrypting the value requires the private key, but if the server is vulnerable to the attack, then the attacker is able to trick the server into decrypting that value by making many connections to the server with an RSA-decryption cipher suite, sending carefully-chosen ciphertexts and observing the precise timing of the server's response.

Even if the client refuses to use RSA-decryption cipher suites, or indeed even if the client only supports TLS 1.3, it may still be vulnerable if the server uses the same RSA private key for decryption and for signature. To perform this variant of the attack, the attacker is once again a man-in-the-middle, and it uses an RSA-signature cipher suite to talk to the client. At some point the attacker needs to sign a value with the server's private key, and it does this as above by making many connections to the server with an RSA-decryption cipher suite.

To protect against this attack, you can do any of the following:

  • Keep your server up to date. This is the best way to protect against every attack.
  • Disable RSA-decryption cipher suites on the server.
  • Disable RSA-decryption cipher suites on the client and not use the same RSA private key for decryption and signature on the server.
  • 3
    I find the name "RSA-decryption cipher suite" a bit misleading since these are usually not called this way. These are actually cipher suites that use the RSA key exchange. But yes, RSA key exchange makes use of RSA decryption, but only for getting the pre-master secret and not for decryption of application data. – Steffen Ullrich Feb 10 at 5:05
  • The work also represents signature forging, see the table II. – kelalaka Feb 10 at 12:22
  • "It can often do that by hijacking the very beginning of the connection (it's a man-in-the-middle attack) and telling the client that it only supports TLS 1.2 (or some earlier version) and only RSA-decryption cipher suites." Is such an attack even possible? This answer implies that it's not, and that forcing a browser downgrade (by blocking higher-version attempts) should be foiled by a modern client and server supporting TLS_FALLBACK_SCSV. – Bob Feb 10 at 14:23
  • 2
    @Bob FALLBACK_SCSV doesn't help here. It stops a mitm from forcing a downgrade of the connection between the server and the client. But here, the server and the client don't connect directly, they both hold a TLS session to the attacker. – Gilles Feb 10 at 21:28
  • 1
    Disabling TLS 1.2 or lower would of course also work as there is no RSA key exchange (or rather key establishment, in my opinion) is present. TLS 1.3 is however rather new at this point so I don't think this is a good idea for e.g. browser to server connections yet. It would make a lot of sense for B2B connections to agree on one TLS 1.3 suite and disable everything else, including TLS 1.2. – Maarten Bodewes Feb 12 at 1:16

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.