7 ms·

New TLS Padding Oracles

73 points by jakobdabo 8y ago

stingraycharles 8y ago
Are these actually novel vulnerabilities, or just unpatched CBC vulnerabilities? As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks.
- olliej 8y ago
  That was my exact thought - CBC mode is not secure against a vast array of attacks, and I’m not sure if I want to read an entire paper to determine if there’s anything new/novel in attacking a known weak cipher mode
  - olliej 8y ago
    Ok, so I did the work of reading/skimming :D Essentially these are implementation specific bugs resulting in oracles, rather than being attacks on CBC itself - basically openssl and some embedded (?) TLS stacks produce different results (delayed hang up and/or different error codes) for padding vs. MAC failures in CBC mode. I assume that the joy of CBC mode just makes those oracles easier to directly exploit. The exploits are still harder to use than GCM with a reused nonce (reusing a nonce in GCM mode essentially breaks it. GCM is hard).
  - tptacek 8y ago
    No, this isn't true. CBC mode is generally fine. The problem is improperly authenticated CBC. But improperly authenticated CTR is also insecure, and CTR is an essential building block of a whole bunch of modern AEAD schemes, including GCM. CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them. Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM. The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.
    - weinzierl 8y ago
      > You're less likely to blow that up than GCM. Do you have a pointer where I can read about traps of GCM?
      - tptacek 8y ago
        I don't know the best summary, but the broad strokes are that nonce reuse both destroys confidentiality and allows recovery of authentication keys --- this is an extraordinarily common problem and one attackers can sometimes induce --- as does truncating the GCM MAC, and, if you don't have hardware support for GCM (ie, x64 CLMUL), the table-based version is timable.
        deleted 8y ago
        [deleted]
- lol768 8y ago
  >As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks was that they were the result of an implementation vulnerability that leaked information through error messages about the padding being the cause. Not that the problem was an inherent flaw in CBC itself. If the server simply used generic error messages when the padding was invalid, there would be no 'oracle' AIUI. Edit: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
  - bcaa7f3a8bbc 8y ago
    > Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
    - lol768 8y ago
      >But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
      - blattimwind 8y ago
        > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
    - 8y ago
- tptacek 8y ago
  They're novel instances of a bug class, the same way a new use-after-free in Chrome is a novel bug. This is what makes crypto vuln research so great: the published work deals mostly in bug classes, which can be leveraged against systems ad infinitum.
bcaa7f3a8bbc 8y ago
CBC mode in TLS SHOULD NOT be used in any new systems. Repost Moxie's The Cryptographic Doom Principle, again... https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/
- tptacek 8y ago
  You're right, of course. To be clear, though, the "doom principle" simply says "encrypt then MAC or die". TLS reverses the order (it was designed before this problem was seriously studied). TLS's CBC mode is flawed, but CBC mode in general --- I still wouldn't use it! --- is basically OK.
  - blattimwind 8y ago
    But when CBC is used correctly (with authentication), then one could just as well use CTR and get a nice performance improvement. The differences between these two (IV reuse, malleability) only become relevant when they're used incorrectly in the first place.
    - tptacek 8y ago
      I would probably generally use CTR? But you can chop this up in different ways; CTR is faster than CBC, and slightly less code to implement, but CBC (assuming EtM) fails less catastrophically than CTR if initialized improperly. CBC+HMAC-SHA2 is probably the safest thing you can implement from scratch. People should just use Tink or Nacl though.
  - colmmacc 8y ago
    Deep breath. I know that I'm going to be thought a heretical fool for saying this, but overall I would consider CBC mode "more secure" than GCM. Of course encrypt-then-MAC would be preferable (which TLS now supports, though implementations are scarce) ... but even with the broken Mac-Then-Encrypt variant that we have today ... still more secure. It's a case of choose your poison. With the Mte CBC vulns, we've seen some pretty hard to implement padding oracles; I don't think that these attacks are in general practical or a big risk for real-world users and workloads. It's awful, ugly, stuff, but it's also something that the internet has been able to stay on top of with patching. On the other hand the mass-deployment of AES-GCM, we've deployed a length preserving cipher as the world's default for network traffic. An exact length-preserving mode makes realistic mass content fingerprinting attacks far cheaper and more feasible. These are very practical passive attacks that happen mostly out of band ... so I think it's a mistake to make these easier. In real terms, AES-GCM reduces by a exponential factor the amount of state that a FVEY-style attacker must maintain to mostly-successfully identify what webpages you are browsing. It's so much more feasible, in the realm of an undergrad term project, that I would be surprised if it is not occurring. Even a modestly resourced security agency with relatively sophomoric skills can do it. To my mind, making a practical passive attack much cheaper, to the point that it may be occurring (though that's a guess, I have no information) to be able to turn our nose at a cryptographic construct that offends us, but is less practical to attack ... seems to me like the wrong trade-off. At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own).

73 points by jakobdabo 8y ago

Are these actually novel vulnerabilities, or just unpatched CBC vulnerabilities? As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks.

olliej 8y ago
That was my exact thought - CBC mode is not secure against a vast array of attacks, and I’m not sure if I want to read an entire paper to determine if there’s anything new/novel in attacking a known weak cipher mode
- olliej 8y ago
  Ok, so I did the work of reading/skimming :D Essentially these are implementation specific bugs resulting in oracles, rather than being attacks on CBC itself - basically openssl and some embedded (?) TLS stacks produce different results (delayed hang up and/or different error codes) for padding vs. MAC failures in CBC mode. I assume that the joy of CBC mode just makes those oracles easier to directly exploit. The exploits are still harder to use than GCM with a reused nonce (reusing a nonce in GCM mode essentially breaks it. GCM is hard).
- tptacek 8y ago
  No, this isn't true. CBC mode is generally fine. The problem is improperly authenticated CBC. But improperly authenticated CTR is also insecure, and CTR is an essential building block of a whole bunch of modern AEAD schemes, including GCM. CBC mode is also susceptible to attacks based on predictable IVs. But again, CTR is susceptible to a sort of isomorphic class of bugs related to repeated nonces --- as, of course, is GCM, which you mention before; GCM not only inherits CTR's brittleness with respect to nonces but also fails in spectacular new ways with them. Arguably, if you're going to have to build your own cryptosystem from primitives (don't do this), you have the best chance of success with random-IV CBC mode and HMAC-SHA2 in an EtM configuration. You're less likely to blow that up than GCM. The research here is in detecting instances of the well-understood CBC padding oracle flaw. A new measurement technique that surfaced a whole bunch of new instances of heap overflows in server software would be an important contribution, in the same way this is.
  - weinzierl 8y ago
    > You're less likely to blow that up than GCM. Do you have a pointer where I can read about traps of GCM?
    - tptacek 8y ago
      I don't know the best summary, but the broad strokes are that nonce reuse both destroys confidentiality and allows recovery of authentication keys --- this is an extraordinarily common problem and one attackers can sometimes induce --- as does truncating the GCM MAC, and, if you don't have hardware support for GCM (ie, x64 CLMUL), the table-based version is timable.
      - deleted 8y ago
        [deleted]
lol768 8y ago
>As far as I am aware CBC has been discouraged for a long time precisely because of the padding oracle attacks My understanding of these padding oracle attacks was that they were the result of an implementation vulnerability that leaked information through error messages about the padding being the cause. Not that the problem was an inherent flaw in CBC itself. If the server simply used generic error messages when the padding was invalid, there would be no 'oracle' AIUI. Edit: https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
- bcaa7f3a8bbc 8y ago
  > Not that there was an inherent flaw in CBC itself. But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created.
  - lol768 8y ago
    >But if history shows it's difficult to implement something without creating vulnerabilities, and there are alternatives which are less prone to mistakes, it should be retired and discouraged to be implemented. >Also, CBC itself is not an actual problem, but CBC in TLS is authenticate-then-encrypt, which is how the vast majority of problems are created. Oh definitely, GCM (or another AEAD cipher) is a much better choice - I wouldn't argue in favour of CBC in production TLS cipher suites. I just wanted to comment on the technical details of where padding oracle vulnerabilities actually arise.
    - blattimwind 8y ago
      > Oh definitely, GCM (or another AEAD cipher) is a much better choice GCM is only a better choice if you have hardware support for it. I'd recommend Chacha20-Poly1305 for anything that might have to cope without hardware support.
  - 8y ago
tptacek 8y ago
They're novel instances of a bug class, the same way a new use-after-free in Chrome is a novel bug. This is what makes crypto vuln research so great: the published work deals mostly in bug classes, which can be leveraged against systems ad infinitum.

bcaa7f3a8bbc 8y ago

CBC mode in TLS SHOULD NOT be used in any new systems. Repost Moxie's The Cryptographic Doom Principle, again... https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/

tptacek 8y ago
You're right, of course. To be clear, though, the "doom principle" simply says "encrypt then MAC or die". TLS reverses the order (it was designed before this problem was seriously studied). TLS's CBC mode is flawed, but CBC mode in general --- I still wouldn't use it! --- is basically OK.
- blattimwind 8y ago
  But when CBC is used correctly (with authentication), then one could just as well use CTR and get a nice performance improvement. The differences between these two (IV reuse, malleability) only become relevant when they're used incorrectly in the first place.
  - tptacek 8y ago
    I would probably generally use CTR? But you can chop this up in different ways; CTR is faster than CBC, and slightly less code to implement, but CBC (assuming EtM) fails less catastrophically than CTR if initialized improperly. CBC+HMAC-SHA2 is probably the safest thing you can implement from scratch. People should just use Tink or Nacl though.
- colmmacc 8y ago
  Deep breath. I know that I'm going to be thought a heretical fool for saying this, but overall I would consider CBC mode "more secure" than GCM. Of course encrypt-then-MAC would be preferable (which TLS now supports, though implementations are scarce) ... but even with the broken Mac-Then-Encrypt variant that we have today ... still more secure. It's a case of choose your poison. With the Mte CBC vulns, we've seen some pretty hard to implement padding oracles; I don't think that these attacks are in general practical or a big risk for real-world users and workloads. It's awful, ugly, stuff, but it's also something that the internet has been able to stay on top of with patching. On the other hand the mass-deployment of AES-GCM, we've deployed a length preserving cipher as the world's default for network traffic. An exact length-preserving mode makes realistic mass content fingerprinting attacks far cheaper and more feasible. These are very practical passive attacks that happen mostly out of band ... so I think it's a mistake to make these easier. In real terms, AES-GCM reduces by a exponential factor the amount of state that a FVEY-style attacker must maintain to mostly-successfully identify what webpages you are browsing. It's so much more feasible, in the realm of an undergrad term project, that I would be surprised if it is not occurring. Even a modestly resourced security agency with relatively sophomoric skills can do it. To my mind, making a practical passive attack much cheaper, to the point that it may be occurring (though that's a guess, I have no information) to be able to turn our nose at a cryptographic construct that offends us, but is less practical to attack ... seems to me like the wrong trade-off. At least with TLS1.3 and QUIC we can pad encrypted data and get a measure of length-hiding back; enough to at least raise costs for passive fingerprinting attacks (and raise those costs more than CBC ever could on its own).