13e81fc971
Although the DTLS transport layer logic drops failed writes on the floor, it is actually set up to work correctly. If an SSL_write fails at the transport, dropping the buffer is fine. Arguably it works better than in TLS because we don't have the weird "half-committed to data" behavior. Likewise, the handshake keeps track of how far its gotten and resumes the message at the right point. This broke when the buffering logic was rewritten because I didn't understand what the DTLS code was doing. The one thing that doesn't work as one might expect is non-fatal write errors during rexmit are not recoverable. The next timeout must fire before we try again. This code is quite badly sprinkled in here, so add tests to guard it against future turbulence. Because of the rexmit issues, the tests need some hacks around calls which may trigger them. It also changes the Go DTLS implementation from being completely strict about sequence numbers to only requiring they be monotonic. The tests also revealed another bug. This one seems to be upstream's fault, not mine. The logic to reset the handshake hash on the second ClientHello (in the HelloVerifyRequest case) was a little overenthusiastic and breaks if the ClientHello took multiple tries to send. Change-Id: I9b38b93fff7ae62faf8e36c4beaf848850b3f4b9 Reviewed-on: https://boringssl-review.googlesource.com/6417 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| .. | ||
| openssl | ||