[openssl-users] DTLS with multiple clients

Thu Apr 5 22:37:01 UTC 2018

On Thu, Apr 5, 2018 at 3:06 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> 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
>

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

>
> >  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 <matt at openssl.org
> > <mailto:matt at openssl.org>> 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
>

-- 

Regards,
Varun K S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180405/b281ae4e/attachment.html>