You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried writing to the connection and it accepts my writes with out error
but when I read, I finally get the tls error
c.Assert(err, IsNil)
... value *net.OpError = &net.OpError{Op:"remote error", Net:"", Source:net.Addr(nil), Addr:net.Addr(nil), Err:0x2a} ("remote error: tls: bad certificate")
The server code tcp listener returns tcpConn that is promoted to tlsConn
tcpConn, err := s.listener.(*net.TCPListener).AcceptTCP()
if err != nil {
// detect that the listener has been closed & exit gracefully
log.Panicf("tls listener: Accept: %s", err)
}
tcpConn.SetKeepAlive(true)
clientConn := tls.Server(tcpConn, s.tlsConfig)
deffer clientConn.Close()
err := clientConn.(*tls.Conn).Handshake()
if err != nil {
return
}
It is going into that last err block and printing closeConnect
What did you expect to see?
I expected the same error to be return form tls.Dial as I was receiving with go 1.12
What did you see instead?
no error returned, until I tried to read from the socket
The text was updated successfully, but these errors were encountered:
This is due to a fundamental protocol difference between TLS 1.3 (enabled in Go 1.13) and TLS 1.2: client certificates are checked by the server after the client finished the handshake (this saves a whole round-trip), so the error is only sent to the client after Handshake and Dial have returned. To catch it in a test you have to do a Read on the client side.
FiloSottile
changed the title
crypto/tls/conn client connection is staying open after server has closed it
crypto/tls: client connection is staying open after server has closed it
Oct 9, 2019
What version of Go are you using (
go version
)?go version go1.13.1 linux/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user1/.cache/go-build"
GOENV="/home/user1/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user1/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/user1/go/src/prj/t/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build100025384=/tmp/go-build -gno-record-gcc-switches"
What did you do?
upgraded from go1.12 to go 1.13
no change to my code or unittests
ran my unit tests
we have simple tls server and client is implemented in the unit test code
_, err := tls.Dial("tcp", suite.Server.GetListenerAddr().String(), &tls.Config{
RootCAs: roots,
InsecureSkipVerify: true,
Certificates: []tls.Certificate{clientCert},
})
c.Assert(err, ErrorMatches, ".*bad certificate")
with 1.13, err is nil
I tried writing to the connection and it accepts my writes with out error
but when I read, I finally get the tls error
... value *net.OpError = &net.OpError{Op:"remote error", Net:"", Source:net.Addr(nil), Addr:net.Addr(nil), Err:0x2a} ("remote error: tls: bad certificate")
The server code tcp listener returns tcpConn that is promoted to tlsConn
tcpConn, err := s.listener.(*net.TCPListener).AcceptTCP()
if err != nil {
// detect that the listener has been closed & exit gracefully
log.Panicf("tls listener: Accept: %s", err)
}
tcpConn.SetKeepAlive(true)
clientConn := tls.Server(tcpConn, s.tlsConfig)
deffer clientConn.Close()
err := clientConn.(*tls.Conn).Handshake()
if err != nil {
return
}
It is going into that last err block and printing closeConnect
What did you expect to see?
I expected the same error to be return form tls.Dial as I was receiving with go 1.12
What did you see instead?
no error returned, until I tried to read from the socket
The text was updated successfully, but these errors were encountered: