EldoS | Feel safer!

Software components for data protection, secure storage and transfer

DTLS Client/Server problem

Also by EldoS: CallbackFilter
A component to monitor and control disk activity, track file and directory operations (create, read, write, rename etc.), alter file data, encrypt files, create virtual files.
#12381
Posted: 02/11/2010 00:06:15
by Ken Ivanov (EldoS Corp.)

I can comment them as following:

#8 - initial client hello (delivered),
#10 - hello verify request (response to #8, delivered),
#12 - repeated client hello as stated by the protocol (response to #10, lost),
#13 - initial client hello (2nd attempt to handshake, delivered),
#15 - hello verify request (response to #13, delivered),
#16 - repeated client hello (response to #15, delivered),
#17 - server hello (response to #16, delivered),
...

During DTLS negotiation (DTLS handshake) some messages can be sent several times. If the peer does not get response from remote for certain period of time, it resends the packets. This only concerns the handshake part of the protocol, the further conversation is unreliable and does not utilize this "reliability over unreliable transport" approach.
#12382
Posted: 02/11/2010 04:53:37
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Morning Innokentiy,
it's amazing, how you insist to see packet losses :) Let me tell you: There is no such a thing like packet loss :)

I'm wondering, why I achieve much better results by setting TimerValue to 3000.
http://maps.alphadex.de/eldos/image5.jpg

However, it works now. Thanks for your patience. One additional question: We are forced to do DTLS client authentication. In that scenario is it required, that the server authenicates to the client in any case? I mean: If I try to click on "listen" in the server having no cert selected, I'm getting warned to choose a cert. If server vs. client is required: Can it be the same certificate as that being used for client vs. server? I'm talking about a P2P usage, in which a node does only have one certificate, but has to act as server and client simultaneously.

And finally: I'm a bit concerned about the assertion on packet 187 (dissector bug) What might this be?

Regards
#12383
Posted: 02/11/2010 05:12:23
by Eugene Mayevski (EldoS Corp.)

Quote
neil young wrote:
it's amazing, how you insist to see packet losses :) Let me tell you: There is no such a thing like packet loss :)

I'm wondering, why I achieve much better results by setting TimerValue to 3000.


It does look like the packets are delayed somehow: they don't arrive within a second and are treated as lost. Maybe they arrive later, who knows, but from the component's point of view they are LOST. Maybe you collect them elsewhere, I don't know :).

Quote
neil young wrote:
One additional question: We are forced to do DTLS client authentication. In that scenario is it required, that the server authenicates to the client in any case? I mean: If I try to click on "listen" in the server having no cert selected, I'm getting warned to choose a cert. If server vs. client is required: Can it be the same certificate as that being used for client vs. server? I'm talking about a P2P usage, in which a node does only have one certificate, but has to act as server and client simultaneously.


You can use the same certificate for authenticating a host, which is a client and a server at the same time. However, certificate's key usage must include both client and server authentication. That is required if you properly validate certificates (or use TElCertificateValidator.ValidateForSSL method, which checks key usage).


Sincerely yours
Eugene Mayevski
#12384
Posted: 02/11/2010 05:33:48
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote
It does look like the packets are delayed somehow: they don't arrive within a second and are treated as lost. Maybe they arrive later, who knows, but from the component's point of view they are LOST. Maybe you collect them elsewhere, I don't know :).

Now I see the problem. You too? It is the granularity of the background timer, which is too unsharp with 1s. If the stacke is fed in a 1s rhythm only, it is rather likely, that a parallel 1s timer will elapse...

This must be called much faster...

private void timer_Tick(object sender, System.EventArgs e)
{
while (socket.Available > 0)
server.DataAvailable();

}


OK, end of investigation. I admit I didn't fully understand your statement:
Quote

However, certificate's key usage must include both client and server authentication. That is required if you properly validate certificates (or use TElCertificateValidator.ValidateForSSL method, which checks key usage).


Could you please elaborate for dummies?

And - is server to client authentication droppable? Or mandatory?
#12387
Posted: 02/11/2010 06:44:40
by Eugene Mayevski (EldoS Corp.)

Quote
neil young wrote:
Now I see the problem. You too? It is the granularity of the background timer, which is too unsharp with 1s. If the stacke is fed in a 1s rhythm only, it is rather likely, that a parallel 1s timer will elapse...


... the timer must be restarted after each incoming data block. So this is a user code (or sample's in our case) problem. Also, if you use the evaluation key with SecureBlackbox 7, it includes certain delays which can also cause packet drop.

Quote
neil young wrote:
Could you please elaborate for dummies?


That's a non-trivial task :).

Each certificate includes Key Usage extension, which defines, what for the certificate is allowed to be used. This key usage field can be set to client authentication and/or server authentication (among other things). When the verifying party receives the certificate, it's supposed to check whether the key usage corresponds to actual use of certificate. However, if it's you who implements certificate validation, then you can skip key usage verification.

In general, in closed systems like yours many of such checks can be skipped.

I recommend reading books and articles in the knowledgebase. They (especially the articles) explain this topic in details.

Quote
neil young wrote:
And - is server to client authentication droppable? Or mandatory?


It's possible to use anonymous cipher suites, but this makes little sense because it leaves perfect place for man-in-the-middle attacks. However everything depends on your goal.

If your goal is to create a p2p network, where the data is hidden from providers (who want to shape traffic or provide copyright control measures), then self-signed certificates on each peer are sufficient. Moreover, they are preferred, cause CA-issued certificates will disclose the origin of the data, and thus compromise privacy and safety of the node owner.


Sincerely yours
Eugene Mayevski
#12388
Posted: 02/11/2010 07:35:38
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Quote
... the timer must be restarted after each incoming data block. So this is a user code (or sample's in our case) problem. Also, if you use the evaluation key with SecureBlackbox 7, it includes certain delays which can also cause packet drop.

The timer is a cyclic timer. However, I have now removed all timer things and put the while... loop into a separate thread. This gave me a DTLS connection setup of less than 1 second !!, but the thread is consuming much processing power in it's endless loopings.

Look here, Ma: http://maps.alphadex.de/eldos/image6.jpg

So I think I'll go for asynchronous socket reception, that should do the job.

Thanks for the clarifications on certificates. So I have learned: All certs, even self signed certs need to have key usage extension, defining whether to use client and/or server authentication. But if on both ends its me, who is responsible for checking the certs, I can drop that. Correct?

After all: Is it possible to use SBB in complete "pass through"? I mean, I have to implement client/server communication using TCP and UDP, using TLS and DTLS, but wouldn't like to branch to much. Is it possible to use SBB to make plain non TLS, non DTLS socket connections? I guess, yes, just wanna make sure.

Regards
#12389
Posted: 02/11/2010 08:09:34
by Eugene Mayevski (EldoS Corp.)

Quote
neil young wrote:
So I think I'll go for asynchronous socket reception, that should do the job.


Remember to guard all calls to DTLS components with an instance of Monitor class, because the components are not designed to be called from several threads in parallel (i.e. they don't have internal guards) in order to gain higher speed.

Not using the monitor can lead to hard-to-track errors later.

Quote
neil young wrote:
But if on both ends its me, who is responsible for checking the certs, I can drop that. Correct?


Exactly. If both sides are you, certificate validation differs from normal patterns, because you can compare the certificate binary data received from the other side with the data stored in your application (for example). The articles in the knowledgebase will explain you more.

Quote
neil young wrote:
After all: Is it possible to use SBB in complete "pass through"? I mean, I have to implement client/server communication using TCP and UDP, using TLS and DTLS, but wouldn't like to branch to much. Is it possible to use SBB to make plain non TLS, non DTLS socket connections? I guess, yes, just wanna make sure.


Enabled property should turn DTLS on and off, at the same time letting you use the same interface for data sending and receiving.


Sincerely yours
Eugene Mayevski
#12390
Posted: 02/11/2010 08:28:03
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Hi Eugene,
I really appreciate your efforts to make an old man understanding the things. I just don't know, what you mean by the "Monitor". Could you please be a bit more specific?

UPDATE: Sorry, found it. Cool. Forget about it.

Quote
Enabled property should turn DTLS on and off, at the same time letting you use the same interface for data sending and receiving.

I suppose there is something similar with TLS?
Regards
#12391
Posted: 02/11/2010 08:40:16
by Eugene Mayevski (EldoS Corp.)



Sincerely yours
Eugene Mayevski
#12393
Posted: 02/11/2010 08:55:26
by neil young (Standard support level)
Joined: 11/05/2007
Posts: 96

Yeah, for those kind of locks I'm usually using the c# lock statement, which is similar I guess.
Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.

Reply

Statistics

Topic viewed 8737 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!