Re: DTLS over UDP

[Nivedita <maddi.nivedita@xxxxxxxxx>]

Hi Michael,

Would you please let me  know whether this  new release of openssl-1.1.1-pre3  supports DTLS over udp for SIP protocol using dtlsv1_accept method.

Regards,

Nivedita

On Wed, Feb 21, 2018 at 11:54 AM, Nivedita <maddi.nivedita@xxxxxxxxx> wrote:

Hi Michael,

Please find the response inline and also i have attached the pcap for your reference.

ip.src ="" is the search criteria for pcap dump.

Regards,

Nivedita

On Tue, Feb 20, 2018 at 12:13 AM, Michael Richardson <mcr@xxxxxxxxxxxx> wrote:

Nivedita <maddi.nivedita@xxxxxxxxx> wrote:
    >> Nivedita <maddi.nivedita@xxxxxxxxx> wrote:

    >>> I am trying to establish DTLS over UDP connection by using
    >>> DTLSv1_listen method .

    >>> I have followed the below steps - 1. Created a server socket
    >>> and using
    >>> this socket created bio and ssl object. bio =
    >>> BIO_new_dgram(VI_sock,BIO_NOCLOSE)) SSL_set_bio
    >>> (ssl,VP_bio,VP_bio);

    >>> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl,
    >>> SSL_OP_COOKIE_EXCHANGE);

    >>> 3. Then started listening using dtlsv1_listen for the new
    >>> client
    >>> connections. Once dtlsv1_listen is successful and i got the
    >>> peer
    >>> address.

    mcr> okay.


    >> Nivedita- All the above mentioned steps i am doing on server
    >> side . On the
    >> client side i have already initiated ssl_connect.
    >> On the server side when i am listening using dtlsv1_listen
    >> method -

    >>> 4. Once i got the peer address , i am creating one more socket
    >>> 5. With the new socket i tried to connect to peer address.

   >> Then once i got the client address from the dtlsv1_listen method,
    >> i am creating one more socket and trying to connect to this client
     >> address.

>I think that I see what is wrong with your flow... you haven't taken the
>packet off the original socket, so SSL_accept is still looking for it.

>The flow is supposed to be:
   >  1) client sends ClientHello

   Nivedita-  Client is sending the client hello.    

 

     >2) DTLSv1_listen() sees it, and sends a HelloVerifyRequest
       > (I assume you have filled in the cookie callbacks. I think that
       > perhaps there should be good cryptographic defaults available in
        >the library.  Maybe there are, and I'm ignorant of them)

       Nivedita-  Yes, I have attached all the cookies  and server is responding with hello verify request. 

 

 >   3) Client sends ClientHello w/cookie.
 >    DTLSv1_listen() then sees that and tweaks the SSL* to indicate that
 >     the cookie has been accepted.  Note that the packet is *LEFT*
 >      on the incoming socket so that SSL_accept() can process it.
  >     This is one the places where the DTLSv1_listen() API is rather
  >      hard to use in my opinion.

   Nivedita-     Now after Hello verify request is done, client sends the client hello with cookie.

                      Now i have done SSL_accept on the same server socket.[ means the same socket on which dtlsv1_listen was triggered] 

>    4) You make up new sockets, etc.

      Nivedita-         After ssl_accept is done , i have created one more socket, and tried to connect to client addr and set the bio on the new socket.   

     

               VI_sock_id = socket(client_addr.ss_family,SOCK_DGRAM,0);

 

               VI_status = connect(VI_sock_id, (struct sockaddr *)&client_addr,  sizeof(struct sockaddr_storage));

 

 

>  5) But, you need to call SSL_accept() once with the **old socket** to
>      process packet that listen() left on it, and then you can switch the
>       FD over!  Of course, you probably want to make sure that SSL_accept()
>      sends the reply correctly.

    Nivedita-   As suggested i have done the ssl_accept on the same socket on which dtlsv1_listen was triggered. 

                    After ssl_accept i am trying to change the fd , so that the incoming data  should come to new fd , instead of old one.  But still traffic is coming on old fd[dtlsv1 fd]

                   VI_res = SSL_accept(VP_ssl);

                   VI_res = BIO_set_fd(SSL_get_rbio(VP_ssl),VI_sock_id,BIO_NOCLOSE);

                   VI_res = BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr);    

   

      Please let me know your inputs i, so that traffic has to move from old fd to new fd.

       

What I do in my proposed DTLSv1_accept() API is that I move the data
>From the incoming socket to the new BIO's incoming queue:
https://github.com/mcr/openssl/blob/dtls-listen-refactor/ssl/d1_lib.c#L964

    /* At this point, there is a real ClientHello in serv->init_buf */
    memcpy(rb->buf, serv->init_buf->data, serv->init_num);
    rb->offset = 0;
    rb->left   = serv->init_num;

and then remove the packet from the incoming socket.  The situation is
then returned like this so that the new sockets can be setup, but the
incoming SSL_accept() BIO is stuffed with the correct (cookie-full)
ClientHello, and replies will go to the right place with the right source
address.  I hope to get these patches accepted for the March 11 freeze,
but you might not want to depend upon it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@xxxxxxxxxxxx  http://www.sandelman.ca/        |   ruby on rails    [

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users