Google Git
Sign in
boringssl / boringssl / a0b324f96615bdca7bd048f23589a2445ccdc6a4
commita0b324f96615bdca7bd048f23589a2445ccdc6a4[log] [tgz]
authorDavid Benjamin <davidben@google.com>Mon Sep 23 17:08:40 2024 -0400
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>Thu Oct 03 19:54:57 2024 +0000
treea477881ec9b69def80eb04e933a0c626b83f82f8
parentf8cadd89744dffe7a566c458b80bf2846f213ff1 [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>
12 files changed
tree: a477881ec9b69def80eb04e933a0c626b83f82f8
  1. .bcr/
  2. .github/
  3. cmake/
  4. crypto/
  5. decrepit/
  6. docs/
  7. fuzz/
  8. gen/
  9. include/
  10. pki/
  11. rust/
  12. ssl/
  13. third_party/
  14. tool/
  15. util/
  16. .bazelignore
  17. .bazelrc
  18. .clang-format
  19. .gitignore
  20. API-CONVENTIONS.md
  21. BREAKING-CHANGES.md
  22. BUILD.bazel
  23. build.json
  24. BUILDING.md
  25. CMakeLists.txt
  26. codereview.settings
  27. CONTRIBUTING.md
  28. FUZZING.md
  29. go.mod
  30. go.sum
  31. INCORPORATING.md
  32. LICENSE
  33. MODULE.bazel
  34. MODULE.bazel.lock
  35. PORTING.md
  36. PrivacyInfo.xcprivacy
  37. README.md
  38. SANDBOXING.md
  39. STYLE.md
README.md

BoringSSL

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: