crypto/tls: allow VerifyConnection to request a full handshake

[FiloSottile]

If VerifyConnection returns an error, the connection is terminated. If the connection is a resumption, there is no way for the callback to decide it would like the client to proceed to a full handshake, instead.

We could define a special error, tested with errors.Is, which causes the resumption to be rejected. In that case VerifyConnection can be called two or more times for a connection. (More if there are multiple session tickets.)

This is an issue and not a proposal for two reasons:

1. we need to figure out if it's technically feasible to call VerifyConnection the first time while still in the handshake phase at which we choose whether to resume or not;
2. we need to spec out a precise API.

Originally discussed at #77217 (comment).

(@espadolini pointed out that while we define smart errors for VerifyConnection, we could also make one that allows sending the peer a different TLS alert to close the connection.)

/cc @golang/security

[gabyhelp]

Related Issues

• crypto/tls: disable session resumption when VerifyPeerCertificate is in use #77377
• crypto/tls: VerifyConnection is called twice by tls 1.3 servers if connection is resumed #39012 (closed)
• crypto/tls: add Config.VerifyConnection callback #36736 (closed)
• crypto/tls: certificate chains aren't re-checked on resumption #77217
• crypto/tls: TLS session resumption re-verifies the client's certificate chain #31641 (closed)
• crypto/tls: allow omitting certificates from session ticket #77379
• crypto/tls: cap lifetime of authentication in TLS 1.3 #77294

Related Code Changes

• crypto/tls: check verifiedChains roots when resuming sessions

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}