4 ms·

Go implements their own RSA crypto and related algorithms? I would have expected them to learn from Javas mistakes and use something that has a hope of being m

Go implements their own RSA crypto and related algorithms? I would have expected them to learn from Javas mistakes and use something that has a hope of being maintained indefinitely and isn't coupled to something like language version. JSSE (TLS implementation in Java) is so broken and behind Tomcat ships with some marshal interface to OpenSSL, but that takes considerable effort and software converges to language defaults.

Dobbs 11y ago
Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.
- revelation 11y ago
  That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.
  - f2f 11y ago
    you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
    - deleted 11y ago
      [deleted]
    - revelation 11y ago
      The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.
      - f2f 11y ago
        > What crypto libraries need is usage openssl is by far the most widely used tls library out there. still, occasionally our collective hearts bleed. what's even worse is you get forks of openssl for each vendor that wants to abide by this government's policy or that. in effect, you have a single bad codebase multiplied n-fold. where's the economy of scale there? if you're arguing that "with many eyes all bugs are shallow", this has been disproven. if you're arguing that java's tls implementers were crap, well, that's fine. doesn't mean go's are.
      - nindalf 11y ago
        Interesting that you mention heartbleed while also claiming that Go implementing its own TLS library was a bad move. fyi, the popular Heartbleed test used a modified Go TLS stack - [1]. Clearly having an alternate implementation that was easy to work with was a win here. https://filippo.io/Heartbleed/ https://filippo.io/Heartbleed/
tptacek 11y ago
Go has one of the best TLS implementations available in any language. Adam Langley at Google oversees it. I think it's more trustworthy than OpenSSL's. The specific type of cryptographic flaw that occurred here is common to virtually all crypto libraries. As I said upthread: even Nacl got bit by carry propagation. Using OpenSSL wouldn't have protected Go from these kinds of flaws; OpenSSL has had several carry bugs.
- hueving 11y ago
  >has had several carry bugs. I'm not sure I understand how Go's implementation is so much better when your justification is that they are making the same mistakes other libraries already have. The bar should be higher for new software, not the same.
  - tptacek 11y ago
    Obviously it isn't my argument that Go's TLS is good because it had a carry propagation bug.
- echlebek 11y ago
  I've had a lot of pushback from our operations team about the Go TLS stack, which they consider to be less secure and less vetted than OpenSSL. They (rightly) point to this message from Andrew Gerrand in 2013: https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/oBLikl38BYUJ https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/oBLi... Do you know if this is still true? Or does it even matter, if OpenSSL is the only other contender for TLS? As someone who has no expertise in crypto, it's hard to make sound judgments.
  - rsc 11y ago
    Andrew wrote: > It's really up to the provider of the service in question to make the call. All we can say about crypto/tls is that it hasn't been thoroughly reviewed from a cryptographic standpoint. Whether that suits your use case or not is very much up to you. That is still true. Of course, the implementation has been reviewed and beat on in production use more now than it had been in 2013, but the fact remains that there has been no systematic, independent outside audit focused specifically on cryptography. On the other hand, the cascade of "interesting" bugs since 2013 like Goto Fail and Heartbleed suggests that maybe the other implementations are not quite as audited as one might have expected. As tptacek mentioned in another comment, Adam Langley is the primary author and maintainer for Go's crypto packages. He's also one of the key people involved in Chrome's TLS implementation and Google's use of TLS more broadly, and he's a significant committer to OpenSSL and the creator and maintainer of BoringSSL. You can learn more about his work at his blog, imperialviolet.org. Having Adam involved with Go's crypto/tls raises my comfort level considerably. It's not Joe Random (or Jane Random) working on the crypto code, as others suggested below. Even so, even experts make mistakes and it would be nice to get a second expert to go through it looking for problems. For the most part Google does not use Go's crypto/tls for user-facing traffic. That is primarily a detail of Google's pre-existing serving architecture (we use separate servers to do that, much like putting nginx in front of your main server, and many engineering years of work went into those servers before Go even started). Because of that, Google has not really evaluated Go's crypto/tls one way or the other for that use. I believe we do run Go's crypto/tls to serve HTTPS on godoc.org, although I'd have to double-check. I certainly run it on swtch.com, rsc.io, and so on, not that there are real secrets in any of those servers. I suspect the largest production user of Go's crypto/tls is CloudFlare. Maybe someone from there can say something about their comfort level or exposure. Like Andrew said, it's really up to the provider of the service to make the call. You can have the same bugs as everyone else, or you can have a different set of bugs.

Dobbs 11y ago

Go makes it easy to build an all in one statically compiled binary with no external dependencies. No glibc, etc. It makes it really easy to build software and distribute it to your server farms.

revelation 11y ago
That's a sweet bullet point on page 3. I don't see what that has to do with security of rolling your own crypto and coupling it with the whole distribution. If you want, you can link OpenSSL statically. It's about as recommended as statically linking the entire universe into a binary.
- f2f 11y ago
  you need as many functional implementations of TLS as you can get. written by people with pedigree. you need them to cross-polinate and find bugs in each other. Go's TLS stack for example is used to test the TLS implementation is BoringSSL: https://www.imperialviolet.org/2015/10/17/boringssl.html https://www.imperialviolet.org/2015/10/17/boringssl.html Go's crypto wasn't rolled out by amateurs.
  - deleted 11y ago
    [deleted]
  - revelation 11y ago
    The evidence points elsewhere. TLS is such a complex protocol that any new library will make fundamental errors in implementing it and the requisite crypto primitives (of which there are many). What crypto libraries need is usage and, this usually goes with it, attention from people looking to break them. There are plenty of TLS libraries out there like mbedTLS and the mentioned JSEE, and looking at CVE reports a few years ago you would think these are the most secure libraries in the entire world compared to the constant trickle of issues in OpenSSL. Except when heartbleed got attention and people started looking at these rarely used alternatives they found massive problems. For years, the protocol FSM in JSEE was fatally broken. MbedTLS had and continues to have issues with just basic things like buffer overflows. And often these libraries just plain lack features and timely updates.
    - f2f 11y ago
      > What crypto libraries need is usage openssl is by far the most widely used tls library out there. still, occasionally our collective hearts bleed. what's even worse is you get forks of openssl for each vendor that wants to abide by this government's policy or that. in effect, you have a single bad codebase multiplied n-fold. where's the economy of scale there? if you're arguing that "with many eyes all bugs are shallow", this has been disproven. if you're arguing that java's tls implementers were crap, well, that's fine. doesn't mean go's are.
    - nindalf 11y ago
      Interesting that you mention heartbleed while also claiming that Go implementing its own TLS library was a bad move. fyi, the popular Heartbleed test used a modified Go TLS stack - [1]. Clearly having an alternate implementation that was easy to work with was a win here. https://filippo.io/Heartbleed/ https://filippo.io/Heartbleed/

tptacek 11y ago

Go has one of the best TLS implementations available in any language. Adam Langley at Google oversees it. I think it's more trustworthy than OpenSSL's. The specific type of cryptographic flaw that occurred here is common to virtually all crypto libraries. As I said upthread: even Nacl got bit by carry propagation. Using OpenSSL wouldn't have protected Go from these kinds of flaws; OpenSSL has had several carry bugs.

hueving 11y ago
>has had several carry bugs. I'm not sure I understand how Go's implementation is so much better when your justification is that they are making the same mistakes other libraries already have. The bar should be higher for new software, not the same.
- tptacek 11y ago
  Obviously it isn't my argument that Go's TLS is good because it had a carry propagation bug.
echlebek 11y ago
I've had a lot of pushback from our operations team about the Go TLS stack, which they consider to be less secure and less vetted than OpenSSL. They (rightly) point to this message from Andrew Gerrand in 2013: https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/oBLikl38BYUJ https://groups.google.com/d/msg/golang-nuts/LjhVww0TQi4/oBLi... Do you know if this is still true? Or does it even matter, if OpenSSL is the only other contender for TLS? As someone who has no expertise in crypto, it's hard to make sound judgments.
- rsc 11y ago
  Andrew wrote: > It's really up to the provider of the service in question to make the call. All we can say about crypto/tls is that it hasn't been thoroughly reviewed from a cryptographic standpoint. Whether that suits your use case or not is very much up to you. That is still true. Of course, the implementation has been reviewed and beat on in production use more now than it had been in 2013, but the fact remains that there has been no systematic, independent outside audit focused specifically on cryptography. On the other hand, the cascade of "interesting" bugs since 2013 like Goto Fail and Heartbleed suggests that maybe the other implementations are not quite as audited as one might have expected. As tptacek mentioned in another comment, Adam Langley is the primary author and maintainer for Go's crypto packages. He's also one of the key people involved in Chrome's TLS implementation and Google's use of TLS more broadly, and he's a significant committer to OpenSSL and the creator and maintainer of BoringSSL. You can learn more about his work at his blog, imperialviolet.org. Having Adam involved with Go's crypto/tls raises my comfort level considerably. It's not Joe Random (or Jane Random) working on the crypto code, as others suggested below. Even so, even experts make mistakes and it would be nice to get a second expert to go through it looking for problems. For the most part Google does not use Go's crypto/tls for user-facing traffic. That is primarily a detail of Google's pre-existing serving architecture (we use separate servers to do that, much like putting nginx in front of your main server, and many engineering years of work went into those servers before Go even started). Because of that, Google has not really evaluated Go's crypto/tls one way or the other for that use. I believe we do run Go's crypto/tls to serve HTTPS on godoc.org, although I'd have to double-check. I certainly run it on swtch.com, rsc.io, and so on, not that there are real secrets in any of those servers. I suspect the largest production user of Go's crypto/tls is CloudFlare. Maybe someone from there can say something about their comfort level or exposure. Like Andrew said, it's really up to the provider of the service to make the call. You can have the same bugs as everyone else, or you can have a different set of bugs.