tree de5c5e4ad3a402056321e245a142623b5dd45389
parent f10ea55e9139d444d277cd03da519a2076e975dc
author David Benjamin <davidben@google.com> 1557950478 -0400
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1570137163 +0000

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>