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

- If the server does not implement, 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
Commit-Queue: Adam Langley <>
Reviewed-by: Adam Langley <>
11 files changed
tree: de5c5e4ad3a402056321e245a142623b5dd45389
  1. .clang-format
  2. .github/
  3. .gitignore
  7. CMakeLists.txt
  15. codereview.settings
  16. crypto/
  17. decrepit/
  18. fuzz/
  19. go.mod
  20. include/
  21. sources.cmake
  22. ssl/
  23. third_party/
  24. tool/
  25. util/


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: