tree ffc81c26951e6108a88a3924c3b27774be532217
parent 96123c01b8c872945004ea9a2c7a1e7c7bf13823
author David Benjamin <davidben@google.com> 1504021692 -0400
committer Przemyslaw Szczepaniak <pszczepaniak@google.com> 1504268942 +0000

Don't reauthenticate on renegotiation.

We currently forbid the server certificate from changing on
renegotiation. This means re-verifying the certificate is pointless and
indeed the callback being called again seems to surprise consumers more
than anything else.

Carry over the initial handshake's SCT lists and OCSP responses (don't
enforce they don't change since the server may have, say, picked up new
OCSP responses in the meantime), ignore new ones received on
renegotiation, and don't bother redoing verification.

For our purposes, TLS 1.2 renegotiation is an overcomplicated TLS 1.3
KeyUpdate + post-handshake auth. The server is not allowed to change
identity.

This is a cherry-pick of https://boringssl-review.googlesource.com/19665
and https://boringssl-review.googlesource.com/19684 to resolve a
Conscrypt bug. The new certificate verify logic in Conscrypt did not
account for renegotiation needing to verify the new certificate,
long-standing behavior of OpenSSL and BoringSSL. However, since
BoringSSL does not allow the server certificate to change on
renegotiation due to 3-SHAKE, this behavior is unnecessary and it was
cleanest to stop calling the callback.

Exempt-From-Owner-Approval: flooey is on vacation 
Merged-In: I615af59fe8af4c56e6cf83a364c0fd69be70c415
Merged-In: I41df37881b9c2228b9a7b3569f1532f3b0dcbaea
Bug: 64827202
Change-Id: Ie97fc68ad992db2dbde7ba4af519757200a199f3