| commit | 1e859054c31ec7b974e998373e85fadea56d93ad | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Sun Feb 09 16:04:58 2020 -0500 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Mar 03 17:15:15 2020 +0000 |
| tree | 8bed48d7df199b3565139339c479c99f2586ed21 | |
| parent | bfe527fa35735e8e045cbfb42b012e13ca68f9cf [diff] |
Revise QUIC encryption secret APIs. The original API separated when keys were exported to QUIC from when they were "active". This means the obligations on QUIC are unclear. For instance we added SSL_quic_read_level and SSL_quic_write_level to capture when keys were active, yet QUICHE never used them anyway. It would be better to defer releasing keys to when they are needed. In particular, we should align our API with the guidelines in https://github.com/quicwg/base-drafts/issues/3173. This means we need separate read and write callbacks, which unfortunately means the invariants around ACKs must now be covered in prose. We'll likely remove SSL_quic_read_level and SSL_quic_write_level in a later CL as QUIC has no need to know this anymore. (It should simply feed handshake data to BoringSSL as it sees it and, if we reject it, report a suitably error.) The notion of a "current" encryption level is a little odd given the interaction between 0-RTT and ServerHello..Finished ACKs. Update-Note: This is an incompatible change to SSL_QUIC_METHOD. BORINGSSL_API_VERSION can be used to distinguish the two revisions. Bug: 303 Change-Id: I6c9dca1ae156d26a80c366a4ba969dcb04e65349 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/40127 Reviewed-by: Nick Harper <nharper@google.com> Reviewed-by: Steven Valdez <svaldez@google.com> Commit-Queue: David Benjamin <davidben@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: