commit | ddecaabdc8c950d1417ed69785ac17c3400bae4c | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Thu May 13 13:53:36 2021 -0400 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Fri May 14 21:00:23 2021 +0000 |
tree | d11de0a32114a04874fc820c67a915c0e3aef26e | |
parent | a4646740ecee1190a5f0d085b4aa172311a16ad8 [diff] |
Check hs->early_session, not ssl->session, for the early data limit. ServerHello/EncryptedExtensions/Finished is logically one atomic flight that exits the early data state, we have process each message sequentially. Until we've processed Finished, we are still in the early data state and must support writing data. Individual messages *are* processed atomically, so the interesting points are before ServerHello (already tested), after ServerHello, and after EncryptedExtensions. The TLS 1.3 handshake internally clears ssl->session when processing ServerHello, so getting the early data information from ssl->session does not work. Instead, use hs->early_session, which is what other codepaths use. I've tested this with runner rather than ssl_test, so we can test both post-SH and post-EE states. ssl_test would be more self-contained, since we can directly control the API calls, but it cannot test the post-EE state. To reduce record overhead, our production implementation packs EE and Finished into the same record, which means the handshake will process the two atomically. Instead, I've tested this in runner, with a flag to partially drive the handshake before reading early data. I've also tweaked the logic to hopefully be a little clearer. Bug: chromium:1208784 Change-Id: Ia4901042419c5324054f97743bd1aac59ebf8f24 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47485 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:
There are other files in this directory which might be helpful: