EldoS | Feel safer!

Software components for data protection, secure storage and transfer

DTLS Client/Server problem

Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.
#12367
Posted: 02/10/2010 07:54:10
by Ken Ivanov (EldoS Corp.)

Quote
It shows the merged screenshots of the client (above) and the server (below). The clocks of both machines have been synchronized before the attempt was made.
It shows the initial connection establishment delay very clear.

The server fires OnOpenConnection once it has sent the [first instance of] TLS Finished packet to the client. The client fires OnOpenConnection once it has received and processed the Finished packet. Obviously, one or more instances of the Finished packet are lost, so the client has to wait for the server to re-send it.

I suggest you to set up the tracing as I explained above and check which packets are actually received.
#12368
Posted: 02/10/2010 08:02:21
by Ken Ivanov (EldoS Corp.)

I am attaching the commented pcap trace you have provided.


#12369
Posted: 02/10/2010 08:21:22
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Thanks for your efforts, but some information:

1) Version 7 shows exactly the same behavior. This makes your claim ("Packet loss") at least possible

2) The Wireshark trace has been taken on the server side. I don't want to comment all the "Losts", but how can packet 3 be lost, if it is traced by the server?

I will take this as an impulse to trace both sides now. Come back to you soon with Wireshark traces from client AND server AND version 7.

Regards
#12370
Posted: 02/10/2010 08:42:53
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

OK, I have uploaded the screenshots of the two wireshark traces, one taken at server, one at client side. For me there is NO SINGLE PACKET LOST, but I'm not the expert here. You can get the raw traces, whenever you want to have that.

Again: Version 7 on both side, latest download (freshly taken), UNCHANGED DTLS client/server sample code, evaluation license, both machines XP SP 3.

For me this simply doesn't work. I'll now go and add some traces, as you suggested.

http://maps.alphadex.de/eldos/images3.zip

Let me know.
#12371
Posted: 02/10/2010 08:54:45
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

I have added the traces as suggested to receive and send on both sides. The log window is full of "Received xx bytes" and "Send xx bytes" on both machines, so it reflects exactly the endless back and forth seen in Wireshark.

The question remains: Why do both sides not understand each other?

Regards
#12372
Posted: 02/10/2010 09:31:08
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

I believe one of the key sequences is buried in packets 4 and 5: Why does the client fire a second "Client Hello" in packed 5, just 300 ms after the first (which contains the cookie, btw). Timeouts are not changed, so it should at least wait for a second. The client definitly jabbers to much.

I have set TimerValue to be 5000 client and server, than both ends come together. But is this really supposed to work that way?

Regards
#12373
Posted: 02/10/2010 09:35:06
by Ken Ivanov (EldoS Corp.)

Got it. There is a bug in the sample applications. Please replace the implementation of the timer_Tick() handler (in both samples) with the following code:
Code
private void timer_Tick(object sender, System.EventArgs e)
{
    while (socket.Available > 0)
    {
        client.DataAvailable();
    }
}
#12374
Posted: 02/10/2010 10:15:53
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hmm, seems to work, but not really. This was probably a bug. Don't forget to change the client.DataAvailable() above to server.DataAvailable() for the server side. But the main problem remains: The client is still firing too fast. There are still some extra rounds, not necessary, because the client is not waiting long enough for the server. I had the best results with a timeout of 5 seconds, but I doubt, that this is by intention....

http://maps.alphadex.de/eldos/images4.jpg has the picture

Regards
#12375
Posted: 02/10/2010 10:51:36
by Ken Ivanov (EldoS Corp.)

Sorry, the server returns 404 by the link above.

Actually, I understood what you are answering about. According to DTLS specification, client hello packet is sent twice. This is done intentionally to prevent client substitution (as you may notice in the pcap log, the server sends so-called hello-verify-request message, asking a client to repeat the client-hello packet).

This feature is optional, you can turn it off using the TElDTLSServer.UseClientVerification property.

Quote
There are still some extra rounds, not necessary, because the client is not waiting long enough for the server. I had the best results with a timeout of 5 seconds, but I doubt, that this is by intention....

SBB uses the timeout of 1 second, as recommended by the DTLS specification. Depending on the particular environment, the optimal timeout value might differ.
#12376
Posted: 02/10/2010 11:35:02
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Sorry, the link was slightly wrong http://maps.alphadex.de/eldos/image4.jpg

Quote
According to DTLS specification, client hello packet is sent twice.

Twice in a row? Without waiting for an answer in between? What sense does that give? Look for packets #12 and #13. What is #13 good for?

And I don't catch, why the server has to send the certificate 3 times. This can't be OK, it looks rather insane.

Regards
Also by EldoS: Solid File System
A virtual file system that offers a feature-rich storage for application documents and data with built-in compression and encryption.

Reply

Statistics

Topic viewed 8731 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!