44d3eed2bb
The only case where renego is supported is if we are a client and the server sends a HelloRequest. That is still needed to support the renego + client auth hack in Chrome. Beyond that, no other forms of renego will work. The messy logic where the handshake loop is repurposed to send HelloRequest and the extremely confusing tri-state s->renegotiate (which makes SSL_renegotiate_pending a lie during the initial handshake as a server) are now gone. The next change will further simplify things by removing ssl->s3->renegotiate and the renego deferral logic. There's also some server-only renegotiation checks that can go now. Also clean up ssl3_read_bytes' HelloRequest handling. The old logic relied on the handshake state machine to reject bad HelloRequests which... actually that code probably lets you initiate renego by sending the first four bytes of a ServerHello and expecting the peer to read it later. BUG=429450 Change-Id: Ie0f87d0c2b94e13811fe8e22e810ab2ffc8efa6c Reviewed-on: https://boringssl-review.googlesource.com/4824 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| crypto | ||
| decrepit | ||
| doc | ||
| include/openssl | ||
| ssl | ||
| tool | ||
| util | ||
| .clang-format | ||
| .gitignore | ||
| BUILDING | ||
| CMakeLists.txt | ||
| codereview.settings | ||
| LICENSE | ||
| STYLE | ||