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

net/http: TLS handshake failure when session resumption is attempted #12024

Closed

bgilmore opened this issue Aug 5, 2015 · 3 comments

bgilmore commented Aug 5, 2015

TLS session resumption by net/http Transport was broken by 3cf15b5

Example program: http://play.golang.org/p/yNVJaXwaxM

go version go1.4.2 linux/amd64:

<no output>

go version devel +3cfc34a Tue Aug 4 21:10:58 2015 +0000 linux/amd64

Died on iteration 2: Get https://www.google.com/: tls: handshake did not verify certificate chain
exit status 1

ianlancetaylor added this to the Go1.5 milestone Aug 5, 2015

Contributor

ianlancetaylor commented Aug 5, 2015

Author

bgilmore commented Aug 5, 2015

Sent https://go-review.googlesource.com/13145, but I'm still working on a reasonable test.

gopherbot commented Aug 5, 2015

CL https://golang.org/cl/13164 mentions this issue.

rsc closed this in `46a2913` Aug 5, 2015

golang locked and limited conversation to collaborators Aug 5, 2016

gopherbot added the FrozenDueToAge label Aug 5, 2016

FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018


      crypto/tls: fix ConnectionState().VerifiedChains for resumed connection

Strengthening VerifyHostname exposed the fact that for resumed
connections, ConnectionState().VerifiedChains was not being saved
and restored during the ClientSessionCache operations.
Do that.

This change just saves the verified chains in the client's session
cache. It does not re-verify the certificates when resuming a
connection.

There are arguments both ways about this: we want fast, light-weight
resumption connections (thus suggesting that we shouldn't verify) but
it could also be a little surprising that, if the verification config
is changed, that would be ignored if the same session cache is used.

On the server side we do re-verify client-auth certificates, but the
situation is a little different there. The client session cache is an
object in memory that's reset each time the process restarts. But the
server's session cache is a conceptual object, held by the clients, so
can persist across server restarts. Thus the chance of a change in
verification config being surprisingly ignored is much higher in the
server case.

Fixes golang#12024.

Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16
Reviewed-on: https://go-review.googlesource.com/13164
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018


      crypto/tls: fix ConnectionState().VerifiedChains for resumed connection

Strengthening VerifyHostname exposed the fact that for resumed
connections, ConnectionState().VerifiedChains was not being saved
and restored during the ClientSessionCache operations.
Do that.

This change just saves the verified chains in the client's session
cache. It does not re-verify the certificates when resuming a
connection.

There are arguments both ways about this: we want fast, light-weight
resumption connections (thus suggesting that we shouldn't verify) but
it could also be a little surprising that, if the verification config
is changed, that would be ignored if the same session cache is used.

On the server side we do re-verify client-auth certificates, but the
situation is a little different there. The client session cache is an
object in memory that's reset each time the process restarts. But the
server's session cache is a conceptual object, held by the clients, so
can persist across server restarts. Thus the chance of a change in
verification config being surprisingly ignored is much higher in the
server case.

Fixes golang#12024.

Change-Id: I3081029623322ce3d9f4f3819659fdd9a381db16
Reviewed-on: https://go-review.googlesource.com/13164
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>

9c9b97f

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

You can’t perform that action at this time.