Re: [openssl-users] DTLS over UDP
Hi Michael, We are working on SIP , and i am looking for dtlsv1_accept method so that when multiple clients want to connect to single server, dtls should open a separate port for each client instance, when running over udp. Regards, Nivedita On Wed, Mar 21, 2018 at 11:04 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Nivedita <maddi.nived...@gmail.com> wrote: > > 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. > > No. I will be rebasing very soon. > (I'm a contributor like you) > > Even the basic BIO patches that I was working on were not yet accepted, as > I > guess I need to validate that it compiles on VMS. > I hope to get an accout soon that I can use to verify things. > > BTW: Are you speaking about *SIP* or *RTP? My impression is that the > existing API was designed specifically for SRTP. > > -- > ] 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
Re: [openssl-users] DTLS over UDP
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 > *)_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.
Re: [openssl-users] DTLS over UDP
Hi Michael, Please find the response inline. Regards, Nivedita On Wed, Feb 14, 2018 at 10:55 PM, Michael Richardson <m...@sandelman.ca> wrote: > > Nivedita <maddi.nived...@gmail.com> wrote: > > Hi Michael, > > > Thanks for the reply. > > > I have mentioned the answers below. > > >okay. I saw only one comment. Maybe you could use standard usenet > quoting? > >Tell me a bit more about what you are working on? > >I'm trying to make CoAP+DTLS work with the ruby-on-rails "David" CoAP > server. > Nivedita - We are using c and Socket programming to establish dtls over udp for sip communication. > > 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. > > > mcr> Do you mean, you call "SSL_connect()"? > > mcr> Or do you mean you bind(2) and connect(2) the socket. > >You didn't answer this. >You imply you might have tried "SSL_connect()" on the server side. Nivedita - SSL_connect is already issued on client side , because of which it triggered the server and dtlsv1_listen was successful and i got the peer address from dtlsv1_listen. >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. > Vi_res= connect(new sockid, client_addr, sizeof (client addr)); I am able to connect to client address which i got in dtlsv1_listen method using new socket id. and i want to do the ssl_accept on the new socket id by issuing bio_set_fd and bio_ctrl. But ssl_accept fails with error code 2. BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, _addr) ssl_accept (VP_ssl) I would like to mention that VP_ssl is created using server socket id, but we are trying to do ssl_accept on newly created socket id which is connected to peer address[got from dtlsv1_listen method) , so that we can use this socket for further read-write operations and server socket for listening operations. > > > >> 6. Then i am trying to do ssl_accept on the new socket by calling > >> bio_set_fd. > > >> BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); > > >> BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, > >> _addr); > > >> SSL_set_fd(ssl,VI_newsock_id); > > mcr> So, SSL_set_fd() will allocate a ne bio, which probably undoes > the effect > mcr> of calling BIO_CRTL_DGRAM_SET_CONNECTED. Since you have set the > fd of > mcr> the existing BIO, I think you can omit that line. > > Please omit the SSL_set_fd(), since you've already done it. > > I have a pull request at: > https://github.com/openssl/openssl/pull/5024 > > which I am reworking to suit the OpenSSL team. > I am solving the same problem that you have encountered. > > -- > ] 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] Fwd: DTLS over UDP
Hi Michael, Please ignore the previous mail. By mistankely it got sent. I have provided my comments below. Thanks in advance. Regards, Nivedita On Wed, Feb 14, 2018 at 10:22 AM, Nivedita <maddi.nived...@gmail.com> wrote: > Hi Michael, > > Thanks for the reply. > > I have mentioned the answers below. > > > On Wed, Feb 14, 2018 at 12:21 AM, Michael Richardson <m...@sandelman.ca> > wrote: > >> From: Michael Richardson <m...@sandelman.ca> >> To: openssl-users@openssl.org >> Subject: Re: [openssl-users] DTLS over UDP >> In-Reply-To:
[openssl-users] DTLS over UDP
Hi All, 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. 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. 6. Then i am trying to do ssl_accept on the new socket by calling bio_set_fd. BIO_set_fd(SSL_get_rbio(ssl),VI_new_sock_id,BIO_NOCLOSE); BIO_ctrl(SSL_get_rbio(VP_ssl),BIO_CTRL_DGRAM_SET_CONNECTED, 0, _addr); SSL_set_fd(ssl,VI_newsock_id); VI_res = SSL_accept(ssl); But ssl_accept will always return error code 2 [ i.e want read or want write] But if i am doing ssl_accept without doing the step no 6 it it will be successful. Could someone please let us know how to switch to newly created socket, so that it can start using newly created socket for further read and write operations and original server socket will keep on listening for new connections. Regards, Nivedita -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: Question regarding OpenSSL Security Advisory
Hey Pandit, From what I understand the vulnerability can apply if: 1) Internal session caching is *not* disable - This means the session cache is mantained in SSL_CTX. 2) Internal Lookup is not disabled - This means that the ssl code will lookup the session cache on receiving ClientHello with valid session Id. 3) Your application is designed such that you create a SSL_CTX and multiple threads can access it. In this case multiple threads could be accessing the same session object (from session cache). T he function in t1_lib.c On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana ppanb...@yahoo.comwrote: Hi, I am not clear about the condition that vulnerability when using internal session caching mechanism. Is it the same thing as TLS session caching or this is some thing different? Thank you, - Pandit -- *From:* David Schwartz dav...@webmaster.com *To:* openssl-users@openssl.org *Cc:* Nivedita Melinkeri nivedita...@gmail.com *Sent:* Wed, November 17, 2010 4:15:36 AM *Subject:* Re: Question regarding OpenSSL Security Advisory On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: Hi, I had some questions about the latest security advisory. I understand that this applies to multi-threaded application while using ssl sessions. Correct. If the application is written thread safe using CRYPTO_set_locking_callback functions will the vulnerability still apply ? If it didn't, it wouldn't be a vulnerability at all. If the ssl code calls the locking callback function before accessing the internal session cache then the vulnerability should not apply to above mentioned applications. Right, it shouldn't, but it does. That's what makes it a vulnerability. Code not working under conditions where it cannot be expected to work is not a vulnerability, it's simply misuse. This is a vulnerability because it affects applications that use the code correctly. DS __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding OpenSSL Security Advisory
Hey Pandit, Sorry for sending out the previous before it was complete. So here it goes From what I understand the vulnerability can apply if: 1) Internal session caching is *not* disable - This means the session cache is mantained in SSL_CTX. 2) Internal session cache Lookup is *not* disabled - This means that the ssl code will lookup the session cache on receiving ClientHello with valid session Id. 3) Your application is designed such that you create a SSL_CTX and multiple threads can access it. In this case multiple threads could be accessing the same session object (from session cache). The function ssl_parse_clienthello_tlsext in t1_lib.c has unsynchronized access to members in session object which could cause the vulnerability. David/other experinced openssl users correct me if you think this understanding is incottect. Regards, Nivedita On Thu, Nov 18, 2010 at 7:26 AM, Pandit Panburana ppanb...@yahoo.comwrote: Hi, I am not clear about the condition that vulnerability when using internal session caching mechanism. Is it the same thing as TLS session caching or this is some thing different? Thank you, - Pandit -- *From:* David Schwartz dav...@webmaster.com *To:* openssl-users@openssl.org *Cc:* Nivedita Melinkeri nivedita...@gmail.com *Sent:* Wed, November 17, 2010 4:15:36 AM *Subject:* Re: Question regarding OpenSSL Security Advisory On 11/16/2010 11:06 PM, Nivedita Melinkeri wrote: Hi, I had some questions about the latest security advisory. I understand that this applies to multi-threaded application while using ssl sessions. Correct. If the application is written thread safe using CRYPTO_set_locking_callback functions will the vulnerability still apply ? If it didn't, it wouldn't be a vulnerability at all. If the ssl code calls the locking callback function before accessing the internal session cache then the vulnerability should not apply to above mentioned applications. Right, it shouldn't, but it does. That's what makes it a vulnerability. Code not working under conditions where it cannot be expected to work is not a vulnerability, it's simply misuse. This is a vulnerability because it affects applications that use the code correctly. DS __ OpenSSL Projecthttp://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Question regarding OpenSSL Security Advisory
Hi,
I had some questions about the latest security advisory. I understand that
this applies to multi-threaded application while using ssl sessions.
If the application is written thread safe using CRYPTO_set_locking_callback
functions will the vulnerability still apply ?
If the ssl code calls the locking callback function before accessing the
internal session cache then the vulnerability should not
apply to above mentioned applications.
Please advice.
Any help on this is really appreciated.
Regards,
Nivedita
On Tue, Nov 16, 2010 at 7:15 AM, OpenSSL open...@master.openssl.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OpenSSL Security Advisory [16 November 2010]
TLS extension parsing race condition.
=
A flaw has been found in the OpenSSL TLS server extension code parsing
which
on affected servers can be exploited in a buffer overrun attack.
The OpenSSL security team would like to thank Rob Hulswit for reporting
this
issue.
The fix was developed by Dr Stephen Henson of the OpenSSL core team.
This vulnerability is tracked as CVE-2010-3864
Who is affected?
=
All versions of OpenSSL supporting TLS extensions contain this
vulnerability
including OpenSSL 0.9.8f through 0.9.8o, 1.0.0, 1.0.0a releases.
Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses
OpenSSL's internal caching mechanism. Servers that are multi-process and/or
disable internal session caching are NOT affected.
In particular the Apache HTTP server (which never uses OpenSSL internal
caching) and Stunnel (which includes its own workaround) are NOT affected.
Recommendations for users of OpenSSL
=
Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should
update
to the OpenSSL 0.9.8p release which contains a patch to correct this issue.
Users of OpenSSL 1.0.0 and 1.0.0a should update to the OpenSSL 1.0.0b
release
which contains a patch to correct this issue.
If upgrading is not immediately possible, the relevant source code patch
provided in this advisory should be applied.
Patch for OpenSSL 0.9.8 releases
Index: ssl/t1_lib.c
===
RCS file: /v/openssl/cvs/openssl/ssl/t1_lib.c,v
retrieving revision 1.13.2.27
diff -u -r1.13.2.27 t1_lib.c
- --- ssl/t1_lib.c 12 Jun 2010 13:18:58 - 1.13.2.27
+++ ssl/t1_lib.c15 Nov 2010 15:20:14 -
@@ -432,14 +432,23 @@
switch (servname_type)
{
case TLSEXT_NAMETYPE_host_name:
- - if (s-session-tlsext_hostname ==
NULL)
+ if (!s-hit)
{
- - if (len
TLSEXT_MAXLEN_host_name ||
- -
((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL))
+
if(s-session-tlsext_hostname)
+ {
+ *al =
SSL_AD_DECODE_ERROR;
+ return 0;
+ }
+ if (len
TLSEXT_MAXLEN_host_name)
{
*al =
TLS1_AD_UNRECOGNIZED_NAME;
return 0;
}
+ if
((s-session-tlsext_hostname = OPENSSL_malloc(len+1)) == NULL)
+ {
+ *al =
TLS1_AD_INTERNAL_ERROR;
+ return 0;
+ }
memcpy(s-session-tlsext_hostname, sdata, len);
s-session-tlsext_hostname[len]='\0';
if
(strlen(s-session-tlsext_hostname) != len) {
@@ -452,7 +461,8 @@
}
else
- - s-servername_done =
strlen(s-session-tlsext_hostname) == len
+ s-servername_done =
s-session-tlsext_hostname
+
strlen(s-session-tlsext_hostname) == len
strncmp(s-session-tlsext_hostname, (char *)sdata, len) == 0;
break;
Patch for OpenSSL 1.0.0 releases
Index: ssl/t1_lib.c
Openssl-dtls Client session sends hello in response to server hello.
Hi All, I am using openssl-0.9.8n with dtls-srtp extension. After upgrading to openssl version 0.9.8n I see a weird problem. This happens only once in a few hundred dtls handshakes. The dtls client sends client hello with 0 session id. The dtls server sends server hello with valid session id. Instead of responding to the server hello with ClientKeyExchange the client sends back a client hello message with 0 session id but some additional data (244 bytes) at the end of the packet. Here is the dump of the spurious client hello : 355 bytes 16 fe ff 00 00 00 00 00 00 00 01 00 60 01 00 00 54 00 00 00 00 00 00 00 54 fe ff 4c 19 5e 5b e2 da 29 22 22 c8 b3 ad 81 e2 33 1f e5 ec a0 1c 73 b8 ee a0 0f 0c 74 c0 ae 02 00 da 00 00 00 24 00 39 00 38 00 35 00 16 00 13 00 0a 00 33 00 32 00 2f 00 07 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 ff 01 00 00 06 80 01 00 02 00 01 16 fe ff 00 00 00 00 00 00 00 02 00 8e 10 00 00 82 00 01 00 00 00 00 00 82 00 80 04 de 96 fd 46 62 1e 81 e8 41 30 ef 6d 73 34 f4 e5 cf 6e 50 3a a5 46 da ce d3 5b 32 2d af 5e 2b f5 8a d0 68 a2 76 89 b2 e7 fd 09 ef ae 3d f8 d4 01 bc 64 21 ec cd 0a 10 0f 02 22 de 22 f0 7b 65 d4 c3 03 f7 2c f9 36 29 a5 0c d8 2c 1f aa 71 76 ed aa e3 8c 05 e0 ac 87 4d 6e 74 b4 b9 88 61 c6 f1 58 88 ac a1 a4 e2 d7 76 4a ac 9b 98 e9 bd a6 53 7a ff 5e 57 ef c3 0e 44 bd fc a5 d5 ae 0e 1d 14 fe ff 00 00 00 00 00 00 00 03 00 01 01 16 fe ff 00 01 00 00 00 00 00 00 00 40 9e f2 5e 8b df 59 06 b1 a8 8b 98 ff aa 30 a2 37 83 c5 a3 52 a7 63 5a 35 ad 93 d5 00 5d c8 a7 e9 a3 cb 5b 5d 99 c0 29 bc 41 e7 73 3d ed 01 97 58 37 bb 05 7f 9e 36 45 67 92 7b 04 24 08 f4 f2 dc On receiving this client hello the server assumes that we are resuming an existing session and responds back with ServerHello with Finished message. Has anyone seen such a issue or know why this could happen with 0.9.8n. Any help is greatly appreciated. Regards, Nivedita
