| commit | 0e7dbd579b5fbb72a5175ad865844a03f74489c4 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Wed May 15 16:01:18 2019 -0400 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Oct 03 21:12:43 2019 +0000 |
| tree | de5c5e4ad3a402056321e245a142623b5dd45389 | |
| parent | f10ea55e9139d444d277cd03da519a2076e975dc [diff] |
Add an option for explicit renegotiations. Chromium's renegotiation handling currently relies on reads being the only thing that can discover a renegotiation. However, for a number of reasons, we would like to eagerly drive the read loop after a handshake: - 0-RTT + HTTP/1.1 will otherwise not pick up ServerHellos until after we send a request. In particular, if we preconnect a 0-RTT socket sufficiently in advance, such that the ServerHello comes in by the time we use it, we should send 1-RTT data rather than 0-RTT. - In TLS 1.2 False Start, if HTTP/1.1 or preconnect, we will not pick up the server Finished and NewSessionTicket until later. This way we pick it up sooner. - If the server does not implement https://boringssl-review.googlesource.com/c/boringssl/+/34948, this plugs the theoretical deadlock on the client end. The False Start and 0-RTT scenarios above also have theoretical deadlocks and cannot be mitigated on the server. - TLS 1.3 client certificate alerts interact badly with TCP reset. Eagerly reading from the socket makes it behave slightly better, though it's still not reliable unless the server defers closing the socket. So we can SSL_peek without triggering a renegotiation, add an ssl_renegotiate_explicit mode to defer processing the renegotiation. Bug: chromium:950706, chromium:958638 Change-Id: I78242d93d651b7a32a5c4c24ea9032ef63a027cf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/37944 Commit-Queue: Adam Langley <agl@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: