| commit | e6b800f90bbdaf57b565db2ce3fd5782df2d7366 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <[email protected]> | Mon Nov 11 17:31:41 2024 -0500 |
| committer | Boringssl LUCI CQ <[email protected]> | Tue Nov 12 23:34:45 2024 +0000 |
| tree | c4788fb95b1c070ca1dbc7cf749c462ec094393b | |
| parent | 0c3c42784edb5fddb7673998727746fe177df090 [diff] |
Track SSL session types a bit better on the client A session could be offered in one of three fields: - The TLS 1.2 session ID - The TLS 1.2 session ticket extension - The TLS 1.3 PSK extension We didn't quite keep track of which kind we had. In particular: - We are not willing to send TLS 1.2 session tickets if SSL_OP_NO_TICKET is set. However, if we were configured with a ticket session AND enabled TLS 1.3, we'd send a non-empty session ID. If the server echo'd the session ID anyway, we'd get confused and think the session was being resumed. There's no real practical consequence to this, but we should reject this. - If we somehow constructed a TLS 1.3 session with ID but no ticket, we would think it was an ID session and offer the session ID after the cleanup in https://boringssl-review.googlesource.com/c/boringssl/+/69947. We'd also send a PSK extension with an empty PSK field, and then even allow the server to resume it. This isn't completely absurd (except that PSK identities cannot be empty), but offering the session ID would trip QUIC up. This case should be impossible... but before the bug fixed in I1651e7887f9611ebc44ac54af89c85bf86a9feff, this was actually reachable. There's no practical consequence, but we should reject this at a better place. - The code to decide whether the server could send pre_shared_key in ServerHello just checked for any session at all, even a TLS 1.2 session. This has no practical consequence because we'll just catch it later, but may as well fix this. Fix this by adding a function to classify the SSL_SESSION and then catch on that throughout. Change-Id: I26a721b7c473d08525217e4ab1d0d341d651dfcb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/73008 Reviewed-by: Adam Langley <[email protected]> Commit-Queue: David Benjamin <[email protected]>
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: