| commit | 8acec00e9eaf4d69297a67c0c10729470b4bd764 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed May 19 13:03:34 2021 -0400 |
| committer | Adam Langley <agl@google.com> | Thu Jun 03 20:49:36 2021 +0000 |
| tree | 6fb240145e223931e36b550969158535eefeda7c | |
| parent | bc4c91ab4655d10b55427ad7d4f1ae21fe2df06b [diff] |
Manage Channel ID handshake state better. The channel_id_valid bit is both used for whether channel_id is filled in (SSL_get_tls_channel_id), and whether this particular handshake will eventually negotiate Channel ID. The former means that, if SSL_get_tls_channel_id is called on the client, we'll return all zeros. Apparently we never fill in channel_id on the client at all. The latter means the state needs to be reset on renegotiation because we do not currently forbid renegotiation with Channel ID (we probably should...), which is the last use of the init callback for extensions. Instead, split this into a bit for the handshake and a bit for the connection. Note this means we actually do not expose or even retain whether Channel ID was used on the client. This requires a tweak to the handoff logic, but it should be compatible. The serialized ssl->s3->channel_id was always a no-op: the handback happens before the ChannelID message, except in RSA key exchange. But we forbid Channel ID in RSA key exchange anyway. Update-Note: SSL_get_tls_channel_id will no longer return all zeros during the handshake or on the client. I did not find any callers relying on this. Change-Id: Icd4b78dd3f311d1c7dfc1cae7d2b86dc7e327a99 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47906 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:
There are other files in this directory which might be helpful: