tree 7e37a34a4e807a098687a1bf8020a4f57b2990f8
parent 44544d9d2d624cbfff9b1e77cb77f8dfc70d073c
author David Benjamin <davidben@google.com> 1565983923 -0400
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1566233083 +0000

Check the second ClientHello's PSK binder on resumption.

We perform all our negotiation based on the first ClientHello (for
consistency with what |select_certificate_cb| observed), which is in the
transcript, so we can ignore most of the second one.

However, we ought to check the second PSK binder. That covers the client
key share, which we do consume. In particular, we'll want to check if it
we ever send half-RTT data on these connections (we do not currently do
this). It is also a tricky computation, so we enforce the peer handled
it correctly.

Tested that both Chrome and Firefox continue to interop with this check,
when configuring uncommon curve preferences that trigger HRR. (Normally
neither browser sees HRRs against BoringSSL servers.)

Update-Note: This does enforce some client behavior that we hadn't been
    enforcing previously. However, it only figures into TLS 1.3 (not many
    implementations yet), and only clients which hit HelloRetryRequest
    (rare), so this should be low risk.
Change-Id: I42126585ec0685d009542094192e674cbd22520d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37124
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>