Go is production ready, but the crypto/tls package isn't?

[Luke Scott]

Many people have claimed that Go is being used in production and that it is production ready. According to a some comments in a few unresolved issues, the crypto/tls package is not production ready. Either this information is out of date, or this fact has not been made apparent (comment in the docs).

We've been integrating with some secure API's and one of them in particular requires client certificates and regeneration. I was quite shocked to find out that not only is this not supported, but there is no plans to support it (https://code.google.com/p/go/issues/detail?id=5742).

While digging further I came across this post (http://stackoverflow.com/questions/12642689/does-golang-tls-support-ie8). So users of IE8 cannot connect to a Go https server... great because IE8 is what we have to support at a minimum.

That SO post links to this issue (https://code.google.com/p/go/issues/detail?id=3930), which contains the following:

agl: 

This has previously been a good method for educating people not to use crypto/tls for serious things. Since the whole crypto stack, from ModExp upwards, is basically unreviewed, I want to encourage people to put Go behind OpenSSL or something similar once they get to the point of having client diversity like this.
So I would actually like to not support SSLv2 compat handshakes; not just because it highlights poor clients (OpenSSL fixed this behaviour quite a while ago), but because of that more subtle reason.

ian: 

The reason given for not merging my patch is that they don't consider the existing TLS code production ready, not because of any known defects, but because it hasn't received the kind of code review warranted for a cryptographic library.
A more interesting question (and perhaps a bug for this one to depend on) is what level of review WOULD be sufficient for this code to be considered production ready.  Identifying that as a need could be the start of a good project for someone, perhaps a summer of code project, or something that could be sponsored by one of the companies out there using Go in production. 

Is this out of date? If not, why has it not received enough attention? Are there any companies out there willing to sponsor it?

--

Luke

[Benjamin Measures]

On Tuesday, 24 September 2013 18:55:48 UTC+1, Luke Scott wrote:

Many people have claimed that Go is being used in production and that it is production ready.

Indeed it is used in production by quite a few companies: http://code.google.com/p/go-wiki/wiki/GoUsers

 

According to a some comments in a few unresolved issues, the crypto/tls package is not production ready.

Presumably you're talking about the following comment: 

agl: 

This has previously been a good method for educating people not to use crypto/tls for serious things. Since the whole crypto stack, from ModExp upwards, is basically unreviewed

I read that as being, "... from a cryptographical standpoint."

Cryptography is difficult to get right: subtle mistakes can blow things wide open. Take, for example, Debian's commenting of two lines from openssl in 2006: https://www.schneier.com/blog/archives/2008/05/random_number_b.html

That was used in production for two years, by a disto normally seen as *rock solid*.

IOW, you can use this code in production but you probably need to be informed (or "educated") that it hasn't been cryptographically reviewed. Don't use it for serious stuff, such as: criticising Iranian authorities (from within Iran); keeping trade secrets from China; or leaking NSA documents to the Guardian; and so on.

[Luke Scott]

What is and what isn't considered serious in production? What about financial information?

[Andrew Gerrand]

On 25 September 2013 09:10, Luke Scott <lu...@visionlaunchers.com> wrote:

What is and what isn't considered serious in production? What about financial information?

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.

Andrew 

[Nick Evgeniev]

Hi,

to me it's still a sandbox language (python replacement to some degree) because of:

1. there is no such thing as reproducible build (i.e. checkout tagged version of go project and build it against predefined versions of go packages (dependencies) instead go promotes you to use all the latest (and this is the LAST thing I want in prod)

2.  there is no versioned binary package distribution system in go (some view this as an advantage) only public repos

3. language is lacking some features (generics (yes there're ugly workarounds) & pls dont shoot me - exceptions, panic helps but it's typeless meaning you can't enforce anything on panic & compile time... endless if err != nil {} hurts as you can't see the code behind forest of ifs)

[Gerard]

Do you really want to start another flame thread? The issues 1 and 2 has been mentioned a lot of times. Take a look at Nathan Youngmans document.

IMO the reasons you mention doesn't qualify the discussion whether Go is a sandbox language or not. If you are facing package revision problems, just use git (or something like that) and use go get only for compiling and linking.

Issue 3, well it's probably Go 2, maybe earlier.

[Raul Mera]

There should be a filter for the list with keywords such as "generics" and "exceptions".

Also, as said in a Go talk, in production you MIGHT want to have your own clone of the repos for libraries you use.

On Wednesday, September 25, 2013 10:34:35 AM UTC+2, Nick Evgeniev wrote:

[Jakob Borg]

2013/9/25 Nick Evgeniev <nevg...@gmail.com>:

> Hi,
>
> to me it's still a sandbox language (python replacement to some degree)
> because of:
> 1. there is no such thing as reproducible build (i.e. checkout tagged
> version of go project and build it against predefined versions of go
> packages (dependencies) instead go promotes you to use all the latest (and
> this is the LAST thing I want in prod)

Having held this opinion myself for a while, I now think this is all a
misunderstanding based on the convenience of "go get". That is a
developer tool and has nothing to do with how you do builds on your
build server.

For reproducible builds, use whatever infrastructure you would
normally (i.e. for C, where the compiler suite doesn't really do
anything about versioning either...). There's a multitude of different
Go-specific approaches out there if you're looking for something new
(i.e. goven, rx, pak, ...).

//jb

[Shivakumar GN]

On Wed, Sep 25, 2013 at 2:04 PM, Nick Evgeniev <nevg...@gmail.com> wrote:

Hi,

to me it's still a sandbox language (python replacement to some degree) because of:

Please do not hijack the thread. The (original) thread is of considerable interest to some of us.

Request others to respond only if relevant to OP.

[DisposaBoy]

I'd like to ask you kindly not to derail topics on this list with spam or trolling.

[Luke Scott]

So what you're saying is there might be some risk, and it's mine to take.

Would it be possible for a company(s) to sponsor the work for crypto/tls to be more feature-complete / be throughly audited?

[David Anderson]

I don't think anyone would mind if such a sponsor appeared. If nothing else, it's another set of eyes on the code. Eventually, with enough eyes, trust in the code will grow.

I take it you have a sponsor in mind? :)

- Dave

 

 

--
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.

[Luke Scott]

On Wednesday, September 25, 2013 10:38:29 AM UTC-7, David Anderson wrote:

On Wed, Sep 25, 2013 at 10:32 AM, Luke Scott <lu...@visionlaunchers.com> wrote:

On Tuesday, September 24, 2013 6:53:31 PM UTC-7, Andrew Gerrand wrote:

On 25 September 2013 09:10, Luke Scott <lu...@visionlaunchers.com> wrote:

What is and what isn't considered serious in production? What about financial information?

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.

Andrew 

So what you're saying is there might be some risk, and it's mine to take.

Would it be possible for a company(s) to sponsor the work for crypto/tls to be more feature-complete / be throughly audited?

I don't think anyone would mind if such a sponsor appeared. If nothing else, it's another set of eyes on the code. Eventually, with enough eyes, trust in the code will grow.

I take it you have a sponsor in mind? :)

- Dave

Perhaps, in part. Being security related, it would probably take more than one sponsor though. At this point I'm not sure what/who would be involved.

[agl]

On Tuesday, September 24, 2013 1:55:48 PM UTC-4, Luke Scott wrote:

Many people have claimed that Go is being used in production and that it is production ready. According to a some comments in a few unresolved issues, the crypto/tls package is not production ready. Either this information is out of date, or this fact has not been made apparent (comment in the docs).

We've been integrating with some secure API's and one of them in particular requires client certificates and regeneration. I was quite shocked to find out that not only is this not supported, but there is no plans to support it (https://code.google.com/p/go/issues/detail?id=5742).

It is the case the renegotiation is not supported. I think I know what API you're trying to use and the one previous user who contacted me about it was able to get it working with only a small patch. Renegotiation, in general, was a design mistake in TLS but crypto/tls does, of course, try to be useful. If there's a significant need to support this then it is a candidate for inclusion in the standard library, but the standard library doesn't try to be all things to all people. It quite deliberately aims to be simpler at the cost of only supporting the 90% case. If edge cases can be handled with local modifications then that does release the trunk from the burden of maintaining the code. 

If you choose to pursue using Go for this I can dig up the patch for you if you wish.  

 

While digging further I came across this post (http://stackoverflow.com/questions/12642689/does-golang-tls-support-ie8). So users of IE8 cannot connect to a Go https server... great because IE8 is what we have to support at a minimum.

That stack overflow post is suggesting that IE8 is sending an SSLv2 format ClientHello, which is very surprising. I've just tested an IE 8 client on Windows XP and it actually works fine with Go and sends a TLS ClientHello as I would expect. crypto/tls doesn't support SSLv2 format ClientHellos, but nor should you need it to.

I was able to get IE 8 to send an SSLv2 format hello by enabling SSLv2 support in the advanced settings, but that doesn't appear to be the default (unless that setting has already been changed on the machine that I'm using), and I'm sure that there are lots of other ways to break things in there too.

 

Is this out of date? If not, why has it not received enough attention? Are there any companies out there willing to sponsor it?

Nobody to my knowledge has yet had a major review performed. (Although they may wish to put work into the ModExp functions first to close side-channels.)

Cheers

AGL 

[Luke Scott]

On Wednesday, September 25, 2013 1:42:10 PM UTC-7, agl wrote:

On Tuesday, September 24, 2013 1:55:48 PM UTC-4, Luke Scott wrote:

Many people have claimed that Go is being used in production and that it is production ready. According to a some comments in a few unresolved issues, the crypto/tls package is not production ready. Either this information is out of date, or this fact has not been made apparent (comment in the docs).

We've been integrating with some secure API's and one of them in particular requires client certificates and regeneration. I was quite shocked to find out that not only is this not supported, but there is no plans to support it (https://code.google.com/p/go/issues/detail?id=5742).

It is the case the renegotiation is not supported. I think I know what API you're trying to use and the one previous user who contacted me about it was able to get it working with only a small patch. Renegotiation, in general, was a design mistake in TLS but crypto/tls does, of course, try to be useful. If there's a significant need to support this then it is a candidate for inclusion in the standard library, but the standard library doesn't try to be all things to all people. It quite deliberately aims to be simpler at the cost of only supporting the 90% case. If edge cases can be handled with local modifications then that does release the trunk from the burden of maintaining the code. 

If you choose to pursue using Go for this I can dig up the patch for you if you wish.  

If you could I would really appreciate it. We're already invested in Go at this point.

 

 

While digging further I came across this post (http://stackoverflow.com/questions/12642689/does-golang-tls-support-ie8). So users of IE8 cannot connect to a Go https server... great because IE8 is what we have to support at a minimum.

That stack overflow post is suggesting that IE8 is sending an SSLv2 format ClientHello, which is very surprising. I've just tested an IE 8 client on Windows XP and it actually works fine with Go and sends a TLS ClientHello as I would expect. crypto/tls doesn't support SSLv2 format ClientHellos, but nor should you need it to.

I was able to get IE 8 to send an SSLv2 format hello by enabling SSLv2 support in the advanced settings, but that doesn't appear to be the default (unless that setting has already been changed on the machine that I'm using), and I'm sure that there are lots of other ways to break things in there too.

 

Is this out of date? If not, why has it not received enough attention? Are there any companies out there willing to sponsor it?

Nobody to my knowledge has yet had a major review performed. (Although they may wish to put work into the ModExp functions first to close side-channels.)

What would it take to make this happen?

[Andy Balholm]

On Wednesday, September 25, 2013 1:42:10 PM UTC-7, agl wrote:

On Tuesday, September 24, 2013 1:55:48 PM UTC-4, Luke Scott wrote:

It is the case the renegotiation is not supported. I think I know what API you're trying to use and the one previous user who contacted me about it was able to get it working with only a small patch. Renegotiation, in general, was a design mistake in TLS but crypto/tls does, of course, try to be useful. If there's a significant need to support this then it is a candidate for inclusion in the standard library, but the standard library doesn't try to be all things to all people. It quite deliberately aims to be simpler at the cost of only supporting the 90% case. If edge cases can be handled with local modifications then that does release the trunk from the burden of maintaining the code. 

 The version of OpenSSL that comes with Mac OS 10.8.4 still has this bug. I don't know why Apple hasn't upgraded, but they haven't. Among other things, this means that when I'm using my HTTPS proxy server, written in Go, go get does not work, since Mercurial uses the system OpenSSL library.