Hey folks,
We found a small DTLS bug while writing some tests. I think it affects
1.0.1 and 1.0.2 too, so I thought I'd send you a note. (Note sure about
master. I'm unfamiliar with the new state machine mechanism.)
In DTLS, each ClientHello is supposed to reset the handshake hash (in case
of HelloVerifyRequest). The old state machine calls ssl3_init_finished_mac
in the SSL3_ST_CW_CLNT_HELLO_* states.
https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=ssl/d1_clnt.c;h=feeaf6d0656f5d0868121852d42b5037b8823111;hb=refs/heads/OpenSSL_1_0_2-stable#l317
If the ClientHello is fragmented and takes multiple iterations to write,
the state machine is re-entered in SSL3_ST_CW_CLNT_HELLO_B, which
calls ssl3_init_finished_mac again, and clobbers what was sampled to the
handshake hash/buffer previously.
This requires the transport return a retriable error on write, which
probably isn't common for DTLS. It came up because WebRTC uses a custom BIO
with a fixed-size buffer, so it can actually do this. Even then, a
ClientHello is unlikely to fill up the buffer. Our tests repro'd it in
BoringSSL by forcing every write to take two iterations.
David
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
