0ab3f0ca25
Mono's legacy TLS 1.0 stack, as a server, does not implement any form of resumption, but blindly echos the ClientHello session ID in the ServerHello for no particularly good reason. This is invalid, but due to quirks of how our client checked session ID equality, we only noticed on the second connection, rather than the first. Flaky failures do no one any good, so break deterministically on the first connection, when we realize something strange is going on. Bug: chromium:796910 Change-Id: I1f255e915fcdffeafb80be481f6c0acb3c628846 Reviewed-on: https://boringssl-review.googlesource.com/25424 Commit-Queue: Steven Valdez <svaldez@google.com> CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> Reviewed-by: Steven Valdez <svaldez@google.com> |
||
---|---|---|
.. | ||
test | ||
bio_ssl.cc | ||
CMakeLists.txt | ||
custom_extensions.cc | ||
d1_both.cc | ||
d1_lib.cc | ||
d1_pkt.cc | ||
d1_srtp.cc | ||
dtls_method.cc | ||
dtls_record.cc | ||
handshake_client.cc | ||
handshake_server.cc | ||
handshake.cc | ||
internal.h | ||
s3_both.cc | ||
s3_lib.cc | ||
s3_pkt.cc | ||
span_test.cc | ||
ssl_aead_ctx.cc | ||
ssl_asn1.cc | ||
ssl_buffer.cc | ||
ssl_cert.cc | ||
ssl_cipher.cc | ||
ssl_file.cc | ||
ssl_key_share.cc | ||
ssl_lib.cc | ||
ssl_privkey.cc | ||
ssl_session.cc | ||
ssl_stat.cc | ||
ssl_test.cc | ||
ssl_transcript.cc | ||
ssl_versions.cc | ||
ssl_x509.cc | ||
t1_enc.cc | ||
t1_lib.cc | ||
tls13_both.cc | ||
tls13_client.cc | ||
tls13_enc.cc | ||
tls13_server.cc | ||
tls_method.cc | ||
tls_record.cc |