41–50 of 51 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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.
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...
[2] http://www.techworld.com/apps/why-googles-go-programming-lan...
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.
> 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?
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…
When I ran the code, the Go HTTP/2 package caused a panic with the message "http2: TLSConfig.CipherSuites is missing HTTP/2-required TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256".
I went source diving and found the following:
https://golang.org/src/net/http/h2_bundle.go?h=TLS_ECDHE_RSA...
It even has the helpful comment:
> If they already provided a CipherSuite list, return an error if it has a bad order or is missing ECDHE_RSA_WITH_AES_128_GCM_SHA256.
I cannot see how I would have achieved my aim without disabling HTTP/2.
The aim of the exercise was to get a perfect score using Go. I wasn't discussing HTTP/2 in general. I was referencing the Go standard library implementation.
As I say, if you still think it's not right, please let me know.
Earlier quoted context omitted.
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.
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 securit…
Earlier quoted context omitted.
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?
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…
Can you explain how it isn't quite right? I would like to correct the article if this is the case. When I ran the code, the Go HTTP/2 package caused a panic with the message "http2: TLSConfig.CipherSuites is missing HTTP/2-required TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256". I went source diving and found the following: https://golang.org/src/net/http/h2_bundle.go?h=TLS_ECDHE_RSA... It even has the helpful comment: > If…
That is to say, you're correct that server configured for a 100% on SSLLabs will not support HTTP/2, but I agree with davidben that SSLLabs is incorrect here for incetivising AES-256, particularly in CBC mode, for the 100% score.
Earlier quoted context omitted.
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 securit…
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.
But maybe I'm missing your point.