[davidben]

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

[blowski]

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

[jlgaddis]

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

[blowski]

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?

[stouset]

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

[MrPeterLambert]

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.

[achernya]

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.