Note: I just subscribed to the openssl-dev mailing list, please excuse me if
this has been discussed/discovered already.
It appears that DTLS handshaking was broken in 0.9.8l due to the
no-renegotiation fix. The issue appears to be as follows.
1. When the first DTLS ClientHello is received; the server sends the
HelloVerify and sets s->new_session (in d1_srvr.c, dtls1_accept, in the
SSL3_ST_SR_CLNT_HELLO_X states)
2. When the second DTLS ClientHellos is received, the no-renegotiation check
³succeeds² and thus generates the error because s->new_session is set.
The workaround for this is to turn on
SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION.
A quick fix might be to change to check of:
if (s->new_session
&& !(s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
...
to:
if (s->enc_read_ctx
&& !(s->s3->flags & SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION))
...
Which means that the SSL state is decrypting, and thus this would be a
renegotiation, rather than an initial handshake.
An alternative fix would be to not set s->new_session in the
SSL3_ST_SRT_CLNT_HELLO_X states unless the state is about to be set to
SSL3_ST_SW_SRVR_HELLO_A. In other words, if the server moves to state
DTLS1_ST_SW_HELLO_VERIFY_REQUEST_A, do not set s->new_session.
I have not tested to see if either of these work, however.
--
-Todd Short
[email protected]
// "One if by land, two if by sea, three if by the Internet."
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
