I discovered that if I establish a DTLS "connection" (with, say, s_client) and then restart my application (for example) and send some application data from the client, SSL_read() will explode with an assertion failure in 0.9.8a. Clearly, this is no good because the client can trivially take down any DTLS server just by sending the right kind of (totally acceptable) packet. It's even easy to do in ordinary circumstances.
This seems to be due to a bad assumption in d1_pkt.c that assumes only nice packets can arrive. I've worked up a patch that does _something_ to handle the error. I am completely unfamiliar with OpenSSL internals, so I presume someone else can tweak this appropriately :) My testing seems to show that my change is enough to make the server resilient to this situation. Thanks for the DTLS idea and implementation. It's just the kind of thing I was looking for! -- ---------------------------------------------------------- Brad Spencer - [EMAIL PROTECTED] - "It's quite nice..." "S.M.A.K.I.B.B.F.B." - A.J. Rimmer | http://jacknife.org/
--- ssl/d1_pkt.c~ 2005-06-05 21:32:30.000000000 -0300
+++ ssl/d1_pkt.c 2006-02-19 00:29:04.818911649 -0400
@@ -790,8 +790,14 @@
dest = s->d1->alert_fragment;
dest_len = &s->d1->alert_fragment_len;
}
- else /* else it's a CCS message */
- OPENSSL_assert(rr->type == SSL3_RT_CHANGE_CIPHER_SPEC);
+ /* else it's a CCS message, or it's 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;
+ }
if (dest_maxlen > 0)
signature.asc
Description: Digital signature
