Comparison of SSL Labs TLS Scores with Different Go Versions | Hacker News Reader

Comparison of SSL Labs TLS Scores with Different Go Versions

aoeus.com

89 pointspythonist27 comments

I'd observe that this is testing the default TLS configuration when you ask net/http to "Just TLS that connection for me, will you?" with no further details. I imagine almost any version could get to A- if you configured it (PFS seems like it may have been a feature that had to be added), and per selectnull's point about Strict Transport Security, you probably should not output that header by default so an A+ with a default configuration would arguably actually be a bad thing.

I certainly do not mean this is an unfair question to ask; quite the contrary! (It has been said "defaults matter", but I'm really coming around to the idea that even that understates the truth. Options almost don't matter. They do. But just barely.) More people should ask this of more code. I just want to make sure non-Go programmers understand what is being said here, that this is the default, not the top capability of the built-in Go TLS stack of those versions.

An HSTS default would probably be a good thing, but HSTS is hard to undo, because it's cached in browsers. We'd all be better off if net/http served HSTS by default, but individual users of the library might not be.

Half in my spare time, half at work I'm working on a Go web framework that tries to turn the web "default deny", and to do so with good API design that makes the default safe (so, it's a lot harder than just "write a middleware that slaps some headers on top"). I'm willing to be a bit of a jerk about cookies (if you want the client to be able to read it, say so, etc.), I'm willing to make you say "Look, just turn off CSP" if that's how you're going to roll... but even as much of a jerk as I'm being, I'm shying away from defaulting HSTS to on. I'm currently thinking of making it simply not defaulted; take a stand one way or the other, but just defaulting it to on is a bit scary.

If I was building a framework, I'd probably force users to select an option, rather than providing a silent default either way.

The right option name for this is probably "Protect against HTTPS-stripping".

Thank you for your confirmation, I will do that then.

Not sure when or frankly even if it will go public, but I hope it will. Still have a lot of work to do on it before it's worth anything.

Edit: Also, thank you for the name suggestion. One of the other things I've noticed is that a lot of web security is... well... let's say, named in a way that does not always make it clear exactly what it means. I'm trying to make this stuff more clear in the naming too.

It's also the grade that 1.4.3 got recently, not when it came out. I wonder if Ivan Ristic could go back in time to the test code then and see what grade it would get.

For those who might not be aware, the highest SSL Labs grade is not A, but A+.

To score A+ you must score A and additionally set HSTS headers with long duration (I use 2 years, haven't tried with less). For example, with Nginx you use something like:

    add_header Strict-Transport-Security "max-age=63113904;";

Right, and you can (and should) do this easily in Go, but it isn't a safe default.

If you use Hiawatha you get A+ with out of the box settings.

Just plugging it because it constantly outperforms my expectations and PolarSSL (now mbed owned by Arm), has avoided many of the recent openssl issues making my life less worrisome, but the dev doesn't really advertise or push it and relies on word of mouth more than anything.

It's worth checking out.

https://www.hiawatha-webserver.org

Zero is the number of TLS experts I know that would unreservedly recommend PolarSSL over Go's crypto/tls. I know several who wouldn't even recommend it over OpenSSL, but it's worth remembering that not only does Go's TLS not use OpenSSL, but it's curated by one of the world's experts in TLS security.

Go has one of the best TLS stacks in the world, and I expect the distinction to become starker in the future; in a few years, barring something unexpected from something like BoringSSL, it may end up being unquestioned best TLS stack.

> Go has one of the best TLS stacks in the world,

Go suffers a bit from weak random numbers though (crypto/rand Read() output), says dieharder at least: http://nopaste.narf.at/show/31060/

I'm not sure how severe that is...

Horseshit. Go's crypto reads from urandom, just like Nacl.

Thanks for the info tptacek, do you have any reading along these lines that goes into any detail on this? From what I have been reading go tls is nice but computationally more intensive. I really like to go for the best wherever I can, so I am genuinely interested if anyone else has any input on this.

Go has one of the best TLS stacks in the world

Do you have any proof to support this claim?

> If you use Hiawatha you get A+ with out of the box settings.

Which means they set long HSTS by default, which will bite you quite badly if you're not ready yet for an irreversible HTTPS rollout. But yeah, A+ looks awesome on comparison tables, doesn't it?

No, it does not set a HSTS header by default. And the out of the box rating is A, not A+. However, with a simple setting you enable the HSTS header, which gives you the A+ rating.

The dev has tried to push it, but it seemed that nobody cares.

See https://www.hiawatha-webserver.org/forum/topic/2063/#10728

It's amazing how much this line of code actually makes happen;

  http.ListenAndServeTLS(":443", "cert.pem", "key.pem", nil))

A full HTTP and TLS stack ready to start dispatching requests to your callbacks. I know there are other languages that can do the same, but I still think it's impressive. I've written just a few thousand lines of Go and while I'm pretty sure I'm not really "doing it right" I was able to port some decent complexity C# and very easily had all cores processing data at a higher overall rate with the Go code. High level libraries like this, and managed memory makes it almost feel like a scripting language, but with all the advantages of a compiler.

Operational question... If you're terminating client-side TLS like this, then does that mean either it's a single server or you have L4 (or lower) load balancing in front of it? I assume it's more common to have haproxy or nginx or something like that in front terminating TLS, with the API servers sitting behind.

In addition to SSL Labs, I also find this useful for things that are not exposed to the internet. (firewalled)

[1] https://github.com/drwetter/testssl.sh

It only depends on OpenSSL and bash. I find it very useful for reviewing our systems before they go live.

Thanks, you read my mind! :)

Hmm what is HSTS preloading.

I have to catchup on the latest TLS stuff every few months.

So what is the default preferred cipher suite string for Go 1.6 ? I worked out my own a couple years ago and it still gets an A rating on SSL Labs

https://tip.golang.org/src/crypto/tls/cipher_suites.go#L75

I wonder what the results would be for 1.5.2 (the version which had the bug in key generation). Has anyone check this? If not, I'll do it when I have time later today.

It will be exactly the same as 1.5.3 normally since no feature are added in those releases. The key generation problem had no visible impact on the tls negociation, it simply resolved a flaw in the key generation process.

Heh. Looks like the cipher suite options are outdated for this site (so it probably wouldn't pass an SSLabs test).

The HTTPS connection of the website (aoeus.com) uses SHA-1.

Link to result https://www.ssllabs.com/ssltest/analyze.html?d=aoeus.com

Reply on news.ycombinator.com