Why does it have to be this way?
This article in a nice exercise, but not a guide you should follow in production. The HTTP/2 ciphersuites recommendations are great, and there's no security reason to disregard them.
I even go as far to say:
> You should probably stop here. Continuing to attempt to achieve a perfect score will result in reduced client compatibility. This means that many users will not be able to access your site.
I should probably have also said that it is unlikely to be their intentions. An A+ is more than good enough.
This was just an exercise to better understand how to influence the score with a Go server as I've read a few in the past for NGINX, Apache etc.
Aiming for 100% in all ares was just a fun, but mostly pointless metric. It did, however uncover a couple of interesting things along the way.
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/...
[0]: https://mozilla.github.io/server-side-tls/ssl-config-generat...
But my question still stands - why do nginx and Apache not provide the same settings as a configuration option?
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.
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.
There's no reason that 128 but cannot be used today, particularly for transport encryption.
Google has SINGLEHANDEDLY improved the security of the TLS ecosystem by light-years:
* They ship the most modern client (Chrome), and started the auto-update trend.
* They forced the move from SHA1 and RC4 by leveraging that client power (with the degraded UI messages) even if it costed them popularity.
* They are leading CT, the single next best thing to happen to the ecosystem.
* They are keeping CAs accountable like no one did before.
* They have amazing people working on security UX and even shared the messages they use for anyone else to use.
* Finally, Chrome is by far the most secure browser you can use thanks to its state-of-the-art sandbox.
And take your client side certificates grudge somewhere else.