[openssl-users] DTLS with multiple clients

[Matt Caswell]

On 06/04/18 00:19, Varun Kulkarni wrote:
> 
> 
> On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 05/04/18 23:37, Varun Kulkarni wrote:
> 
>     >
>     > Thanks for the reply Matt. Previosuly , I did the exact thing you
>     > mentioned. But in that case , the DTLSV1_listen returns succesfully (>
>     > 0) immediately on reception of
>     > app packet and hangs on SSL_accept.
>     >
>     > Here is tshark trace of the same:
>     >
>     >     1 0.000000000    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >     2 0.000136330    127.0.0.1 → 127.0.0.1    DTLSv1.0 90 Hello Verify
>     > Request
>     >     3 0.000258998    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     >     4 0.999217798    127.0.0.1 → 127.0.0.1    DTLSv1.0 264 Client Hello
>     >     5 1.001095034    127.0.0.1 → 127.0.0.1    DTLSv1.0 1482 Server
>     > Hello, Certificate, Server Key Exchange, Certificate Request, Server
>     > Hello Done
>     >     6 1.003771485    127.0.0.1 → 127.0.0.1    DTLSv1.0 1457 Certificate,
>     > Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted
>     > Handshake Message
>     >     7 1.004282757    127.0.0.1 → 127.0.0.1    DTLSv1.0 1252 New Session
>     > Ticket, Change Cipher Spec, Encrypted Handshake Message
>     >     8 4.313854533    127.0.0.1 → 127.0.0.1    DTLSv1.0 103 Application Data
>     >     9 4.314110117    127.0.0.1 → 127.0.0.1    DTLSv1.0 295 Application
>     > Data   
>     >  * 10 31.662557986    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello*
>     >    11 32.662344551    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    12 34.665481449    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    13 38.662321433    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    14 46.662998247    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >    15 62.662816876    127.0.0.1 → 127.0.0.1    SSL 244 Client Hello
>     >
>     > The trace starting from 10 is from the second client and it hangs
>     > because DTLSv1_listen has already returned and is struck on SSL_accept.
>     >
>     > Can you clarify that at any moment of time, dtls can process only one
>     > handshake at a time. 
> 
>     For any single thread that is true. It is self evident that in a single
>     thread you can only do one thing at a time. But plenty of applications
>     still manage to handle multiple simultaneous clients! There are two
>     general ways that applications solve this problem.
> 
>     1) Have one thread for DTLSv1_listen. When a client connects offload the
>     SSL_accept call to some other thread. In the first thread you can loop
>     around and call DTLSv1_listen again while, at the same time, the second
>     thread can process the handshake with the connected client.
> 
> 
>  This is what I tried to do. But it appears that DTLSV1_listen() fails
> to send
>  the Hello verify request for the second client (Refer trace above). But
> If I recreate the fd
>  every time in the thread, it works as expected.

This code is quite old now and some things have moved on a bit in terms
of the OpenSSL API, but take a look at the sample code here:

https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c

This might give you some hints about how to tackle the problem.

Matt



> 
>     or
> 
>     2) Interleave processing of different clients and DTLSv1_listen within
>     the same thread. Usually on some event driven process (e.g. select,
>     poll, epoll, libevent etc). So in this case you set the underlying fd to
>     be non-blocking and then handle the
>     SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from
>     OpenSSL (see man page for SSL_get_error).
> 
>     Matt
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 
> -- 
> 
> 
> Regards,
> Varun K S
> 
>