

The POODLE bites again - deepblueocean
https://www.imperialviolet.org/2014/12/08/poodleagain.html

======
tacoman
"This seems like a good moment to reiterate that everything less than TLS 1.2
with an AEAD cipher suite is cryptographically broken."

So this means AES-GCM essentially?

~~~
colmmacc
Well, almost. AES-GCM is also "Cryptographically Broken" if you take into
account software implementations using table lookup schemes that are subject
to cache timing attacks. But the fundamental AEAD support in TLS1.2 is a much
better place to be overall - and GCM tags are much better than the MAC-then-
Encrypt HMACs elsewhere in TLS. For practical purposes; AES-GCM is the "least
worst", by a long way.

~~~
cesarb
For the future, there's also the encrypt-then-MAC extension
([https://tools.ietf.org/html/rfc7366](https://tools.ietf.org/html/rfc7366),
[https://bugzilla.mozilla.org/show_bug.cgi?id=972145](https://bugzilla.mozilla.org/show_bug.cgi?id=972145)),
and probably some variant of a ChaCha20+Poly1305 AEAD
([https://tools.ietf.org/html/draft-agl-tls-
chacha20poly1305-0...](https://tools.ietf.org/html/draft-agl-tls-
chacha20poly1305-04),
[https://bugzilla.mozilla.org/show_bug.cgi?id=917571](https://bugzilla.mozilla.org/show_bug.cgi?id=917571),
already on Chrome AFAIK).

For now, AES-GCM is the best alternative.

~~~
edwintorok
I like the alternative described here:
[https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...](https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html)

"The end result is that Chrome talking to Google uses AES-GCM if there's
hardware support at the client and ChaCha20-Poly1305 otherwise."

It seems to be specific to Chrome though, and all TLS clients would have to
reimplement that choice. Would be good if there was a way to tell the SSL
library to give you the best cipher that works on your hardware (i.e. don't
give AES-GCM/AES-CBC when there is no hardware support and the software
implementation isn't constant time).

------
huxley
Link didn't work for me, here is the Google Cache text version:

[http://webcache.googleusercontent.com/search?q=cache:f01MHrX...](http://webcache.googleusercontent.com/search?q=cache:f01MHrX8LTAJ:https://www.imperialviolet.org/2014/12/08/poodleagain.html&strip=1)

------
resonantcore
We look forward to TLS 1.2 support being the norm. (And then, hopefully, the
ratification and adoption of TLS 1.3)

A 50% adoption rate is excellent news. Still a long way to go, but that's
worth toasting over.

~~~
yuhong
What is frustrating is how many such servers have TLS 1.3 intolerance (even
PayPal), and often the same servers are also affected by this bug. I wonder
what TLS implementation is this.

~~~
feld
TLS 1.3 isn't finished yet...

~~~
yuhong
I know, the goal is to prepare.

~~~
feld
I'm not sure what you mean then by servers having TLS 1.3 intolerance.

~~~
yuhong
It does not respond properly to clients trying to negotiate TLS 1.3. It should
return a ServerHello showing the supported TLS 1.2 version.

~~~
feld
I wasn't aware there was a TLS 1.3 PoC that people could use for testing.

~~~
yuhong
It is as simple as setting the version in the ClientHello message.

~~~
feld
Oh, I see

------
cryptbe
POODLE worked not only against SSLv3, but also against any TLS implementations
that check padding in SSLv3's style (e.g., just checking the last byte, and
ignoring the rest of the padding). SSL accelerators from F5 and A10 were
vulnerable. Thus, many of the world's largest sites were vulnerable.

------
eyeareque
Are there any more details than what this write up contains?

