[gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly

[Andreas Schultz]

URL:
  <http://savannah.gnu.org/support/?108712>

                 Summary: mutiple DTLS records in one UDP packet not handled
correctly
                 Project: GnuTLS
            Submitted by: roadrunnr
            Submitted on: Tue 30 Dec 2014 02:12:06 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

under some very special circumstance, gnutls_handshake does return E_AGAIN
even when there are pending DTLS records in the buffer.

I have a CAPWAP DTLS client in GNUTLS_NONBLOCK mode, talking to a server that
insists to fragment it's packets to about 544 bytes (before CAPWAP
encapsulation). This leads to a server handshake where the last datagram
caries three DTLS records (a Certificate Fragment, a Certificate Request and
the Server Hello Done).

gnutls_handshake call's the pull func, get the full datagram, handls the
Certificate Fragment, reassembles the full certificate chain and then return
GNUTLS_E_AGAIN.
The rest of the datagram is left in the internal buffer and handled on the
next call to gnutls_handshake.

For the application there is no indication that it should or has to call
gnutls_handshake again. It's internal buffer was emptied by the pull func, no
more data will arrive and GNUTLS_E_AGAIN means "wait for more data".

Relevant lines from the debug log:

Dec 30 14:44:57.475 capwap-mitm.c:710:dtls_pull_func: 0x15e2810: DTLS pull of
size 16732

^^^^ pull empties the application buffer

gnutls[10]: READ: Got 251 bytes from 0x15e2810
gnutls[10]: READ: read 251 bytes from 0x15e2810
gnutls[10]: RB: have 0 bytes into buffer. Adding 251 bytes.

^^^^ gets the 251 bytes from the last datagram

gnutls[10]: RB: Requested 13 bytes
gnutls[5]: REC[0x160b170]: SSL 254.255 Handshake packet received. Epoch 0,
length: 145
gnutls[5]: REC[0x160b170]: Expected Packet Handshake(22)
gnutls[5]: REC[0x160b170]: Received Packet Handshake(22) with length: 145
gnutls[5]: REC[0x160b170]: Decrypted Packet[0.7] Handshake(22) with length:
145

^^^^ process the Certificate Fragemtent 158 Bytes (145 + 13 Bytes header)

gnutls[4]: HSK[0x160b170]: CERTIFICATE (11) was received. Length 2645[133],
frag offset 2500, frag length: 133, sequence: 2
gnutls[3]: ASSERT: gnutls_buffers.c:1111
gnutls[3]: ASSERT: gnutls_kx.c:630

^^^^ from here one, nothing happens on this session, gnutls_handshake returns
GNUTLS_E_AGAIN and the remaining bytes in the buffer are ignored.

I believe gnutls_handshake should continue to process the records in the
buffer.

Full debug log and sample DTLS pcap attached (needs up to date wireshark do
decode properly), full DTLS application can be found at
http://github.com/travelping/capwap-mitm





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue 30 Dec 2014 02:12:06 PM GMT  Name: capwap-dtls-handshake.pcapng 
Size: 4kB   By: roadrunnr

<http://savannah.gnu.org/support/download.php?file_id=32734>
-------------------------------------------------------
Date: Tue 30 Dec 2014 02:12:06 PM GMT  Name: capwap-dtls-handshake.log  Size:
47kB   By: roadrunnr

<http://savannah.gnu.org/support/download.php?file_id=32735>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?108712>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/