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

31–40 of 51 posts

Re: Achieving a Perfect SSL Labs Score with Go

#31

Post by jlgaddis »

blowski wrote: post #30
davidben wrote: post #29

Earlier quoted context omitted.

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

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

Re: Achieving a Perfect SSL Labs Score with Go

#32

Post by blowski »

jlgaddis wrote: post #31
blowski wrote: post #30

Earlier quoted context omitted.

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?

Re: Achieving a Perfect SSL Labs Score with Go

#33

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

Re: Achieving a Perfect SSL Labs Score with Go

#34

Post by tptacek »

hodgesrm wrote: post #33

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

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.

Re: Achieving a Perfect SSL Labs Score with Go

#35

Post by tptacek »

rgbrenner wrote: post #5
vbernat wrote: post #3

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.

Re: Achieving a Perfect SSL Labs Score with Go

#36

Post by rgbrenner »

hannob wrote: post #14
rgbrenner wrote: post #6

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) bu…

>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

Re: Achieving a Perfect SSL Labs Score with Go

#37

Post by mioelnir »

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?

The bigger problem is that in go you can not do privilege revocation. And although unprivileged binding So they go for a reverse proxy, more often than not, just to get the 80/443 binding.

Re: Achieving a Perfect SSL Labs Score with Go

#38

Post by rgbrenner »

tptacek wrote: post #35
rgbrenner wrote: post #5

Earlier quoted context omitted.

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.

Re: Achieving a Perfect SSL Labs Score with Go

#39

Post by saturncoleus »

hodgesrm wrote: post #33

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

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.

Re: Achieving a Perfect SSL Labs Score with Go

#40

Post by meddlepal »

tptacek wrote: post #34
hodgesrm wrote: post #33

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

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