
New TLS Padding Oracles - jakobdabo
https://github.com/RUB-NDS/TLS-Padding-Oracles
======
bcaa7f3a8bbc
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
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.

~~~
colmmacc
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
Couldn't length-hiding be done more effectively (than CBC) at the HTTP layer
by injecting random headers?

~~~
colmmacc
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
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
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.

~~~
tedunangst
Measurably? I think you have a point about length hiding, although many models
seem to just dismiss it, but I'm not sure the accidental padding you get from
CBC is measurably better.

Scenario 1: https, downloading a file. Plus or minus a few bytes is still
accurate enough for identification, no?

Scenario 2: ssh, where one keystroke equals one packet, regardless of length.
I can still hear your password.

Did you have a scenario in mind where CBC padding provides a meaningful degree
of length obfuscation?

~~~
colmmacc
The case I think about the most is web fingerprinting. For example if the
authorities in a country that funnels all external traffic through a point of
mediation want to identify who is reading certain specific pages on wikipedia
- they likely can.

The most effective forms of web fingerprinting focus on static resources; the
two most prominent papers focus on Google Maps tiles, and Netflix videos,
which were both collections of static resources that were compressed offline.
Static resources are easier to target because the size of response is fixed,
and the domains they're hosted on tend to be relatively free from cookies,
auth tokens, query strings, and other noise.

In practical terms for attackers, it's easiest to focus on the images, CSS and
javascript that your browser is downloading; since these are usually static,
pre-compressed, and on CDN-hosted domains. This is pretty feasible against
Wikipedia, but also Facebook shares, tweets, etc ... anywhere where you're
viewing content that includes images or video.

O.k. so far nothing controversial, nobody would even get much of a paper
published about this, we bucket it under "Traffic Analysis" and while it might
shock the average internet user, cryptographers aren't surprised.

Where CBC vs GCM comes in is that GCM reduces the "cost" of these fingerprints
and increases the effectiveness of the whole approach. If a webpage contains
say 4 images, and an external CSS reference, that gives you 10 points of
information to fingerprint. You get 5 request lengths and 5 response lengths.
Given the spread of URL lengths and file sizes, it's pretty easy for that
combination to be unique, or at least narrow things down to a small set of
possibilities. With CBC enabled, each request length and response length is
rounded to the nearest 16-bytes. That's not a huge amount of padding, more
would be better, but it still reduces the uniqueness of the fingerprinting by
an exponential factor. It's particularly effective on the request lengths,
which are small to begin with.

Now with more requests, and a bigger graph, it's still probably possible to
de-fuzz this; but my point is that in practical terms - when you have exact
lengths, you just don't need to this. With exact lengths, you can ask a junior
SDE to code this up for you in a few weeks. Someone who barely understands
tcpdump and mysql can build this. With blocks and /some/ length hiding, the
same person finds that they get less signal and have to correlate between more
requests and pages, it might not even be practical for many sites. On
principle, I think it's dumb to lower costs for practical attacks like this.

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

~~~
lol768
>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
> _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
>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
> 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.

