crypto/tls: tls connection broken in 1.5

[leo-stone]

Hello,
it seems "crypto/tls" is broken since GO 1.5. (Windows)
Here you find the code to reproduce the problem.

I could not test on any OS other than Windows.
Confirmed on Windows, Linux, OS X (tx @bradfitz )

[ianlancetaylor]

Can you write a test case that does not require the heroku package and does not require contacting other servers? There isn't enough information here to know where the problem is.

[leo-stone]

I did what I could, to provide you with a setup to investigate the issue.
Unfortunatly i have no more resources than that.

[bradfitz]

@ianlancetaylor, the referenced program at least contains the necessary credentials to run it easily.

I can confirm the issue on OS X too, so it's not Windows specific.

With Go 1.4:

$ go run x.go
2015/10/16 07:37:26 rendezvous.runtime.heroku.com:5000
2015/10/16 07:37:26 /81ba7f46d09156cc43d642e03f249157f4ad1e488583903b130ab5b1e97cb464
2015/10/16 07:37:27 Sending secret: 81ba7f46d09156cc43d642e03f249157f4ad1e488583903b130ab5b1e97cb464
2015/10/16 07:37:27 Bytes sent:  64
2015/10/16 07:37:27 12 <nil>
2015/10/16 07:37:27 rendezvous

2015/10/16 07:37:30 7 <nil>
2015/10/16 07:37:30 hello

2015/10/16 07:37:30 0 EOF
2015/10/16 07:37:30 

With Go 1.5:

$ go run x.go
2015/10/16 07:38:07 rendezvous.runtime.heroku.com:5000
2015/10/16 07:38:07 /e6ac3371bd9e97be4ef5db06bd4b82712a89264b7198ee0619eca06b306fb18e
2015/10/16 07:38:07 Sending secret: e6ac3371bd9e97be4ef5db06bd4b82712a89264b7198ee0619eca06b306fb18e
2015/10/16 07:38:07 Bytes sent:  64
(hang)

Ignore the difference in the hex string. That changes randomly per run regardless of Go version.

I haven't looked into this more than just reproducing it.

[bradfitz]

Perhaps @bgentry can help debug, as the author of that Heroku package.

[bgentry]

@bradfitz I suspect this could have something to do with the specific version of OpenSSL running on Heroku's rendezvous component. I no longer work there, but maybe @fabiokung, @dpiddy, or @freeformz would be able to debug further.

The heroku-go package is just using http.Client under the hood to make an API call that spawns a "dyno" (container) on Heroku. That part is really irrelevant, except that it returns a URL that needs to be used in the connection to rendezvous.

You can see a complete example of how this is done in the hk client, which uses heroku-go. So anybody with a Heroku account should be able to reproduce this issue using hk run -a myappname bash on Windows (which I haven't tried).

Separately, @leo-stone you are going to want to rotate your API key as the one you included in your repo is now compromised, and anybody can use it to modify your Heroku apps and/or rack up charges on your account.

[bradfitz]

@bgentry, if the official hk client uses Go, I would suspect people at Heroku have already identified this problem? I'm a little surprised we haven't already heard about it. Can you recommend any contacts there to talk about this?

[freeformz]

@dickeyxxx owns the heroku CLI tools, which include hk AFAIK.

[bgentry]

hk is more or less unmaintained at this point, so wouldn't
necessarily count on this having been encountered before.

On Friday, October 16, 2015, Brad Fitzpatrick notifications@github.com
wrote:

@bgentry https://github.com/bgentry, if the official hk client uses Go,
I would suspect people at Heroku have already identified this problem? I'm
a little surprised we haven't already heard about it. Can you recommend any
contacts there to talk about this?

—
Reply to this email directly or view it on GitHub
#12957 (comment).

[jdx]

To be clear, it is not maintained. We need to update the project to reflect this.

[bgentry]

regardless of hk's status, this is probably bad interaction between Go's crypto/tls on Windows and whatever Heroku's rendezvous component is using for TLS. hk run should at least be a reliable way to reproduce the issue.

@dickeyxxx if you could raise this w/ folks on Heroku's runtime team to help track down the issue that would be 👍

[jdx]

will do! thanks @bgentry!

[leo-stone]

I got around to confirm that this issue also exists on Linux-64bit.

[leo-stone]

Issue still existent in go 1.6.0 :(