3 ms·

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

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 10y ago
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.
- meddlepal 10y ago
  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.
  - tptacek 10y ago
    It'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 ago
  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-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...
  - tptacek 10y ago
    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 10y ago
      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.
saturncoleus 10y ago
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.

tptacek 10y ago

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.

meddlepal 10y ago
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.
- tptacek 10y ago
  It'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 ago
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-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...
- tptacek 10y ago
  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 10y ago
    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.

saturncoleus 10y ago

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.