Google Git
Sign in
boringssl / boringssl / 72a60506ded3407454d6ddc1d848c266020c0c82
commit72a60506ded3407454d6ddc1d848c266020c0c82[log] [tgz]
authorDavid Benjamin <davidben@google.com>Fri Sep 27 12:07:47 2024 -0400
committerBoringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>Fri Sep 27 21:25:33 2024 +0000
treed6eaf91881a3753a7731198fc7076b0f8b6fa764
parent37571ee525bf1484fa76b4731053e7e7ddb93d31 [diff]
Use illegal_parameter instead of decode_error for invalid key shares

This is extremely silly and a huge waste of everyone's time (I deeply
regret disambiguating illegal_parameter and decode_error for RFC 8446),
but so it goes. Technically these errors pass the TLS syntax and are an
invalid value, so they should be illegal_parameter.

   Note: TLS defines two generic alerts (see Section 6) to use upon
   failure to parse a message.  Peers which receive a message which
   cannot be parsed according to the syntax (e.g., have a length
   extending beyond the message boundary or contain an out-of-range
   length) MUST terminate the connection with a "decode_error" alert.
   Peers which receive a message which is syntactically correct but
   semantically invalid (e.g., a DHE share of p - 1, or an invalid enum)
   MUST terminate the connection with an "illegal_parameter" alert.

Update-Note: The error sent on invalid key share is now more correct.
This does not change which connections do or do not fail, only which of
two practically identical alert codes is sent to the other side.

Change-Id: If0ddf511d6cf23383c6134ad30e3ae080c4f2769
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71627
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
2 files changed
tree: d6eaf91881a3753a7731198fc7076b0f8b6fa764
  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: