Re: [openssl-users] DTLS-over-UDP client example

[aleksandr . derevianko]

Hello !

>>
>>  With such list it works, but without encoding (data send in cleartext, 
>> connection established as Cipher: NULL-SHA)
>>
>>  and if I remove eNULL on client side, it doesn't connect - server wait 
>> repeat of client cookue forever.
>>
>>  At the same time, "openssl s_client -dtls1 ..." connects fine, with Cipher: 
>> AES256-SHA
>
> Then debug why the server is ignoring the client request.
> OpenSSL has good debug output, in worst case add new prints...
>

Actually, I have traced it to ClientHello cookie exchange: test client connects 
to server, server calls generate_cookie() and never calls verify_cookie().

If I connect to test server using openssl s_client - server calls both 
generate_cookie() and verify_cookie(), and connection establishes.

If I return eNULL back in client ciphers list, server do not call  
generate_cookie(), and connection went OK.

If I comment out SSL_CTX_set_cookie_generate_cb() on server side, it still 
doesn't connect using test client but still connectes using openssl s_client.

-- 
Александр Деревянко/Aleksander Derevianko
Нач. отдела новых аппаратно-программных средств
Бомбардье Транспортейшн (Сигнал)/Bombardier Transportation (Signal) Ltd.
T:   +74959255370 Доб. 265
M: +79859229755

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

Re: [openssl-users] DTLS-over-UDP client example

[Richard Weinberger]

On Tue, Sep 18, 2018 at 9:18 AM 
wrote:> Unfortunelly, it's exactly this example which I use. You have
pointed on slightly different version,
> but all difference is:
>
> SSL_CTX_set_cookie_verify_cb(ctx, _cookie);
> instead of
> SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);
>
> ctx = SSL_CTX_new(DTLS_client_method());
> instead of
> ctx = SSL_CTX_new(DTLSv1_client_method());
>
>
> I have tryed it, works exactly the same.
>
> In both versions, on client side cipher_list is:
> SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");
>
> With such list it works, but without encoding (data send in cleartext, 
> connection established as  Cipher: NULL-SHA)
>
> and if I remove eNULL on client side, it doesn't connect - server wait repeat 
> of client cookue forever.
>
> At the same time,  "openssl s_client -dtls1   ..." connects fine, with 
> Cipher: AES256-SHA

Then debug why the server is ignoring the client request.
OpenSSL has good debug output, in worst case add new prints...

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

Re: [openssl-users] DTLS-over-UDP client example

[aleksandr . derevianko]

Hello !

17.09.2018, 16:26, "Richard Weinberger" :
> On Thu, Sep 13, 2018 at 3:51 PM  wrote:
>>  I tryed to dig inside openssl s_client source code, but it's really too 
>> complex for me, it seems like s_client doesn't use
>>  SSL_connect, instead, using more low-level functions.
>>
>>  So, does anybody have any simple client-side implementation of DTLS over 
>> UDP connection?
>
> https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c
> ... is a good example.

Unfortunelly, it's exactly this example which I use. You have pointed on 
slightly different version,
but all difference is: 

SSL_CTX_set_cookie_verify_cb(ctx, _cookie);
instead of 
SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);

ctx = SSL_CTX_new(DTLS_client_method());
instead of 
ctx = SSL_CTX_new(DTLSv1_client_method());


I have tryed it, works exactly the same.

In both versions, on client side cipher_list is:
SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");

With such list it works, but without encoding (data send in cleartext, 
connection established as  Cipher: NULL-SHA)

and if I remove eNULL on client side, it doesn't connect - server wait repeat 
of client cookue forever. 

At the same time,  "openssl s_client -dtls1   ..." connects fine, with Cipher: 
AES256-SHA

>
> In case you are on 1.1.x, please also see:
> https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html
>
> OpenSSL badly regressed in 1.1.x wrt. DTLS.
>

Actually, I use openssl-1.0.2o_2,1
Also, this "regression" is for multy-threaded server, not for single-threaded 
client.


-- 
Александр Деревянко/Aleksander Derevianko
Нач. отдела новых аппаратно-программных средств
Бомбардье Транспортейшн (Сигнал)/Bombardier Transportation (Signal) Ltd.
T:   +74959255370 Доб. 265
M: +79859229755

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

Re: [openssl-users] DTLS-over-UDP client example

[Richard Weinberger]

On Thu, Sep 13, 2018 at 3:51 PM  wrote:
> I tryed to dig inside openssl s_client source code, but it's really too 
> complex for me, it seems like s_client doesn't use
> SSL_connect, instead, using more low-level functions.
>
>
> So, does anybody have any simple client-side implementation of DTLS over UDP 
> connection?

https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c
... is a good example.

In case you are on 1.1.x, please also see:
https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html

OpenSSL badly regressed in 1.1.x wrt. DTLS.

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

Re: [openssl-users] DTLS over UDP

[Nivedita]

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

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

[Nivedita]

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  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 
> wrote:
>
>>
>> Nivedita  wrote:
>> >> Nivedita  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.  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, _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 

Re: [openssl-users] DTLS over UDP

[Michael Richardson]

Nivedita  wrote:
>> Nivedita  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

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

4) You make up new sockets, etc.
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.

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[ 



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] DTLS over UDP

[Nivedita]

Hi Michael,

Please find the response inline.

Regards,
Nivedita

On Wed, Feb 14, 2018 at 10:55 PM, Michael Richardson 
wrote:

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

Re: [openssl-users] DTLS over UDP

[Michael Richardson]

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

okay.

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

Do you mean, you call "SSL_connect()"?
Or do you mean you bind(2) and connect(2) the socket.

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

So, SSL_set_fd() will allocate a ne bio, which probably undoes the effect
of calling BIO_CRTL_DGRAM_SET_CONNECTED.  Since you have set the fd of
the existing BIO, I think you can omit that line.


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

Yes.

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

Do you expect additional connections on the existing socket?
I've been working on some new API to make this all easier.

Your method may fail if you have bound your "listen" to :: (0.0.0.0),
and you have multiple IPs.  In my case, I expect connections over IPv6 LL
addresses, and there are always multiple of those, and ifindex issues as well.

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



signature.asc
Description: PGP signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users