Re: DTLS OpenSSL internal error, assertion failed: i == DTLS1_HM_HEADER_LENGTH
Michael Tüxen
> 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.
Are both sides communicating running 1.0.0.e or is an 0.9.8g implementation
involved?
Best regards
Michael
>
> 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><dtls-good.pcap>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List opens...@openssl.org
Automated List Manager majo...@openssl.org
Robert Story
MT> > I'm running an client/server application over DTLS, which works great
MT> > locally, but when we started testing over the net, things got a little
MT> > wacky. It appears that there is an issue somewhere with
MT> > fragmentation/reassembly. I'm getting the above assertion with 0.9.8g
MT> > and 1.0.0e, both on CentOS 5.5.
MT> Are both sides communicating running 1.0.0.e or is an 0.9.8g implementation
MT> involved?
Client is 1.0.0.e (Fedora 13), and I've built the server (CentOS 5.5)
with both, the crash happens with 0.9.8g and 1.0.0.e on the server.
Stack trace was from 1.0.0.e.
Michael Tüxen
So the problem occurs when 1.0.0 is communicating with 1.0.0, right?
Robin will look into it when he's back from vacation...
Best regards
Michael
>
> --
> Senior Software Engineer
> SPARTA (dba Cobham Analytic Soloutions)
______________________________________________________________________
Robert Story
MT> So the problem occurs when 1.0.0 is communicating with 1.0.0, right?
correct.
MT> Robin will look into it when he's back from vacation...
Ok... would that be a US-type 1-2 week vacation, or a European-type 1
month vacation? :-)
Robert Story
RS> I'm running an client/server application over DTLS, which works great
RS> locally, but when we started testing over the net, things got a little
RS> wacky. It appears that there is an issue somewhere with
RS> fragmentation/reassembly.
I was having trouble trying to get the recent DTLS patches to work with
the CentOS/RHEL rpms, so I punted and built a vanilla 1.0.0d version
from the tarball. I'm pleased to report that this problem no longer
happens. I do still get a missed packet (or something), but the server
no longer asserts, and it is only every 100 requests or so, instead of
10. I can live with that.
Robert
Michael Tüxen
> On Thu, 10 Feb 2011 23:46:49 -0500 Robert wrote:
> RS> I'm running an client/server application over DTLS, which works great
> RS> locally, but when we started testing over the net, things got a little
> RS> wacky. It appears that there is an issue somewhere with
> RS> fragmentation/reassembly.
>
> I was having trouble trying to get the recent DTLS patches to work with
> the CentOS/RHEL rpms, so I punted and built a vanilla 1.0.0d version
> from the tarball. I'm pleased to report that this problem no longer
> happens. I do still get a missed packet (or something), but the server
> no longer asserts, and it is only every 100 requests or so, instead of
> 10. I can live with that.
Hi Robert,
I assume with 'recent DTLS patches' you refer to the ones Robin has
posted today.
Could you elaborate a bit more on the problem you are still experiencing.
If possible, I would prefer that Robin tries to nail it down and fix it,
even if you can life with it.
Best regards
Michael
>
>
> Robert
>
> --
> Senior Software Engineer
> SPARTA (dba Cobham Analytic Soloutions)
______________________________________________________________________
Robert Story
MT> > I was having trouble trying to get the recent DTLS patches to work with
MT> > the CentOS/RHEL rpms, so I punted and built a vanilla 1.0.0d version
MT> > from the tarball. I'm pleased to report that this problem no longer
MT> > happens. I do still get a missed packet (or something), but the server
MT> > no longer asserts, and it is only every 100 requests or so, instead of
MT> > 10. I can live with that.
MT>
MT> I assume with 'recent DTLS patches' you refer to the ones Robin has
MT> posted today.
It was last night for me, but yes.
MT> Could you elaborate a bit more on the problem you are still experiencing.
MT> If possible, I would prefer that Robin tries to nail it down and fix it,
MT> even if you can life with it.
Sure. I've now got 1.0.0d from the openssl tarball on the server side,
and openssl-1.0.0b-1.fc13.i686 on the client side. I fired up wireshark
on my local machine (the client) to see what was going on.
I've seen three scenarios so far:
> Client Hello Seq# 0
> Client Hello Seq# 1
> Client Hello Seq# 2
> Client Hello Seq# 0
> Client Hello Seq# 1
< Server Hello Seq# 6
> Client Hello Seq# 2
< Server Hello Seq# 12
> Client Hello Seq# 0
> Client Hello Seq# 1
< Server Hello Seq# 0
> Client Hello Seq# 2
< Server Hello Seq# 6
This happens with or without today's patches applied on the server
side. I haven't tried using the 1.0.0d tarball on the client side.
Michael Tüxen
Hi Robert,
how do you get the client to send these sequence numbers? The same for the server?
I don't understand how you get things into these states...
We need more information... Maybe you can send us (privately) a Wireshark trace
and describe how we can reproduce the problem.
Best regards
Michael
>
>
> This happens with or without today's patches applied on the server
> side. I haven't tried using the 1.0.0d tarball on the client side.
>
>
> Robert
>
> --
> Senior Software Engineer
> SPARTA (dba Cobham Analytic Soloutions)
______________________________________________________________________
Robin Seggelmann
On Feb 24, 2011, at 9:34 PM, Robert Story wrote:
> This happens with or without today's patches applied on the server
> side. I haven't tried using the 1.0.0d tarball on the client side.
Please try using a patched 1.0.0d tarball on both sides.
What do you mean by a packet is "missing"? Is there packet loss on the network or is DTLS discarding a message? And what is the result? Is there a retransmission and the handshake continues or does the handshake fail?
Best regards
Robin
Robert Story
RS> Please try using a patched 1.0.0d tarball on both sides.
Ok, I'll try to get that this weekend or Monday.
RS> What do you mean by a packet is "missing"? Is there packet loss on the
RS> network or is DTLS discarding a message? And what is the result?
I'm not sure, since I've just been running wireshark on the client
side. I'll try to get a dump from both sides. Obviously in some cases
DTLS is getting the message, since it is responding with a ServerHello
(albeit with the wrong sequence number).
RS> Is there a retransmission and the handshake continues or does the
RS> handshake fail?
The ClientHello is always sent three times, and the handshake fails.
Michael Tüxen
> On Fri, 25 Feb 2011 11:54:53 +0100 Robin wrote:
> RS> Please try using a patched 1.0.0d tarball on both sides.
>
> Ok, I'll try to get that this weekend or Monday.
>
> RS> What do you mean by a packet is "missing"? Is there packet loss on the
> RS> network or is DTLS discarding a message? And what is the result?
>
> I'm not sure, since I've just been running wireshark on the client
> side. I'll try to get a dump from both sides. Obviously in some cases
> DTLS is getting the message, since it is responding with a ServerHello
> (albeit with the wrong sequence number).
Hi Robert,
are you trying to establish multiple DTLS connections at the same
time? Or just one after the other? Is there some traffic load on
the server?
>
> RS> Is there a retransmission and the handshake continues or does the
> RS> handshake fail?
>
> The ClientHello is always sent three times, and the handshake fails.
It looks like the ClientHellos are just retransmissions. The
same could be the the ServerHellos. It would make sense, the
the Certificate message needs to be fragmented.
It would be helpful to have .pcap files from both sides and no
packet drops reported from libpcap.
Best regards
Michael
>
>
> Robert
>
> --
> Senior Software Engineer
> SPARTA (dba Cobham Analytic Soloutions)
______________________________________________________________________
Robert Story
MT> > Sure. I've now got 1.0.0d from the openssl tarball on the server side,
MT> > and openssl-1.0.0b-1.fc13.i686 on the client side. I fired up wireshark
MT> > on my local machine (the client) to see what was going on.
MT> >
MT> > I've seen three scenarios so far:
MT> >
MT> > > Client Hello Seq# 0
MT> > > Client Hello Seq# 1
MT> > > Client Hello Seq# 2
MT> >
MT> > > Client Hello Seq# 0
MT> > > Client Hello Seq# 1
MT> > < Server Hello Seq# 6
MT> > > Client Hello Seq# 2
MT> > < Server Hello Seq# 12
MT> >
MT> > > Client Hello Seq# 0
MT> > > Client Hello Seq# 1
MT> > < Server Hello Seq# 0
MT> > > Client Hello Seq# 2
MT> > < Server Hello Seq# 6
MT>
MT> how do you get the client to send these sequence numbers? The same for the server?
I'm not doing anything. I'm just reporting the numbers I'm seeing via
wireshark. The server is long running, but the client is run fresh from
the command line eash time, so a sequence number of 0 makes sense.
MT> I don't understand how you get things into these states...
MT> Maybe you can send us (privately) a Wireshark trace
sure.
--
Robert Story
MT> are you trying to establish multiple DTLS connections at the same
MT> time? Or just one after the other? Is there some traffic load on
MT> the server?
My testing is a shell script which loops, calling an app to send a
query, then sleeping 1-2 seconds. So it's the same request
repeatedly. There is no traffic load on the client or server machine.
Both are recent multi-core machines with plenty of memory.
MT> > RS> Is there a retransmission and the handshake continues or does the
MT> > RS> handshake fail?
MT> >
MT> > The ClientHello is always sent three times, and the handshake fails.
MT> It looks like the ClientHellos are just retransmissions. The
MT> same could be the the ServerHellos. It would make sense, the
MT> the Certificate message needs to be fragmented.
MT>
MT> It would be helpful to have .pcap files from both sides and no
MT> packet drops reported from libpcap.
sent off-list.. tshark didn't report any packet drops.