commit | d63435779fd2634b03976aab5f0cd13daab238a2 | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Thu Aug 15 17:29:02 2019 -0400 |
committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Tue Aug 27 23:41:41 2019 +0000 |
tree | 13b1e1a7e7c8054ffc7d5f6d16bc0d8e5cf29d09 | |
parent | 95dd54e57ff79f5440c424cbd34c781da14269e7 [diff] |
Add initial support for 0-RTT with QUIC. This adapts our existing API for QUIC, although I'm not entirely convinced the shape of it fits as it does with TCP. Things that needed to be changed: - There is a slight ordering issue on the server with HRR and releasing the 0-RTT keys to QUIC. - Remove EndOfEarlyData. - At the early return point for the server, QUIC needs to have installed the client traffic secrets earlier. - The maximum early data value is a constant in QUIC. - QUIC never installs early secrets at the TLS level. (In particular, this avoids nuisances with do_send_second_client_hello's null cipher not updating the encryption level.) - The read/write secrets for 0-RTT keys were mixed up. As the QUIC tests are getting a bit unwieldy, I tidied them up a bit. This CL does *not* handle the QUIC transport parameters or HTTP/3 server SETTINGS frame interactions with 0-RTT. That will be done in a separate CL. I suspect if we ever implement DTLS 1.3, we'll find ourselves wanting to align some of the QUIC bits here with DTLS and perhaps refine the handshake/transport abstractions a bit. Bug: 221 Change-Id: I61f701d7241dbc99e5dbf57ae6c283e10b85b049 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37145 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Steven Valdez <svaldez@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: