| commit | 361e3e0aba458b0e91bb80b88adf84986dfa45b0 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Sep 11 13:58:38 2022 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Sep 14 20:58:16 2022 +0000 |
| tree | 9aa6fd2a066ddbd16129b51b24b6d8245f73dba5 | |
| parent | 91e0b11eba517d83b910b20fe3740eeb39ecb37e [diff] |
Move the DTLS cookie to SSL_HANDSHAKE. The cookie is only needed in SSL_HANDSHAKE, so there's no need to retain it for the lifetime of the connection. (SSL_HANDSHAKE is released after the handshake completes.) Back when DTLS1_COOKIE_LENGTH was 32, storing it inline made some sense. Now that RFC 6347 increased the maximum to 255 bytes, just indirect it with an Array<uint8_t>. Along the way, remove the DTLS1_COOKIE_LENGTH checks. The new limit is the largest that fits in the length prefix, so it's always redundant. In fact, the constant was one higher was allowed anyway. Add some tests for the maximum length, as well as zero-length cookies. I considered just repurposing the plain cookie field, used in HelloRetryRequest (as opposed to HelloVerifyRequest), as they're mutually exclusive, even in DTLS 1.3. But, when we get to DTLS 1.3, that'll get a little hairy because ssl_write_client_hello will need extra checks to know whether hs->cookie is meant to go in the ClientHello directly or in extensions. Change-Id: I1afedc7ce31414879545701bf8fe4658657ba66f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54466 Reviewed-by: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
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: