supplemental data handshake message

[Simon Josefsson]

Carolin Latze <carolin.latze at unifr.ch> writes:

> Hi again,
>
> it seems there is a mismatched between the length the sender assumes
> to send (which is the correct length) and the length the receiver is
> able to retrieve out of the buffer. The debug output on the sender
> says the following:
>
> --debug--
> server.log screenshot
> --end debug--
>
> (sorry didn't have time to capture that properly)
>
> The data is indeed 10 bytes long, which results in 14 bytes to be sent
> due to the 2 byte length and type. So, the server.log make sense to
> me. However the client does something strange:
>
> --debug--
> REC[0x954f378]: Received Packet[1] Handshake(22) with length: 14
> REC[0x954f378]: Decrypted Packet[1] Handshake(22) with length: 14
> HSK[0x954f378]: SUPPLEMENTAL was received [14 bytes]
> EXT[0x954f378]: Got supplemental type=01 length=3
> --end debug--
>
> I set the type to 1, so that makes sense as well. However... why does
> it read out a length of 3? It receives the correct packet length of 14
> bytes. It is gnutls_supplemental.c that generates the packet and
> parses it... so I would expect that it would parse it correctly. Any
> ideas or hints?

It is difficult to tell from just description of the problem...  Try
printing the entire buffer that is sent by _gnutls_gen_supplement and
the buffer received by _gnutls_parse_supplemental and hand-check that
they are correct and match.  Maybe you could push a git branch with your
work somewhere, so we can more easily reproduce the problem?

I suspect it is just a encoding/decoding bug somewhere.

/Simon