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

Achieving a Perfect SSL Labs Score with Go

blog.bracelab.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Achieving a Perfect SSL Labs Score with Go

#21

Post by jvehent »

pilif wrote: post #12
mrmondo wrote: post #9

It's really easy to get an A+ on SSL labs as long as you follow standard modern recommended settings for your certificates and web server (nginx generally being the easiest to set correctly), having said that I see my own crappy blog has dropped from an A+ to an A in the last couple of weeks: https://www.ssllabs.com/ssltest/analyze.html?d=smcleod.net&s... I highly recommend regularly reading Mozilla's various posts o…

The article goes beyond an A+ and also goes for 100% in all the ratings. The guides which you linked don't do that

Neither should they. Both guides haves different goals.

SSLLabs evaluates the highest possible security, while Mozilla's levels compromise to implement the best possible TLS for a given population of users. "best" isn't always determined by security: speed and compatibility are taken into account as well.

That said, Mozilla's modern level ranks A+ in SSLLabs: https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall...

Re: Achieving a Perfect SSL Labs Score with Go

#22

Post by FiloSottile »

darkhorn wrote: post #17
dorianm wrote: post #7

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

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

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.

Re: Achieving a Perfect SSL Labs Score with Go

#23

Post by danieltillett »

Panino wrote: post #19
danieltillett wrote: post #10

Earlier quoted context omitted.

Exactly. Perfection means you exclude a large percentage of users who are not using a modern browser or who have older handsets. If you running a hobby site then it is fine, but if it is a business this sort of behaviour is insane.

(Note: I do support AES-128-GCM, and don't recommend doing what the author of this article did.) That said: According to my webserver logs, I see I encourage everyone to measure their traffic, and take some time to consider how important their TLS 1.0 and 1.1 users are. If you're a business, what percentage of sales are from TLS 1.0/1.1 clients? What's the ratio of good:bad traffic? And the same questions for 1.2. Me…

It really depends on your market. I see around 20% of my traffic coming from below 1.2. Measure twice and cut once.

Re: Achieving a Perfect SSL Labs Score with Go

#24

Post by MrPeterLambert »

FiloSottile wrote: post #20
dorianm wrote: post #7

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

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 disreg…

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.

Re: Achieving a Perfect SSL Labs Score with Go

#25

Post by Spooky23 »

Panino wrote: post #19
danieltillett wrote: post #10

Earlier quoted context omitted.

Exactly. Perfection means you exclude a large percentage of users who are not using a modern browser or who have older handsets. If you running a hobby site then it is fine, but if it is a business this sort of behaviour is insane.

(Note: I do support AES-128-GCM, and don't recommend doing what the author of this article did.) That said: According to my webserver logs, I see I encourage everyone to measure their traffic, and take some time to consider how important their TLS 1.0 and 1.1 users are. If you're a business, what percentage of sales are from TLS 1.0/1.1 clients? What's the ratio of good:bad traffic? And the same questions for 1.2. Me…

Many institutional and enterprise shops using Windows 7 won't use TLS 1.2, either due to poor configuration management practices or confusion with regard to how to handle the 3-ring circus that is IE.

Re: Achieving a Perfect SSL Labs Score with Go

#27

Post by sethammons »

karim wrote: post #26

I'm not a golang developer --- is it common in Go deployments to run your service without a reverse proxy in front of it? Do people implement rate-limiting on their own?

We typically sit behind a reverse proxy. That said, we do have apps that control their own rate-limiting too. They usually do so because some logic is needed.

Re: Achieving a Perfect SSL Labs Score with Go

#28

Post by ivanr »

FiloSottile wrote: post #20
dorianm wrote: post #7

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

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 disreg…

That's absolutely correct; the goal should be to get an A+. (SSL Labs author.)

Re: Achieving a Perfect SSL Labs Score with Go

#29

Post by davidben »

dorianm wrote: post #7

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

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

Re: Achieving a Perfect SSL Labs Score with Go

#30

Post by blowski »

davidben wrote: post #29
dorianm wrote: post #7

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

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…

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".
Post reply on HN