
Achieving a Perfect SSL Labs Score with Go - 0xmohit
https://blog.bracelab.com/achieving-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.

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

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

~~~
rgbrenner
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](http://www.isg.rhul.ac.uk/tls/TLStiming.pdf)

------
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...](https://www.schneier.com/blog/archives/2009/07/another_new_aes.html)

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

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

~~~
hodgesrm
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...](http://thenewstack.io/a-closer-look-at-golang-from-an-architects-
perspective/)

[2] [http://www.techworld.com/apps/why-googles-go-programming-
lan...](http://www.techworld.com/apps/why-googles-go-programming-language-
could-rival-java-in-enterprise-3626140/)

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

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

------
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](https://certsimple.com/blog/chrome-outdated-cryptography)

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

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

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

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

------
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...](https://www.ssllabs.com/ssltest/analyze.html?d=smcleod.net&s=104.28.27.110&latest)

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://wiki.mozilla.org/Security/Server_Side_TLS)

\- [https://mozilla.github.io/server-side-tls/ssl-config-
generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)

\-
[https://wiki.mozilla.org/Security/Guidelines/OpenSSH](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

~~~
jvehent
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...](https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall.info)

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

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

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

------
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...](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility)

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

