9 ms·
Achieving a Perfect SSL Labs Score with Go
- saturncoleus 10y ago> 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.
- bpineau 10y agoRight, and they had to salvage HTTP/2 support (which mandates 128 bit AES) in the process.
- xorcist 10y agoIt 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_aes.html https://www.schneier.com/blog/archives/2009/07/another_new_a...
- vbernat 10y agoThe driven-by-score configuration keeps a AES256-CBC-SHA cipher but discards a AES128-GCM-SHA2 cipher which is more robust.
- rgbrenner 10y agoIn 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 10y agoYou 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 10y agoThis 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.
- danieltillett 10y agoExactly. 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.
- Panino 10y ago(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!
- danieltillett 10y agoIt really depends on your market. I see around 20% of my traffic coming from below 1.2. Measure twice and cut once.
- Spooky23 10y agoMany 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.
- dorianm 10y ago> 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?
- Spooky23 10y ago128bit 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 10y agoBecause it was developed for Google and they what they care is speed not security or client side certificates.
- FiloSottile 10y agoThis 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.
- FiloSottile 10y agoI 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.
- kinai 10y agoto 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
- mrmondo 10y agoIt'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=104.28.27.110&latest 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://wiki.mozilla.org/Security/Server_Side_TLS - https://mozilla.github.io/server-side-tls/ssl-config-generator/ https://mozilla.github.io/server-side-tls/ssl-config-generat... - https://wiki.mozilla.org/Security/Guidelines/OpenSSH https://wiki.mozilla.org/Security/Guidelines/OpenSSH
- pilif 10y agoThe article goes beyond an A+ and also goes for 100% in all the ratings. The guides which you linked don't do that
- jvehent 10y agoNeither 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.info https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall...
- alexchamberlain 10y agoGiven all the comments indicate that AES 128 is considered secure, do SSL Labs need to change their scoring algo for the cipher suite?
- jvehent 10y agoWe 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_compatibility https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_com...
- karim 10y agoI'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?
- sethammons 10y agoWe 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.
- mioelnir 10y agoThe 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 10y agoIs setcap(8) the informed thing to be using on Linux?
- mioelnir 10y agoYes, 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.
- hodgesrm 10y agoGo 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 10y agoGo'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.
- meddlepal 10y agoIn 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.
- tptacek 10y agoIt'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.
- hodgesrm 10y agoPerhaps 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-architects-perspective/ http://thenewstack.io/a-closer-look-at-golang-from-an-archit... [2] http://www.techworld.com/apps/why-googles-go-programming-language-could-rival-java-in-enterprise-3626140/ http://www.techworld.com/apps/why-googles-go-programming-lan...