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

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

Closed
bgilmore opened this issue Aug 5, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@bgilmore
Copy link

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 ianlancetaylor added this to the Go1.5 milestone Aug 5, 2015

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 5, 2015

@bgilmore

This comment has been minimized.

Copy link
Author

commented Aug 5, 2015

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

@gopherbot

This comment has been minimized.

Copy link

commented Aug 5, 2015

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

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

@golang golang locked and limited conversation to collaborators 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>
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.