Achieving a Perfect SSL Labs Score with Go | Hacker News Reader

Achieving a Perfect SSL Labs Score with Go

blog.bracelab.com

98 points0xmohit50 comments

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

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.

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.

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.

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.

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

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

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.

This is an interesting example of how to get a perfect score on the ssl test.. but it's a terrible config for a production web server.

It only works with the following clients without an error.. since this is when these browsers added TLS 1.2 support (and this config requires tls 1.2):

  Android 5+
  Firefox 27+
  IE 11, Edge
  Opera 17+
  Safari 7+

It might work on some versions of Chrome after v30 (when tls 1.2 was added) but before they added the obsolete crypto warning (that this config triggers).

It pointlessly excludes clients since TLS 1.0, 1.1 and AES 128 are still considered secure.

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 <5% of traffic being TLS 1.0/1.1, so going TLS 1.2 only wouldn't (in my case) exclude many people. By recently blocking only 3 IP addresses (unfriendly bots), I calculate an expected reduction in TLS 1.1 usage of about 85%. So now I expect TLS 1.1 usage to plunge from about 1% to ... less than 1%.

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

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

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.

>It pointlessly excludes clients since TLS 1.0, 1.1 and AES >128 are still considered secure.

Wrong. All AES-based ciphers in TLS 1.0/1.1 are vulnerable to the Lucky Thirteen attack. This can be avoided by careful implementation, however as far as I know the go developers don't even try to do that and say if you want something secure use gcm.

Wrong.

1. TLS 1.2 is also vulnerable to the lucky thirteen attack.

2. The lucky thirteen attack requires CBC-mode.. which is also what generates the obsolete crypto warning in chrome.

The solution here is clearly to disable CBC-mode.

http://www.isg.rhul.ac.uk/tls/TLStiming.pdf

I use this future so that email agregators (bots) cannot reach my web site. So far 0 spam :D

> This means I need to take the default CipherSuites and simply remove any that use a cipher smaller than 256bit.

Arguably using a higher bit cipher suite should be considered worse, since it reduces accessibility. 128 bit crypto (specifically the GCM suites) are ridiculously faster, to the point where it is practically free to enable it for all websites. Treating 256bit crypto as better feels like it is missing a key point of security: availability.

Right, and they had to salvage HTTP/2 support (which mandates 128 bit AES) in the process.

It is not at all obvious which of AES-128 and AES-256 is more secure.

See for example this 2009 paper: https://www.schneier.com/blog/archives/2009/07/another_new_a...

Go encryption support looks really elegant.

Ironically just before reading this article I was reviewing a Java code change to force TLS 1.1+. The logic to set security protocols and ciphers correctly is quite tangled in part because it's not consistent across different libraries e.g., for JMX and SSL sockets. I still can't tell if the code I was reviewing will work in production.

Has anyone posted a general comparison of Java vs. Go on security? This deserves a closer look.

Go's TLS and crypto is across the board better than Java's. I wouldn't choose a language based on its TLS stack, but if you were in a weird position where you had to do that, you'd pick Go.

It's not a fair comparison: Go has a TLS stack that is shepherded by Adam Langley, who is one of the Internet's foremost experts on TLS.

In Java's defense its TLS stack and frameworks using it have grown organically over 20 years. Let's see how Go is doing with consistency in 2030.

It's not time that makes Java's TLS stack bad; it's that the TLS stacks are afterthoughts. Java could be competitive with Go if it attracted someone of Langley's caliber to manage a coherent, designed-for-security TLS stack, and then the ecosystem was managed to ensure that everyone used that stack.

Perhaps not but it is astonishing to me that many (most?) of the comparisons between Go and Java omit security. In particular, it's hard see how you can assert Go (or any language for that matter) is well-suited for distributed computing without considering issues like authentication and encryption.

Here are a couple of examples of what I mean. [2] cites use of Go in financial apps without a single mention of security.

[1] http://thenewstack.io/a-closer-look-at-golang-from-an-archit...

[2] http://www.techworld.com/apps/why-googles-go-programming-lan...

I don't understand this argument. I'm a security practitioner and, in particular, a software security expert. I don't think either language is intrinsically more or less secure. But Go does have a better TLS stack.

Building secure systems in Java requires a lot of arcane knowledge due to the complexity of the libraries. For instance, you can't just throw a switch and convert all socket-based communication to TLS. I'm not arguing that Go is necessarily better but it's a useful consideration in language evaluation.

But maybe I'm missing your point.

Java's SSL is very painful to deal with. It has no support for ALPN or NPN, making it really difficult to use for HTTP/2. Also, the GCM cipher suites are implemented in Java, not with Intrinsics, so they are painfully slow. As in 20MB/s. Openssl and Go's TLS get 3000MB/s for the same amount of CPU.

Worst of all, Oracle refuses to propagate patches backwards, so if you are running even a mildly old (like a year) JDK, you will suffer for it. Enterprise Java doesn't move that fast, so you end up having bootclass hacks to get around these shortcomings.

And oh yeah, if you also support Android, you might as well hire someone full time to deal with this, since it is that time consuming to deal with.

The driven-by-score configuration keeps a AES256-CBC-SHA cipher but discards a AES128-GCM-SHA2 cipher which is more robust.

In fact, using AES256-CBC-SHA will cause Chrome to mark the https with a red strikeout (in the location bar).. because its 'outdated' cryptogrpahy. See: https://certsimple.com/blog/chrome-outdated-cryptography

You should lose the scare quotes, as SHA1 is approximately as secure relative to hash functions as RSA-1024 is to public key algorithms: that is, not very.

fair... but it's actually the CBC suite that generates the warning.

All the CBC suites in TLS are vulnerable to Lucky 13.

Exactly. So why not call it insecure.. Instead it's just "outdated". Hence the quotes

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 on recommended security settings, especially the TLS best practises for web servers and OpenSSH.

- https://wiki.mozilla.org/Security/Server_Side_TLS

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

- https://wiki.mozilla.org/Security/Guidelines/OpenSSH

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

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.

The bigger problem is that in go you can not do privilege revocation. And although unprivileged binding <=1023 has been a solved problem for well over a decade, most people still consider it a dark art.

So they go for a reverse proxy, more often than not, just to get the 80/443 binding.

Is setcap(8) the informed thing to be using on Linux?

Yes, and it works good with Go since you have static executables so you do not have to set the capability on an interpreter. But you have to reapply it after every upgrade, which is easy enough to automate. That said, I mostly use mac_portacl on FreeBSD.

Given all the comments indicate that AES 128 is considered secure, do SSL Labs need to change their scoring algo for the cipher suite?

We also recommend AES-256 being preferred to AES-128 in Mozilla's modern configuration. From the rationale section:

    AES256-GCM is prioritized above its 128 bits variant,
    and ChaCha20 because we assume that most modern devices 
    support AESNI instructions and thus benefit from fast 
    and constant time AES.

https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...

to extrapolate: if you disable webserver nobody can access it and hence no security risk at all wohooo

obviously refering to the point that all this tight security will result in lot of issues for most users

Reply on news.ycombinator.com