c67a3ae6ba
BoringSSL currently retransmits non-deterministically on an internal timer (rather than one supplied externally), so the tests currently fail flakily depending on timing. Valgrind is a common source for this. We still assume an in-order and reliable channel, but drop retransmits silently: - Handshake messages may arrive with old sequence numbers. - Retransmitted CCS records arrive from the previous epoch. - We may receive a retransmitted Finished after we believe the handshake has completed. (Aside: even in a real implementation, only Finished is possible here. Even with out-of-order delivery, retransmitted or reordered messages earlier in the handshake come in under a different epoch.) Note that because DTLS renego and a Finished retransmit are ambiguous at the record layer[*], this precludes us writing tests for DTLS renego. But DTLS renego should get removed anyway. As BoringSSL currently implements renego, this ambiguity is also a source of complexity in the real implementation. (See the SSL3_MT_FINISHED check in dtls1_read_bytes.) [*] As a further fun aside, it's also complex if dispatching renego vs Finished after handshake message reassembly. The spec doesn't directly say the sequence number is reset across renegos, but it says "The first message each side transmits in /each/ handshake always has message_seq = 0". This means that such an implementation needs the handshake message reassembly logic be aware that a Finished fragment with high sequence number is NOT an out-of-order fragment for the next handshake. Change-Id: I35d13560f82bcb5eeda62f4de1571d28c818cc36 Reviewed-on: https://boringssl-review.googlesource.com/2770 Reviewed-by: Adam Langley <agl@google.com> |
||
|---|---|---|
| .. | ||
| runner | ||
| async_bio.cc | ||
| async_bio.h | ||
| bssl_shim.cc | ||
| CMakeLists.txt | ||
| malloc.cc | ||
| packeted_bio.cc | ||
| packeted_bio.h | ||
| test_config.cc | ||
| test_config.h | ||