commit | a0b324f96615bdca7bd048f23589a2445ccdc6a4 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Mon Sep 23 17:08:40 2024 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Oct 03 19:54:57 2024 +0000 |
tree | a477881ec9b69def80eb04e933a0c626b83f82f8 | |
parent | f8cadd89744dffe7a566c458b80bf2846f213ff1 [diff] |
Remove redudant version information from SSLAEADContext After https://boringssl-review.googlesource.com/c/boringssl/+/71533, it is never the case that we have two version's worth of the record layer alive at once. This means we stop needing to store a version number in the epoch state, or worry about which version we check if in theory the connection and each epoch are in different states. (I'm not sure how DTLS 1.3 ACKs will possibly work in such a model.) Simply this by taking versions out of the epochs and instead having everything check the connection's version. For that to work, we need to relax the invariants on the version slightly. When we enter 0-RTT, we set the version to the 0-RTT version. The final version will then either match or trigger a 0-RTT reject before changing the version. Having the version change is unfortunate but it reflects what's going on. As a result, some checks added for DTLS 1.3 will now behave correctly with DTLS 1.3 0-RTT. This also simplifies things slightly along the way to cleaning up the epoch state to implement DTLS 1.3 ACKs. There are two checks that arguably did not want to pay attention to the 0-RTT version, but the difference seems unimportant. But, for completeness: 1. If we offer 0-RTT, the logic to ignore dummy ChangeCipherSpec records deep in the record layer will kick in before the ServerHello, instead of after. This is arguably supported by RFC 8446, which says any time after the first ClientHello suffices: > An implementation may receive an unencrypted record of type > change_cipher_spec consisting of the single byte value 0x01 at any > time after the first ClientHello message has been sent or received > and before the peer's Finished message has been received and MUST > simply drop it without further processing. Though that guidance is pretty bizarre because we haven't learned the version yet before ServerHello. Anyway, I don't think this has any real practical impact and isn't worth fussing over. 2. If we offer 0-RTT, the logic to treat a "warning" decode_error alert as fatal will kick in before the ServerHello, instead of after. If the server deployed 0-RTT, then rolled back to TLS 1.2 (against the guidance in Appendix D.3 but possible), AND if it sent a warning alert before the TLS 1.2 ServerHello, we would fail the connection with a different error and not trigger the application's retry. This also does not seem worth fussing over. Bug: 42290594 Change-Id: I8d97e219888c75274c3c640b2da5c769c6b9ad36 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71534 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: