Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The POODLE bites again

imperialviolet.org

Post reply on HN
Print view View original

11–17 of 17 posts

Re: The POODLE bites again

#11

Post by cesarb »

colmmacc wrote: post #10
tacoman wrote: post #9

"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?

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.

For the future, there's also the encrypt-then-MAC extension (https://tools.ietf.org/html/rfc7366, 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://bugzilla.mozilla.org/show_bug.cgi?id=917571, already on Chrome AFAIK).

For now, AES-GCM is the best alternative.

Re: The POODLE bites again

#12

Post by edwintorok »

cesarb wrote: post #11
colmmacc wrote: post #10

Earlier quoted context omitted.

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.

For the future, there's also the encrypt-then-MAC extension ( https://tools.ietf.org/html/rfc7366 , 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://bugzilla.mozilla.org/show_bug.cgi?id=917571 , already on Chrome AFAIK). For now, AES-GCM is the best alternative.

I like the alternative described here: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...

"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).

Re: The POODLE bites again

#14

Post by yuhong »

feld wrote: post #13
yuhong wrote: post #8

Earlier quoted context omitted.

I know, the goal is to prepare.

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

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.

Re: The POODLE bites again

#15

Post by feld »

yuhong wrote: post #14
feld wrote: post #13

Earlier quoted context omitted.

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

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.

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

Re: The POODLE bites again

#16

Post by yuhong »

feld wrote: post #15
yuhong wrote: post #14

Earlier quoted context omitted.

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.

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

It is as simple as setting the version in the ClientHello message.
Post reply on HN