6 ms·

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

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).
  - tptacek 8y ago
    Couldn't length-hiding be done more effectively (than CBC) at the HTTP layer by injecting random headers?
    - colmmacc 8y ago
      Yes! I've experimented with server-side changes, but unfortunately the request length leaks information too, so the client needs to do something similar. In real terms, I think the consequence of the rapid mass-migration away from CBC made the passive attacks far easier; instead of building graphs and de-fuzzers, analysts can identify content using combined request and response length signatures. All of that happened purely at the cryptographic layer, and it's unfortunate. In general, it's hard to ask HTTP servers and applications higher up the stack to take it on; the folks writing those ton'd tend to be cryptography or SIGINT experts. It's still easy enough to find subtle CRIME-like compression attacks against servers and applications that mix compression and untrusted input, which is some sign of how effective we all are at chasing down similar kinds of issues at those layers.
      - tptacek 8y ago
        Certainly this logic doesn't suggest using CBC instead of an AEAD for a new, non-TLS system, where, if traffic analytic attacks were a concern, you'd just bake that into the protocol itself while still claiming the benefits of modern authenticated encryption.
        colmmacc 8y ago
        That's a tough call. We've thoroughly learned that not only should developers not build their own cryptographic primitives, but that they shouldn't even trivially combine them on their own. "Use AEAD" (or better yet: use noise) is good advice for application and protocol designers who on their own probably wouldn't even think about the problems ... but it's not sufficient. We haven't seemed to learn that length hiding, traffic analysis, and shared compression dictionaries are all so firmly in the realm of what encryption is supposed to do ... make content secret ... that developers also can't be trusted to get these right on their own. So if you're in the position to telling someone to use AEAD instead of CBC, I'd make sure to also tell them that they should think hard about length hiding, message timing, and shared compression dictionaries, and whether those are important concerns in that environment. Oh and they still have to watch out for IV problems with plenty of the AEAD implementations. Personally I long for some better crypto boxes than "AEAD" and I should really get off my butt and define one; at the level of total hand-waving, I trust cryptographers more to review this stuff much better than protocol designers. Like here I am claiming that TLS, the most pervasive network encryption protocol, has actually gotten measurably less secure at encryption, by at least one important measure, in the last 5 years.
microcolonel 8y ago
There's a downside to this, if you're trying to serve people running Safari on OSX Yosemite or older. Nobody cares about Windows Phone 8.1 though so you're probably safe there. [0] [0]: https://www.ssllabs.com/ssltest/analyze.html?d=qui.suis.je&s=2604%3aa880%3a800%3a10%3a0%3a0%3a12f%3a3001 https://www.ssllabs.com/ssltest/analyze.html?d=qui.suis.je&s...
- pvg 8y ago
  Safari gets backported, usually for a major release or two.
  - microcolonel 8y ago
    Ahh yes, seems like a bit of a mess. 10.9 got 9.1.3, but 10.8 stopped at 6.2.8.

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).
- tptacek 8y ago
  Couldn't length-hiding be done more effectively (than CBC) at the HTTP layer by injecting random headers?
  - colmmacc 8y ago
    Yes! I've experimented with server-side changes, but unfortunately the request length leaks information too, so the client needs to do something similar. In real terms, I think the consequence of the rapid mass-migration away from CBC made the passive attacks far easier; instead of building graphs and de-fuzzers, analysts can identify content using combined request and response length signatures. All of that happened purely at the cryptographic layer, and it's unfortunate. In general, it's hard to ask HTTP servers and applications higher up the stack to take it on; the folks writing those ton'd tend to be cryptography or SIGINT experts. It's still easy enough to find subtle CRIME-like compression attacks against servers and applications that mix compression and untrusted input, which is some sign of how effective we all are at chasing down similar kinds of issues at those layers.
    - tptacek 8y ago
      Certainly this logic doesn't suggest using CBC instead of an AEAD for a new, non-TLS system, where, if traffic analytic attacks were a concern, you'd just bake that into the protocol itself while still claiming the benefits of modern authenticated encryption.
      - colmmacc 8y ago
        That's a tough call. We've thoroughly learned that not only should developers not build their own cryptographic primitives, but that they shouldn't even trivially combine them on their own. "Use AEAD" (or better yet: use noise) is good advice for application and protocol designers who on their own probably wouldn't even think about the problems ... but it's not sufficient. We haven't seemed to learn that length hiding, traffic analysis, and shared compression dictionaries are all so firmly in the realm of what encryption is supposed to do ... make content secret ... that developers also can't be trusted to get these right on their own. So if you're in the position to telling someone to use AEAD instead of CBC, I'd make sure to also tell them that they should think hard about length hiding, message timing, and shared compression dictionaries, and whether those are important concerns in that environment. Oh and they still have to watch out for IV problems with plenty of the AEAD implementations. Personally I long for some better crypto boxes than "AEAD" and I should really get off my butt and define one; at the level of total hand-waving, I trust cryptographers more to review this stuff much better than protocol designers. Like here I am claiming that TLS, the most pervasive network encryption protocol, has actually gotten measurably less secure at encryption, by at least one important measure, in the last 5 years.

microcolonel 8y ago

There's a downside to this, if you're trying to serve people running Safari on OSX Yosemite or older. Nobody cares about Windows Phone 8.1 though so you're probably safe there. [0] [0]: https://www.ssllabs.com/ssltest/analyze.html?d=qui.suis.je&s=2604%3aa880%3a800%3a10%3a0%3a0%3a12f%3a3001 https://www.ssllabs.com/ssltest/analyze.html?d=qui.suis.je&s...

pvg 8y ago
Safari gets backported, usually for a major release or two.
- microcolonel 8y ago
  Ahh yes, seems like a bit of a mess. 10.9 got 9.1.3, but 10.8 stopped at 6.2.8.