Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto/tls: Not stable tls handshake #18608

Closed
ikhahmedov opened this issue Jan 11, 2017 · 7 comments
Closed

crypto/tls: Not stable tls handshake #18608

ikhahmedov opened this issue Jan 11, 2017 · 7 comments

Comments

@ikhahmedov
Copy link

@ikhahmedov ikhahmedov commented Jan 11, 2017

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

go version go1.7.4 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build435595517=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

g++ --version
g++ (Ubuntu 4.9.2-10ubuntu13) 4.9.2

What did you do?

We are opening TLS connection to server, sending basic command implemented there.
occasionally socket returns EOF while in handshake process.
https://github.com/golang/go/blob/go1.7.4/src/crypto/tls/handshake_client.go#L637

Code: https://play.golang.org/p/-JK8L3ONcg

What did you expect to see?

OK, all the time, because executable is restarted every time we make connection

What did you see instead?

25% percent of TLS connection opening is failed with EOF

@ikhahmedov ikhahmedov changed the title Not stable tls handshake crypto/tls: Not stable tls handshake Jan 11, 2017
@ALTree

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Jan 11, 2017

Can you try with go1.8rc1? It looks like you are triggering the problem described in #17037, which was fixed in go1.8 by 5a59b66, so you shouldn't see the EOFs with go1.8, but actual alerts.

@ikhahmedov

This comment has been minimized.

Copy link
Author

@ikhahmedov ikhahmedov commented Jan 11, 2017

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

go version go1.8rc1 linux/amd64

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

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build900657989=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"

What did you see?

Same problem persists

@ALTree is there any way I can help with issue?

@ALTree

This comment has been minimized.

Copy link
Member

@ALTree ALTree commented Jan 11, 2017

With "same problem persists" you mean that you're still seeing EOFs during handshakes on go1.8?

@opennota

This comment has been minimized.

Copy link

@opennota opennota commented Jan 11, 2017

In my Go server logs there are many lines like these (Go 1.8 beta 2, too):

2017/01/11 20:55:03 http2: server: error reading preface from client *.*.153.123:14777: timeout waiting for client preface
2017/01/11 20:57:28 http: TLS handshake error from *.*.92.45:50361: EOF

Dunno if it is relevant.

@ikhahmedov

This comment has been minimized.

Copy link
Author

@ikhahmedov ikhahmedov commented Jan 12, 2017

With "same problem persists" you mean that you're still seeing EOFs during handshakes on go1.8?

Yes

@ALTree ALTree added this to the Go1.9 milestone Jan 12, 2017
@ikhahmedov

This comment has been minimized.

Copy link
Author

@ikhahmedov ikhahmedov commented Jan 12, 2017

@ALTree I have investigated an issue.

  1. I was wrong that this problem is Connection establishing issue
  2. It comes from reading data

Problem comes from here:
https://github.com/golang/go/blob/master/src/crypto/tls/conn.go#L1167

Data is there, but alert is also coming immediately with data, probably because nature of application is
server gets request, responds and immediately closes connection (1line, less than 100bytes).

fix is not checking err first, instead testing whether we got data and then check for error

n, err = conn.Read(buf)
if n != 0 {
	println(string(buf[:n]))
} 
if err != nil {
	log.Println(n, err)
	return
}

Maybe this should be documented

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz commented Jan 12, 2017

It is already documented at https://golang.org/pkg/io/#Reader ...

Callers should always process the n > 0 bytes returned before considering the error err.

Sounds like there's nothing to do here. Closing. Let me know if I misunderstand.

@bradfitz bradfitz closed this Jan 12, 2017
@golang golang locked and limited conversation to collaborators Jan 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.