| commit | c59bf8bf189dcbde868e04efcd53b705ed155231 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Nov 12 12:02:09 2024 -0500 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Nov 13 05:22:33 2024 +0000 |
| tree | c541ea30ca1040da20ceab4f4e3ff70a028cc1fe | |
| parent | 4ad93a8c50451ee4c7cc31ecc49aeb19200a4e78 [diff] |
Support skipping tickets in both ticket callbacks TLS 1.2 and TLS 1.3 both support some mechanism for the server to change its mind at the last minute and not send a ticket. In TLS 1.2, you leave the ticket field empty. In TLS 1.3, you just don't send NewSessionTicket in the first place. We have two ticket encryption callbacks, the old "ticket key callback" and the "ticket AEAD callback". The ticket key callback has no way to trigger this behavior, but it has an unused zero return that could be repurposed for this, in principle. Back in 2016, OpenSSL did so in https://github.com/openssl/openssl/pull/1098 The ticket AEAD callback could, in principle, support this by successfully returning the empty string. This goes against the current documented API contract, but it accidentally worked in TLS 1.2. In TLS 1.3, it caused our servers to send a syntax error. The QUIC folks want this behavior and used to accidentally trigger the syntax error, and have switched to returning some garbage placeholder string. Between that, the new OpenSSL behavior, and it accidentally working in TLS 1.2 anyway, let's just go ahead and support this. To aid in version skew messes, this also bumps BORINGSSL_API_VERSION. Change-Id: Id4fef7b9aa552dc8e927f89a5d746bdd2247e1c6 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73028 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@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:
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: