DTLS with multiple clients
Locked
 
|
Hi,
I was able to get DTLS work with the latest version of openssl with a single client and server. However, I was unable to get it to work with multiple clients. The first client completes the handshake and works well. But however the function DTLSv1_listen returns 1 immediately even for an application data packet (after the first client completes the handshake), where it should ideally return 0 and wait for the next client hello. Since it hangs on SSL_accept, the next client hello packets won't be answered. The closest reference I have got is from: https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This doesn't seem to work for multiple clients. Any suggestions/references would be helpful in this regard. If this is not the right mailing list, please point me to the right one. Thanks and Regards, Varun K S -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
Are you able to share a simple reproducer of your problem?
Matt On 05/04/18 02:14, Varun Kulkarni wrote: > Hi, > > I was able to get DTLS work with the latest version of openssl with a > single client and server. However, I was unable to get it to work with > multiple clients. The first client completes the handshake and works > well. But however the function DTLSv1_listen returns 1 immediately even > for an application data packet (after the first client completes the > handshake), where it should ideally return 0 and wait for the next > client hello. Since it hangs on SSL_accept, the next client hello > packets won't be answered. > > > The closest reference I have got is from: > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5. This > doesn't seem to work for multiple clients. > > Any suggestions/references would be helpful in this regard. If this is > not the right mailing list, please point me to the right one. > > > -- > > > Thanks and Regards, > Varun K S > > openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
Hi Matt,
I was able to fix the issue with the following changes. The change was to create new fd (bound to server address) each time DTLSv1_listen() was called. Previously, I used the same fd for every DTLSv1_listen call. The new dgram BIO was created with an old fd. On passing newly created fd to BIO_new_dgram, the problem seems to be resolved. However, this leads to another question. Why doesn't DTLS_listen queue up the connections similar to accept call? Does that mean DTLS can support only one handshake at a time? Is it recommended to create multiple fds bound to server address and then spawning a thread (per fd) to listen to DTLS requests. while(1) { int fd = socket(AF_INET6, SOCK_DGRAM, 0); bind(fd, &server_addr, sizeof(struct sockaddr_in6)); } Thanks, Varun On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <[hidden email]> wrote: Are you able to share a simple reproducer of your problem? Regards, Varun K S -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
On 05/04/18 18:53, Varun Kulkarni wrote: > Hi Matt, > > > I was able to fix the issue with the following changes. The change was > to create new fd (bound to server address) each time DTLSv1_listen() was > called. There should be no need to do that. Instead, when DTLSv1_listen returns successfully, you should create a new fd for the *client* (connected to their address as returned from DTLSv1_listen()), and then update the SSL object for the client to use that fd. You can reuse the old fd for the next DTLSv1_listen call. You will need a new SSL object for the next DTLSv1_listen() call though. Matt > Previously, I used the same fd for every DTLSv1_listen call. > The new dgram BIO was created with an old fd. On passing newly created > fd to BIO_new_dgram, the problem seems to be resolved. However, this > leads to another question. Why doesn't DTLS_listen queue up the > connections similar to accept call? Does that mean DTLS can support only > one handshake at a time? Is it recommended to create multiple fds bound > to server address and then spawning a thread (per fd) to listen to DTLS > requests. > > > > while(1) { > > int fd = socket(AF_INET6, SOCK_DGRAM, 0); > bind(fd, &server_addr, sizeof(struct sockaddr_in6)); > > > > BIO *bio = BIO_new_dgram(fd, BIO_NOCLOSE); > SSL *ssl = SSL_new(ctx); > SSL_set_bio(ssl, bio, bio); > > /* Enable cookie exchange */ > SSL_set_options(ssl, SSL_OP_COOKIE_EXCHANGE); > > /* Wait for incoming connections */ > while (!DTLSv1_listen(ssl, &client_addr)); > > /* connect to client on different fd and complete the handshake and > process data packets */ > > } > > > > > Thanks, > Varun > > > > On Thu, Apr 5, 2018 at 1:03 AM, Matt Caswell <[hidden email] > <mailto:[hidden email]>> wrote: > > Are you able to share a simple reproducer of your problem? > > Matt > > On 05/04/18 02:14, Varun Kulkarni wrote: > > Hi, > > > > I was able to get DTLS work with the latest version of openssl with a > > single client and server. However, I was unable to get it to work with > > multiple clients. The first client completes the handshake and works > > well. But however the function DTLSv1_listen returns 1 immediately > even > > for an application data packet (after the first client completes the > > handshake), where it should ideally return 0 and wait for the next > > client hello. Since it hangs on SSL_accept, the next client hello > > packets won't be answered. > > > > > > The closest reference I have got is from: > > https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5 > <https://gist.github.com/Jxck/b211a12423622fe304d2370b1f1d30d5>. This > > doesn't seem to work for multiple clients. > > > > Any suggestions/references would be helpful in this regard. If this is > > not the right mailing list, please point me to the right one. > > > > > > -- > > > > > > Thanks and Regards, > > Varun K S > > > > > -- > 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 > > openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
On Thu, Apr 5, 2018 at 3:06 PM, Matt Caswell <[hidden email]> 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. -Varun
Regards, Varun K S -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
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. 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 |
Re: DTLS with multiple clients
|
|
On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email]> wrote:
>> This is what I tried to do. But it appears that DTLSV1_listen() fails to send the Hello verify request for the second client.
Regards, Varun K S -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
In reply to this post by Matt Caswell-2
On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email]> wrote:
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. or Regards, Varun K S -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
Re: DTLS with multiple clients
|
|
On 06/04/18 00:19, Varun Kulkarni wrote: > > > On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <[hidden email] > <mailto:[hidden email]>> 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 > > openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users |
«
Return to OpenSSL - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |