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>
diff --git a/ssl/internal.h b/ssl/internal.h
index ec3594c..c635583 100644
--- a/ssl/internal.h
+++ b/ssl/internal.h
@@ -2294,6 +2294,10 @@
// alert_dispatch is true there is an alert in |send_alert| to be sent.
bool alert_dispatch : 1;
+ // renegotiate_pending is whether the read half of the channel is blocked on a
+ // HelloRequest.
+ bool renegotiate_pending : 1;
+
// hs_buf is the buffer of handshake data to process.
UniquePtr<BUF_MEM> hs_buf;
