tree 77ea104da01877545b1287dca9e2d6db5eeb2f98
parent 83824d298cf2272a265c44336a493c76d843b93a
author David Benjamin <davidben@google.com> 1727032664 -0400
committer Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> 1727203333 +0000

Add a test for a subtle corner of 0-RTT and version tracking

This is a huge mess. I was trying to simplify our version state to be:

- Version not known
- Version not known but sending 0-RTT at V
- Version known to be V

But it turns out we can actually have both early version and true
versions existing and at different values. There are two cases:

1. We send TLS 1.3 early data and get back a TLS 1.2 ServerHello. We
   will return an error but, at least right now, we continue to present
   a self-consistent TLS 1.3 picture, even though we send the
   protocol_version alert at TLS 1.2.

2. [Does not exist yet] We send TLS 1.4 early data and get back a TLS
   1.3 ServerHello. This isn't even fatal to the connection, so we
   especially should keep reporting the early session until
   SSL_reset_early_Data_reject.

Case 2 is extra weird because we won't actually immediately flag the
mismatch as a 0-RTT reject! Right now we don't run the reject ceremony
until we read EncryptedExtensions, but at that point we'll have even
decrypted a record under the other version.

But this case also doesn't exist today. There is an analogous thing that
does exist today with the cipher suite. For both the version and the
cipher suite, we get around this right now by having the SSLAEADContext
hold on to this information, so we pull it out of there.

We could instead run the rejection ceremony at multiple points in the
handshake, as soon as we detect any kind of inconsistency. Not sure
which is best. Either way, let's test this case.

Change-Id: I333175b25ba35261e1dd7d02e9ec1d9f1d43ff73
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71531
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>