Achieving a Perfect SSL Labs Score with Go

[dorianm]

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

[FiloSottile]

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.

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

[Spooky23]

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]

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

[rgbrenner]

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.

[hannob]

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

[danieltillett]

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.

[darkhorn]

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

[saturncoleus]

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

[xorcist]

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

[bpineau]

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

[hodgesrm]

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.

[saturncoleus]

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.

[tptacek]

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.

[vbernat]

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

[rgbrenner]

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

[mrmondo]

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

[pilif]

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

[karim]

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?

[mioelnir]

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.

[sethammons]

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.

[alexchamberlain]

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

[jvehent]

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

[kinai]

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