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: TLS session resumption re-verifies the client's certificate chain #31641

Open
marten-seemann opened this issue Apr 24, 2019 · 2 comments
Assignees
Milestone

Comments

@marten-seemann
Copy link
Contributor

@marten-seemann marten-seemann commented Apr 24, 2019

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

$ go version
1.12.x

Does this issue reproduce with the latest release?

Yes

What did you do?

When using TLS session resumption with client certificates, the server reverifies the client's certificate chain.

What did you expect to see?

When using TLS session resumption the server sends an encrypted (and MACed) ticket to the client, which the client presents during the next handshake. According to the spec, the session ticket is an opaque blob. The Go implementation encodes the client's certificate chain into the session ticket. If the server is able to authenticate and decrypt the session ticket presented by the client, this should serve as proof that the server communicated with this client before, and allow it to skip the (potentially computationally expensive) verification of the certificate chain.

Re-verifying leads to unexpected consequences if the tls.Config.VerifyPeerCertificate callback was changed such that it rejects the certificate in between the original and the resumed connection . Since the server re-verifies the certificate chain, it will reject the connection. The client doesn't perform any verification (other than checking that the certificate didn't expire) and is happy to resume a connection even if its VerifyPeerCertificate callback would have rejected the server's certificate chain on a new connection.

@bradfitz bradfitz changed the title TLS session resumption re-verifies the client's certificate chain crypto/tls: TLS session resumption re-verifies the client's certificate chain Apr 24, 2019
@bradfitz bradfitz added this to the Go1.13 milestone Apr 24, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Oct 1, 2019

I noticed this while implementing TLS 1.3, and it's not an easy decision. The discrepancy between client and server is bad. On the one hand, if the verification policy has changed, the application probably expects it to apply to all connections, so we should re-verify. On the other hand, verification is expensive and session tickets are a performance measure.

Usually, it's servers that have the most performance concern, though, so I am tempted to resolve the discrepancy towards safety, by making clients reverify as well. Opinions?

(Related to #25352)

@marten-seemann

This comment has been minimized.

Copy link
Contributor Author

@marten-seemann marten-seemann commented Oct 2, 2019

Since we're encoding the whole certificate chain in the session ticket, there's no point whatsoever to use session tickets with TLS 1.3 at all: The amount of data transferred during the handshake is (modulo some framing overhead) exactly the same as during a normal handshake, the computational cost of re-verifying the certificate chain is the same, and we're not even saving any roundtrips.

Couldn't one argue that the security properties of a resumed session should be the same as those of the original session? If the session was kept alive (instead of being resumed), the new policy wouldn't apply to that session either, right?

@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.