[gnutls-devel] handshake packet re-ordering issue during encrypted handshake

[Guillaume Roguez]

> On Fri, 2016-06-03 at 15:43 -0400, Guillaume Roguez wrote:
>> Hi,
>> 
>> Using gnutls 3.4.12, I'm trying to implement an encrypted and
>> authenticated UDP channel using DTLS.
>> To not send the certificate in clear during the handshake, I'm doing
>> a double hanshake, starting
>> with an anonymous credential session, then forcing a re-handshake
>> using a certified credential session.
>> 
>> My in-production code was worked well... until some users complain
>> about the certified handshake not working.
>> After investigation I've found that the packet containing (completely
>> or partially) the client certificate is
>> shift in time at server side.
>> This packet is encryted as it's inside anonymous session, quite big
>> (all allowed bytes used = MTU size)
>> and re-ordered by the network.
> 
> Hi,
> Could you modify tests/mini-dtls-rehandshake.c to do the same re-
> ordering so that I can reproduce and also include it in the test suite?
> 

For sure, I'm joining a patch to modify this test (also utils to permit
extra arguments). It must be applied inside tests/ directory.
Notice you need to give CA, certificate and key as arguments for x509
authentification.

The patch gives a working version, uncomment the line:

//#define DO_PACKET_REORDERING 1

to obtain a version with a simulation of packet re-ordering.
The second handshake will never success.

>> To not enter into a complex code (our product is https://ring.cx),
>> I've written a simple client/server working on GNU/Linux
>> based from samples found in gnutls documentation, added a bit of code
>> to do the double handshake
>> and simulate the packet re-ordering by swapping the first big packet
>> with the next one (only in server code).
>> Questions: What am I doing wrong? In this case, what's the good way
>> to implement my anonymous certificate exchange?
> 
> I'll have to check the debugging output on what's wrong. There are
> several tests for re-orders and lost packets (tests/dtls/dtls) but it
> may be that a corner case is not covered (the issue may also depend on
> packet size). The best would be to have an easy to use reproducer in
> order for me to check it.
> 
> regards,
> Nikos

Thanks,
Guillaume
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reordering_patch
Type: text/x-patch
Size: 5450 bytes
Desc: not available
URL: </pipermail/attachments/20160606/33986e94/attachment.bin>