Hacker News Reader

Comment by davidben | Hacker News Reader

The blog isn't quite right. HTTP/2 requires ECDHE (or DHE, but don't do that) with an AEAD, which means one of the GCMs or CHACHA20_POLY1305 if you have it. It's written as a blacklist, but this was the intent.

What's going on is Chrome and Firefox don't do AES_256_GCM (but Chrome will be adding support in the next release, see [1]), which means it was picking a CBC mode cipher and HTTP/2 wouldn't allow it.

SSL Labs is, in my opinion, wrong about incentivizing AES_256_CBC over AES_128_GCM. The CBC mode ciphers in TLS are composed wrong and very very difficult to implement safely. They'll be gone in TLS 1.3.

[1] https://groups.google.com/a/chromium.org/d/msg/security-dev/...

View on HN

I appreciate the information you've given, but such a list of acronyms is exactly why so many webservers are configured incorrectly. Why can't this be made easier? Maybe flags like "Modern Support Only" or "Legacy Browser Support".

If you use the Mozilla SSL Configuration Generator [0], you can select "Modern", "Intermediate", or "Old", and end up with a cut-and-paste configuration snippet that'll best suit your specific needs.

[0]: https://mozilla.github.io/server-side-tls/ssl-config-generat...

That's really useful, thank you.

But my question still stands - why do nginx and Apache not provide the same settings as a configuration option?

Because what is implied by those terms changes over time, and minor changes can have major impacts on accessibility by older clients.

Can you explain how it isn't quite right? I would like to correct the article if this is the case.

When I ran the code, the Go HTTP/2 package caused a panic with the message "http2: TLSConfig.CipherSuites is missing HTTP/2-required TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".

I went source diving and found the following:

https://golang.org/src/net/http/h2_bundle.go?h=TLS_ECDHE_RSA...

It even has the helpful comment:

> If they already provided a CipherSuite list, return an error if it has a bad order or is missing ECDHE_RSA_WITH_AES_128_GCM_SHA256.

I cannot see how I would have achieved my aim without disabling HTTP/2.

The aim of the exercise was to get a perfect score using Go. I wasn't discussing HTTP/2 in general. I was referencing the Go standard library implementation.

As I say, if you still think it's not right, please let me know.

The specific detail that you've noticed in the Go implementation has to do with RFC 7540, Section 9.2.2 (https://tools.ietf.org/html/rfc7540#section-9.2.2) which requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 only. Deployments of the future TLS 1.3 are free to not support this cipher, if I am reading the RFC correctly.

That is to say, you're correct that server configured for a 100% on SSLLabs will not support HTTP/2, but I agree with davidben that SSLLabs is incorrect here for incetivising AES-256, particularly in CBC mode, for the 100% score.

Reply on news.ycombinator.com