The current DTLS implementation always generates an
SSL_R_UNEXPECTED_RECORD error if application data is received while
handshaking. This is ok for the first handshake, but not necessary
for renegotiations. Furthermore it's likely that the connection fails
just because of unordered UDP packets. The DTLS specification does
not mention this issue, but there is no reason not to accept belated
application data while renegotiating, as long as the key material has
not changed yet. With this patch the implementation will leave the
handshake routine, return the application data and generate the error
SSL_ERROR_WANT_READ, so that the application reads again to continue
handshaking.
--- d1_pkt.c~ 2008-09-14 19:57:03.000000000 +0200
+++ d1_pkt.c 2008-11-11 09:40:52.000000000 +0100
@@ -795,13 +827,27 @@
dest = s->d1->alert_fragment;
dest_len = &s->d1->alert_fragment_len;
}
- /* else it's a CCS message, or it's wrong */
+ /* else it's a CCS message, or application data or
wrong */
else if (rr->type != SSL3_RT_CHANGE_CIPHER_SPEC)
{
- /* Not certain if this is the right error
handling */
- al=SSL_AD_UNEXPECTED_MESSAGE;
- SSLerr
(SSL_F_DTLS1_READ_BYTES,SSL_R_UNEXPECTED_RECORD);
- goto f_err;
+ /* Application data
while renegotiating
+ * is allowed. Try
again reading.
+ */
+ if (rr->type ==
SSL3_RT_APPLICATION_DATA)
+ {
+ s->s3-
>in_read_app_data=2;
+ BIO *bio;
+
bio=SSL_get_rbio(s);
+ s-
>rwstate=SSL_READING;
+
BIO_clear_retry_flags(bio);
+
BIO_set_retry_read(bio);
+ return(-1);
+ }
+
+ /* Not certain if this is the right error
handling */
+ al=SSL_AD_UNEXPECTED_MESSAGE;
+ SSLerr
(SSL_F_DTLS1_READ_BYTES,SSL_R_UNEXPECTED_RECORD);
+ goto f_err;
}
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
