Google Git
Sign in
boringssl / boringssl / 5b03c8fd1c54397eded6bf84ef52ac610d79bddd
commit5b03c8fd1c54397eded6bf84ef52ac610d79bddd[log] [tgz]
authorDavid Benjamin <davidben@google.com>Mon Oct 28 17:42:12 2024 -0400
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>Wed Nov 06 23:56:37 2024 +0000
tree95b3ba45c474f2a65654834a4f0fef1184a4f667
parentabed22499d36aa35b3a5c829a88316b0c8280d74 [diff]
Redo DTLS retransmit tests

Previously, we tested DTLS retransmit by hooking *before* processing a
flight and bracketing one flight's worth of packets and then dropping
all of them, with minimal processing. We'd then repeat this a few times
and, once we were satisfied, actually process the next flight. This has
a few drawbacks:

1. We cannot interleave timeouts with chunks of the next flight.
   Retransmit of the peer's flight, in both 1.2 and 1.3, interacts with
   the peer receiving all or parts of the next flight, and in different
   ways.

2. We cannot easily, in 1.3, ACK part of a flight and then wait for the
   shim to retransmit the other part.

The new design instead hooks *after* we construct the reply to the
peer's flight under test. We buffer up all the data to be sent and then
call into a test-supplied callback that can control the exact order of
timeouts, etc. See the comment on DTLSController for more details.

As part of this, ChangeCipherSpec is now implicitly ordered with
ReorderHandshakeFragments, so there is no more need to carry
ReorderChangeCipherSpec separately.

Bug: 42290594
Change-Id: I754946dbb5591188aa2d32b694f213269836b266
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72708
Reviewed-by: Nick Harper <nharper@chromium.org>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
6 files changed
tree: 95b3ba45c474f2a65654834a4f0fef1184a4f667
  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. .clang-format
  20. .gitignore
  21. API-CONVENTIONS.md
  22. BREAKING-CHANGES.md
  23. BUILD.bazel
  24. build.json
  25. BUILDING.md
  26. CMakeLists.txt
  27. codereview.settings
  28. CONTRIBUTING.md
  29. FUZZING.md
  30. go.mod
  31. go.sum
  32. INCORPORATING.md
  33. LICENSE
  34. MODULE.bazel
  35. MODULE.bazel.lock
  36. PORTING.md
  37. PrivacyInfo.xcprivacy
  38. README.md
  39. SANDBOXING.md
  40. 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: