| commit | cccf8525db8a57153d3cb3e22efed2db4b71a8ab | [log] [tgz] |
|---|---|---|
| author | Chris Vest <christianvest_hansen@apple.com> | Wed Feb 26 10:16:18 2025 -0800 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Apr 23 16:09:52 2025 -0700 |
| tree | 74a38b24b720ffe2c87b556f5ccb623c8d32e596 | |
| parent | 85145fdc914b4c01b9bb16a9253067958e327283 [diff] |
Use max_cert_list for TLSv1.3 NewSessionTicket Certificate chains are transfered to the respective peer during the TLS handshake in the ServerHello, and sometimes the ClientHello, messages. These certificate chains can be of arbitrary size due to the number of intermediary issuers, and due to the extensions within the certificates. To avoid resource exhaustion, BoringSSL limits the size of handshake messages, and rejects handshakes beyond a certain size. By default, the max message size is 16 KiB, but it can be increased with the SSL_CTX_set_cert_max_list setting. This setting allows handshakes to complete with large certificate chains. However, a new problem surfaces for TLSv1.3 sessions. In TLSv1.3, session tickets (for supporting session resumption) are sent after the handshake in NewSessionTicket messages. BoringSSL currently encode the entire peer certificate chain (and some other things) in the session ticket, which means the size of the certificate chains influence the size of the corresponding NewSessionTicket. To avoid breaking the TLS session on oversized NewSessionTicket messages, a BoringSSL server will refuse to send any NewSessionTicket that looks like it will be larger than 16 KiB. Unfortunately, this accounting is inaccurate and does not take the entire NewSessionTicket message into account. Thus, certificate chains that are a few hundred bytes smaller than 16 KiB can be accepted by a handshake when the max_cert_list setting has been increased, and by the NewSessionTicket size accounting, but then later fail on the client with an EXCESSIVE_MESSAGE_SIZE error, because ssl_max_handshake_message_len() returns the default 16 KiB, in turn because the handshake has finished and that causes it to ignore the configured max_cert_list. This patch fixes this problem by making TLSv1.3 clients keep using the max_cert_list setting post-handshake, when it is greater than the default 16 KiB. Change-Id: I17d689906a12079add4ad48b679508bc09a79f7c Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/78647 Reviewed-by: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: 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: