<div dir="ltr">Hi Michael,<div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Nivedita</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 21, 2018 at 11:54 AM, Nivedita <span dir="ltr"><<a href="mailto:maddi.nivedita@gmail.com" target="_blank">maddi.nivedita@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Michael,<div><br></div><div>Please find the response inline and also i have attached the pcap for your reference.</div><div><br></div><div>ip.src ==22.33.40.20 is the search criteria for pcap dump.</div><div>Regards,</div><div>Nivedita<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Feb 20, 2018 at 12:13 AM, Michael Richardson <span dir="ltr"><<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5"><span class="m_3772872272450068029gmail-"><br>
Nivedita <<a href="mailto:maddi.nivedita@gmail.com" target="_blank">maddi.nivedita@gmail.com</a>> wrote:<br>
>> Nivedita <<a href="mailto:maddi.nivedita@gmail.com" target="_blank">maddi.nivedita@gmail.com</a>> wrote:<br>
<br>
>>> I am trying to establish DTLS over UDP connection by using<br>
>>> DTLSv1_listen method .<br>
<br>
>>> I have followed the below steps - 1. Created a server socket<br>
>>> and using<br>
>>> this socket created bio and ssl object. bio =<br>
>>> BIO_new_dgram(VI_sock,BIO_NOCL<wbr>OSE)) SSL_set_bio<br>
>>> (ssl,VP_bio,VP_bio);<br>
<br>
>>> 2. Enable cookie exchange on SSL object. SSL_set_options(ssl,<br>
>>> SSL_OP_COOKIE_EXCHANGE);<br>
<br>
>>> 3. Then started listening using dtlsv1_listen for the new<br>
>>> client<br>
>>> connections. Once dtlsv1_listen is successful and i got the<br>
>>> peer<br>
>>> address.<br>
<br>
mcr> okay.<br>
<br>
<br>
>> Nivedita- All the above mentioned steps i am doing on server<br>
>> side . On the<br>
>> client side i have already initiated ssl_connect.<br>
>> On the server side when i am listening using dtlsv1_listen<br>
>> method -<br>
<br>
>>> 4. Once i got the peer address , i am creating one more socket<br>
>>> 5. With the new socket i tried to connect to peer address.<br>
<br>
</span><span class="m_3772872272450068029gmail-"> >> Then once i got the client address from the dtlsv1_listen method,<br> >> i am creating one more socket and trying to connect to this client<br> >> address.<br>
<br>
</span>>I think that I see what is wrong with your flow... you haven't taken the<br>>packet off the original socket, so SSL_accept is still looking for it.<br>
<br>>The flow is supposed to be:<br> > 1) client sends ClientHello<br></div></div>
Nivedita- Client is sending the client hello. <br></blockquote><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >2) DTLSv1_listen() sees it, and sends a HelloVerifyRequest<br> > (I assume you have filled in the cookie callbacks. I think that<br> > perhaps there should be good cryptographic defaults available in<br> >the library. Maybe there are, and I'm ignorant of them)<br>
<br></blockquote></span><div> Nivedita- Yes, I have attached all the cookies and server is responding with hello verify request. </div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > 3) Client sends ClientHello w/cookie.<br> > DTLSv1_listen() then sees that and tweaks the SSL* to indicate that<br> > the cookie has been accepted. Note that the packet is *LEFT*<br> > on the incoming socket so that SSL_accept() can process it.<br> > This is one the places where the DTLSv1_listen() API is rather<br> > hard to use in my opinion.<br></blockquote></span><div> Nivedita- Now after Hello verify request is done, client sends the client hello with cookie.</div><div> Now i have done SSL_accept on the same server socket.[ means the same socket on which dtlsv1_listen was triggered] </div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>> 4) You make up new sockets, etc.<br></blockquote></span><div> 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. </div><div> </div><div> VI_sock_id = socket(client_addr.ss_family,<wbr>SOCK_DGRAM,0);</div><div> </div><div> VI_status = connect(VI_sock_id, (struct sockaddr *)&client_addr, sizeof(struct sockaddr_storage));</div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 5) But, you need to call SSL_accept() once with the **old socket** to<br>> process packet that listen() left on it, and then you can switch the<br>> FD over! Of course, you probably want to make sure that SSL_accept()<br>> sends the reply correctly.<br></blockquote><div><br></div></span><div> Nivedita- As suggested i have done the ssl_accept on the same socket on which dtlsv1_listen was triggered. </div><div> 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]</div><div><br></div><div> VI_res = SSL_accept(VP_ssl);</div><div><div> VI_res = BIO_set_fd(SSL_get_rbio(VP_<wbr>ssl),VI_sock_id,BIO_NOCLOSE);</div><span class=""><div> VI_res = BIO_ctrl(SSL_get_rbio(VP_ssl),<wbr>BIO_CTRL_DGRAM_SET_CONNECTED, 0, &client_addr); </div></span></div><div> </div><div> Please let me know your inputs i, so that traffic has to move from old fd to new fd.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
What I do in my proposed DTLSv1_accept() API is that I move the data<br>
>From the incoming socket to the new BIO's incoming queue:<br>
<a href="https://github.com/mcr/openssl/blob/dtls-listen-refactor/ssl/d1_lib.c#L964" rel="noreferrer" target="_blank">https://github.com/mcr/openssl<wbr>/blob/dtls-listen-refactor/<wbr>ssl/d1_lib.c#L964</a><br>
<br>
/* At this point, there is a real ClientHello in serv->init_buf */<br>
memcpy(rb->buf, serv->init_buf->data, serv->init_num);<br>
rb->offset = 0;<br>
rb->left = serv->init_num;<br>
<br>
and then remove the packet from the incoming socket. The situation is<br>
then returned like this so that the new sockets can be setup, but the<br>
incoming SSL_accept() BIO is stuffed with the correct (cookie-full)<br>
ClientHello, and replies will go to the right place with the right source<br>
address. I hope to get these patches accepted for the March 11 freeze,<br>
but you might not want to depend upon it.<br>
<div class="m_3772872272450068029gmail-HOEnZb"><div class="m_3772872272450068029gmail-h5"><br>
<br>
--<br>
] Never tell me the odds! | ipv6 mesh networks [<br>
] Michael Richardson, Sandelman Software Works | network architect [<br>
] <a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a> <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a> | ruby on rails [<br>
<br>
</div></div><br></span><span class="HOEnZb"><font color="#888888">--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailma<wbr>n/listinfo/openssl-users</a><br>
<br></font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div>