5 ms·

> No HTTP/2 for you! - HTTP/2 was enabled by default in go 1.6, however HTTP/2 mandates the support of the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. A

by dorianm 10y ago

> No HTTP/2 for you! - HTTP/2 was enabled by default in go 1.6, however HTTP/2 mandates the support of the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. As this is a 128bit cipher, it needs to be removed. The only way to achieve a perfect score now is to disable HTTP/2. Why does it have to be this way?

Spooky23 10y ago
128bit or the requirement to exceed it for an A+? There's no reason that 128 but cannot be used today, particularly for transport encryption.
darkhorn 10y ago
Because it was developed for Google and they what they care is speed not security or client side certificates.
- FiloSottile 10y ago
  This is so outlandish that I'd love to be able to dismiss you as a troll, but it's also so wrong it makes me angry, so I want to make sure no one nods reading your comment. 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.
FiloSottile 10y ago
I think something to understand here is that SSL Labs wants you to aim for A+, not for 100%. The numeric score is probably just to visualize what areas need improvement, and obviously 256 scores more than 128, but that's not an indictment of 128. 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.
- MrPeterLambert 10y ago
  Author here. This is exactly right. 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.
- ivanr 10y ago
  That's absolutely correct; the goal should be to get an A+. (SSL Labs author.)
davidben 10y ago
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/5BmCy4Gx3gs/1FiAx2YpGgAJ https://groups.google.com/a/chromium.org/d/msg/security-dev/...
- blowski 10y ago
  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 10y ago
    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-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...
    - blowski 10y ago
      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 10y ago
        Because what is implied by those terms changes over time, and minor changes can have major impacts on accessibility by older clients.

by dorianm 10y ago

Spooky23 10y ago

128bit or the requirement to exceed it for an A+? There's no reason that 128 but cannot be used today, particularly for transport encryption.

darkhorn 10y ago

Because it was developed for Google and they what they care is speed not security or client side certificates.

FiloSottile 10y ago
This is so outlandish that I'd love to be able to dismiss you as a troll, but it's also so wrong it makes me angry, so I want to make sure no one nods reading your comment. 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.

FiloSottile 10y ago

I think something to understand here is that SSL Labs wants you to aim for A+, not for 100%. The numeric score is probably just to visualize what areas need improvement, and obviously 256 scores more than 128, but that's not an indictment of 128. 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.

MrPeterLambert 10y ago
Author here. This is exactly right. 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.
ivanr 10y ago
That's absolutely correct; the goal should be to get an A+. (SSL Labs author.)

davidben 10y ago

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/5BmCy4Gx3gs/1FiAx2YpGgAJ https://groups.google.com/a/chromium.org/d/msg/security-dev/...

blowski 10y ago
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 10y ago
  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-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat...
  - blowski 10y ago
    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 10y ago
      Because what is implied by those terms changes over time, and minor changes can have major impacts on accessibility by older clients.