crypto/tls: handshake hangs when running over synchronous/unbuffered connection

[runeaune]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go1.9.4

Does this issue reproduce with the latest release?

Most likely

What operating system and processor architecture are you using (go env)?

darwin and amd64

What did you do?

I'm writing a test that relies on crypto/tls but mocks out the underlying net.Conn with https://github.com/jordwest/mock-conn/blob/master/end.go (this implements an unbuffered, local net.Conn based on two io.Pipes).

(I can help provide full example code if I get confirmation that fixing this issue is likely to be prioritized)

What did you expect to see?

I expected a completed handshake, and a useable TLS tunnel to be set up over the pipe. As far as I can tell, this can be achieved by never flushing multiple records together, or by reading responses in parallel with the flushing.

What did you see instead?

The TLS handshake hangs and eventually times out.

My limited digging points towards this flush as a likely culprit:

go/src/crypto/tls/handshake_server.go

Line 444 in 4c1aff8

if _, err := c.flush(); err != nil {

There seems to be multiple records being flushed together. The receiver wants to respond to the first one, but the sender needs to complete the flush before accepting any responses. Thus they are both blocked trying to write to the connection.

[odeke-em]

Hello @runeaune, thank you for creating the issue and welcome to Go!

(I can help provide full example code if I get confirmation that fixing this issue is likely to be prioritized)

We could try our best but unfortunately we can't make such guarantees, the number of specialists and for that matter code contributors is a handful(more are very welcome!), plus a complete issue is the value proposition that contributors will use to decide if the issue is worth their time. It is a time and attention economy relying at times on volunteered contributions(such as my own), so ironically I would suggest that the best way to try to get your issue prioritized(no promises) is by posting a fully reproducible sample. The less issue digging and reproduction cognitive load for contributors, the higher the success rate, please try it out.

In the meantime I'll mark this issue as "WaitingForInfo" as that's the state that it is in.
Thank you.

[ianlancetaylor]

If I understand correctly, you are suggesting that we modify the default implementation of crypto/tls so that it works over an unbuffered networking connection, for testing purposes. I'm sorry, we aren't going to do that. Real network connections do buffer data, and it seems reasonable for the crypto/tls code to assume that that will work.

[gopherbot]

Change https://golang.org/cl/142817 mentions this issue: crypto/tls: replace net.Pipe in tests with real TCP connections

[gopherbot]

Change https://golang.org/cl/142818 mentions this issue: crypto/tls: replace custom *block with standard buffers