Google Git
Sign in
boringssl / boringssl / e2e41dadaefec8961cc4b799f96703073b7a683d
commite2e41dadaefec8961cc4b799f96703073b7a683d[log] [tgz]
authorDavid Benjamin <davidben@google.com>Mon Nov 25 15:43:04 2024 -0500
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>Thu Dec 05 16:42:51 2024 +0000
treeced9c4da9f37d6810ac4b2232a3e40797e39e8ca
parent6bf2625ee0435a2d07e5609318a86c3ce1d533b6 [diff]
Check for message sequence overflow in DTLS

In DTLS 1.2, message sequence number overflow was impossible. The
counter reset on every handshake, and every handshake had a bounded
number of messages. (The counter reset was actually problematic. The end
of one handshake and the start of the next shared epochs, so sequence
numbers become ambiguous. 1.3 fixes this by removing the reset but, in
hindsight, resetting on each epoch would probably have been better.)

In DTLS 1.3, there is no bound and overflow is possible. Check for
overflow. Somewhat annoyingly, because we tend to store the next
sequence number, we actually need 17 bits per sequence number to
represent this, if we want to accept up to the maximum possible message.
Test this on the read side with KeyUpdate. (To test this on the write
side, we must be able to send KeyUpdate.)

Bug: 42290594
Change-Id: I691855dc72427afb9e82d8de0fb2eeea6818f2ea
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73507
Reviewed-by: Nick Harper <nharper@chromium.org>
Commit-Queue: David Benjamin <davidben@google.com>
4 files changed
tree: ced9c4da9f37d6810ac4b2232a3e40797e39e8ca
  1. .bcr/
  2. .github/
  3. cmake/
  4. crypto/
  5. decrepit/
  6. docs/
  7. fuzz/
  8. gen/
  9. include/
  10. infra/
  11. pki/
  12. rust/
  13. ssl/
  14. third_party/
  15. tool/
  16. util/
  17. .bazelignore
  18. .bazelrc
  19. .bazelversion
  20. .clang-format
  21. .gitignore
  22. API-CONVENTIONS.md
  23. BREAKING-CHANGES.md
  24. BUILD.bazel
  25. build.json
  26. BUILDING.md
  27. CMakeLists.txt
  28. codereview.settings
  29. CONTRIBUTING.md
  30. FUZZING.md
  31. go.mod
  32. go.sum
  33. INCORPORATING.md
  34. LICENSE
  35. MODULE.bazel
  36. MODULE.bazel.lock
  37. PORTING.md
  38. PrivacyInfo.xcprivacy
  39. README.md
  40. SANDBOXING.md
  41. 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: