Hello, I'm running an client/server application over DTLS, which works great locally, but when we started testing over the net, things got a little wacky. It appears that there is an issue somewhere with fragmentation/reassembly. I'm getting the above assertion with 0.9.8g and 1.0.0e, both on CentOS 5.5.
The problem is intermittent, but easy for me to reproduce. Generally within 10 exchanges this assert will be hit. I've looked at the packets with wireshark, and there is an initial reassembled packet that appears to get dropped, and then several resend which are exactly 82 bytes shorter than the initial packet (and the packet size of the first 10 or so requests that do not trigger this assert). It would be great if I could get a patch that would gracefully handle this, instead of asserting. The last thing we need is a remote DOS attack against our application. I've attached pcaps for a successful exchange between the client and server, and one which triggered the assert. Here is the debug output from our app: dtlsudp: received 3414 raw bytes on way to dtls tls_x509:verify: verify_callback called with: ok=1 ctx=0x7fffffffdda0 depth=1 err=0:ok tls_x509:verify: verify_callback called with: ok=1 ctx=0x7fffffffdda0 depth=0 err=0:ok tls_x509:verify: returning the passed in value of 1 ---- OpenSSL Related Errors: ---- TLS error: SSL_read: rc=-1, sslerror = 1 (SSL_ERROR_SSL) TLS Error: bad decompression error: #336601317 (file d1_pkt.c, line 751) ---- End of OpenSSL Errors ---- dtlsudp: received -1 decoded bytes from dtls ---- OpenSSL Related Errors: ---- TLS error: SSL_read: rc=-1, sslerror = 5 (SSL_ERROR_SYSCALL): system_error=0 (Success) TLS Error: (null) dtlsudp: netsnmp_dtlsudp_recv(): transports/snmpDTLSUDPDomain.c, 509: dtlsudp: received 3414 raw bytes on way to dtls d1_both.c(663): OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH So it looks like it gets the same reassembled fragment twice (dtlsudp: received 3414 raw bytes on way to dtls), and it chokes on the second one. On the good packets, the packet size is 3496 bytes. Here's the stack trace (openssl-1.0.0.e): Program received signal SIGABRT, Aborted. 0x00000033d2430265 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000033d2430265 in raise () from /lib64/libc.so.6 #1 0x00000033d2431d10 in abort () from /lib64/libc.so.6 #2 0x00002aaaaad8143e in OpenSSLDie (file=0x2aaaaab0f768 "d1_both.c", line=663, assertion=0x2aaaaab0f81c "i == DTLS1_HM_HEADER_LENGTH") at cryptlib.c:877 #3 0x00002aaaaaaf5bcf in dtls1_get_message_fragment (s=0x808fc0, st1=8640, stn=8641, max=64, ok=0x7fffffffdf34) at d1_both.c:663 #4 0x00002aaaaaaf5210 in dtls1_get_message (s=0x808fc0, st1=8640, stn=8641, mt=20, max=64, ok=0x7fffffffdf34) at d1_both.c:393 #5 0x00002aaaaaae379a in ssl3_get_finished (s=0x808fc0, a=8640, b=8641) at s3_both.c:215 #6 0x00002aaaaaaecad4 in dtls1_accept (s=0x808fc0) at d1_srvr.c:536 #7 0x00002aaaaaaf2d3f in dtls1_read_bytes (s=0x808fc0, type=23, buf=0x7e82c0 "\026\376\377", len=65536, peek=0) at d1_pkt.c:747 #8 0x00002aaaaaade96f in ssl3_read_internal (s=0x808fc0, buf=0x7e82c0, len=65536, peek=0) at s3_lib.c:3265 #9 0x00002aaaaaadea1c in ssl3_read (s=0x808fc0, buf=0x7e82c0, len=65536) at s3_lib.c:3285 #10 0x00002aaaaaaf91ea in SSL_read (s=0x808fc0, buf=0x7e82c0, num=65536) at ssl_lib.c:954 [...] Robert -- Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions)
dtls-bad.pcap
Description: Binary data
dtls-good.pcap
Description: Binary data
signature.asc
Description: PGP signature
