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.nived...@gmail.com> wrote: > Hi Michael, > > Please find the response inline and also i have attached the pcap for your > reference. > > ip.src ==22.33.40.20 is the search criteria for pcap dump. > Regards, > Nivedita > > On Tue, Feb 20, 2018 at 12:13 AM, Michael Richardson <m...@sandelman.ca> > wrote: > >> >> Nivedita <maddi.nived...@gmail.com> wrote: >> >> Nivedita <maddi.nived...@gmail.com> 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 [ >> ] m...@sandelman.ca 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