Why did Go implement its own SSL library?

[jto...@gmail.com]

Hey all,

I've scanned the list and the website and I might have missed a design doc somewhere, but as far as I can tell I can't find any motivational reason for why Go implemented its own SSL library.

Ordinarily, if the author of Go's SSL library wasn't someone of AGL's caliber, I would have written off another implementation of SSL as just plain crazy. It's hard to get crypto right, and OpenSSL or GnuTLS have been tested and hardened, hopefully with most bugs worked out. However, since AGL is also a contributor to OpenSSL directly, I can't help but wonder why Go decided to re-invent the wheel here.

The only two things I can think of as possible pros are that perhaps the Go authors wanted the Go standard library to be all written in Go, or that maybe an existing library was hard to get to work with the event loop? The first argument is poor since there's already a lot of native code that's not Go in the standard library and OpenSSL is super portable. I can't really say much toward the second argument. Even more speculative and crazy (and something I wouldn't have considered at all until Snowden) is that maybe Google knows something we don't about the OpenSSL codebase but isn't allowed to say? Nah.

On the flip side, Go's reimplementation has caused some serious headaches (https://code.google.com/p/go/issues/detail?id=5987 is one example, I can't find the other ticket I have in mind at the moment, something about what certificates in the chain Go chooses to present to the peer), raises security questions (yet another codebase to vet and verify), and perhaps most selfishly, none of my OpenSSL hardware acceleration modules work with Go at all (cryptodev or AF_ALG support plz?).

I've had a few people show serious surprise and concern when I mention Go uses its own crypto library.

So, yeah, given all that, having not seen any discussion of this before, why? I assume there's good reasons.

-JT

[Rob Pike]

We have someone of AGL's calibre, he wanted to do it, and it's nice to have it all in Go. If crypto is so hard that only one implementation is allowed to exist, it's crypto that needs to be rethought, not Go's library. Moreover, Go is safer and cleaner and I would argue therefore a safer language for writing crypto code than C or C++. The problems you list are due more to the youth of the library rather than to it being infeasible.

But actually: When the SSL work was undertaken, there was no cgo, so doing it in Go was the only option.

-rob

[Rodrigo Kochenburger]

Also, I think it's good to have the option to not dynamic link to a 3rd party library. You can always use CGO to wrap/use OpenSSL yourself if you want too.

- RK

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[agl]

On Wednesday, October 9, 2013 9:39:36 AM UTC-4, jto...@gmail.com wrote:

Ordinarily, if the author of Go's SSL library wasn't someone of AGL's caliber, I would have written off another implementation of SSL as just plain crazy. It's hard to get crypto right, and OpenSSL or GnuTLS have been tested and hardened, hopefully with most bugs worked out. However, since AGL is also a contributor to OpenSSL directly, I can't help but wonder why Go decided to re-invent the wheel here.

Have you seen the OpenSSL code? I do, indeed, work with it a lot and it doesn't exactly fill one with positive feelings. NSS has a different set of issues. (I'm not familiar with alternatives like Polar or GnuTLS.)

The crypto/tls package doesn't solve every use case, but you're not forced to use it. Since you need client auth without KeyUsage + hardware accel then it is perfectly reasonable to wrap OpenSSL.

Cheers

AGL 

[brainman]

The lib "just works" on windows. There are no special requirements, like "install this compiler and extra libs, make sure they are in the path and ... and ... and ...". It just another package like strconv for example.

Alex

[Carlos Castillo]

Aside from the reasons listed above, I like the fact that there are computationally complex libraries built in Go that are part of the std library, that way there is always an impetus to improve the quality of the code produced by the compiler, and a decent real-life benchmark to measure any performance improvements against.