]> Cypherpunks repositories - gostls13.git/commit
crypto/tls: fix ConnectionState().VerifiedChains for resumed connection
authorRuss Cox <rsc@golang.org>
Wed, 5 Aug 2015 13:53:56 +0000 (09:53 -0400)
committerAdam Langley <agl@golang.org>
Wed, 5 Aug 2015 19:59:28 +0000 (19:59 +0000)
commit46a29138827cefb15e437f291cbb2ccda685b840
tree76e81ed91726e7abe82a1e633c1feccbfefc8d12
parent0290d51b4ada1615853b2dc368902b2a310392f3
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 #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>
src/crypto/tls/common.go
src/crypto/tls/handshake_client.go
src/crypto/tls/handshake_client_test.go
src/crypto/tls/tls_test.go