Update to draft-ietf-tls-esni-13.

Later CLs will clean up the ClientHello construction a bit (draft-12
avoids computing ClientHelloOuter twice). I suspect the transcript
handling on the client can also be simpler, but I'll see what's
convenient after I've changed how ClientHelloOuter is constructed.

Changes of note between draft-10 and draft-13:

- There is now an ECH confirmation signal in both HRR and SH. We don't
  actually make much use of this in our client right now, but it
  resolves a bunch of weird issues around HRR, including edge cases if
  HRR applies to one ClientHello but not the other.

- The confirmation signal no longer depends on key_share and PSK, so we
  don't have to work around a weird ordering issue.

- ech_is_inner is now folded into the main encrypted_client_hello code
  point. This works better with some stuff around HRR.

- Padding is moved from the padding extension, computed with
  ClientHelloInner, to something we fill in afterwards. This makes it
  easier to pad up the whole thing to a multiple of 32. I've accordingly
  updated to the latest recommended padding construction, and updated
  the GREASE logic to match.

- ech_outer_extensions is much easier to process because the order is
  required to be consistent. We were doing that anyway, and now a simple
  linear scan works.

- ClientHelloOuterAAD now uses an all zero placeholder payload of the
  same length. This lets us simplify the server code, but, for now, I've
  kept the client code the same. I'll follow this up with a CL to avoid
  computing ClientHelloOuter twice.

- ClientHelloOuterAAD is allowed to contain a placeholder PSK. I haven't
  filled that in and will do it in a follow-up CL.

Bug: 275
Change-Id: I7464345125c53968b2fe692f9268e392120fc2eb
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48912
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
20 files changed
tree: 9794caad72b730867e8fb0415cc0cecb22f9cace
  1. .clang-format
  2. .github/
  3. .gitignore
  4. API-CONVENTIONS.md
  5. BREAKING-CHANGES.md
  6. BUILDING.md
  7. CMakeLists.txt
  8. CONTRIBUTING.md
  9. FUZZING.md
  10. INCORPORATING.md
  11. LICENSE
  12. PORTING.md
  13. README.md
  14. SANDBOXING.md
  15. STYLE.md
  16. codereview.settings
  17. crypto/
  18. decrepit/
  19. fuzz/
  20. go.mod
  21. go.sum
  22. include/
  23. sources.cmake
  24. ssl/
  25. third_party/
  26. tool/
  27. util/
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:

There are other files in this directory which might be helpful: