Information to detach a BIO from fd

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Information to detach a BIO from fd

Grace Priscilla Jero
Hi All,
We are having a scenario wherein we are having 2 BIOs for DTLS attached to the same fd. Each BIO has a different SSL associated with it. The messages are getting written to different BIO each time and we are trying to resolve it.

Is there a API or any way to detach one of the BIO/SSL from the fd for DTLS?

Thanks,
Grace


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Michael Richardson

Grace Priscilla Jero <[hidden email]> wrote:
    > We are having a scenario wherein we are having 2 BIOs for DTLS
    > attached to the same fd. Each BIO has a different SSL associated with
    > it. The messages are getting written to different BIO each time and we
    > are trying to resolve it.

    > Is there a API or any way to detach one of the BIO/SSL from the fd for
    > DTLS?

No.  How did you get into that situation in the first place?
My belief is that the DTLS API is suitable for (Secure)RTP only, and not for
CoAP-type usage. (or other DTLS server end-point usage)

According to some source code comments, you should have called connect() on
the socket after the first connection was received, and then (or
previously... there are race conditions either way), opened a new
socket.

I ran into this, and I wound up creating a new API, which is in a pull
request:
  https://github.com/openssl/openssl/pull/5024
  https://github.com/mcr/openssl/tree/dtls-listen-refactor

Sadly, the new test case I wrote is not running consistently, which I'm still
debugging.

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


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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Grace Priscilla Jero
Hi Michael,

Below is our scenario on DTLS.

We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections.

Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by 
  • creating bio/ssl each time on the same fd
  • fetching the peer using BIO_dgram_get_peer after ssl_accept 
  • Comparing it to the internally maintained list of peer
  • If it is a new peer we continue with handshake but if it is old peer we do the ssl_read.
The problem is that there are 2 bio/ssl that gets created for the same fd and the peer end up writing to one of them and we don't get the message on the intended ssl.
Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected case.

Thanks,
Grace

On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson <[hidden email]> wrote:

Grace Priscilla Jero <[hidden email]> wrote:
    > We are having a scenario wherein we are having 2 BIOs for DTLS
    > attached to the same fd. Each BIO has a different SSL associated with
    > it. The messages are getting written to different BIO each time and we
    > are trying to resolve it.

    > Is there a API or any way to detach one of the BIO/SSL from the fd for
    > DTLS?

No.  How did you get into that situation in the first place?
My belief is that the DTLS API is suitable for (Secure)RTP only, and not for
CoAP-type usage. (or other DTLS server end-point usage)

According to some source code comments, you should have called connect() on
the socket after the first connection was received, and then (or
previously... there are race conditions either way), opened a new
socket.

I ran into this, and I wound up creating a new API, which is in a pull
request:
  https://github.com/openssl/openssl/pull/5024
  https://github.com/mcr/openssl/tree/dtls-listen-refactor

Sadly, the new test case I wrote is not running consistently, which I'm still
debugging.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  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
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Jan Graczyk

Hello Everyone,

 

I am evaluating different SSL software stacks for a company product. Does anyone know how much is ROM memory footprint for OpenSSL? I would appreciate very much a help from you.

 

Best Regards,

 

Jan

 

From: openssl-users [mailto:[hidden email]] On Behalf Of Grace Priscilla Jero
Sent: Friday, January 12, 2018 8:49 AM
To: [hidden email]
Subject: Re: [openssl-users] Information to detach a BIO from fd

 

Hi Michael,

 

Below is our scenario on DTLS.

 

We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections.

 

Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by 

  • creating bio/ssl each time on the same fd
  • fetching the peer using BIO_dgram_get_peer after ssl_accept 
  • Comparing it to the internally maintained list of peer
  • If it is a new peer we continue with handshake but if it is old peer we do the ssl_read.

The problem is that there are 2 bio/ssl that gets created for the same fd and the peer end up writing to one of them and we don't get the message on the intended ssl.

Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected case.

 

Thanks,

Grace

 

On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson <[hidden email]> wrote:


Grace Priscilla Jero <[hidden email]> wrote:
    > We are having a scenario wherein we are having 2 BIOs for DTLS
    > attached to the same fd. Each BIO has a different SSL associated with
    > it. The messages are getting written to different BIO each time and we
    > are trying to resolve it.

    > Is there a API or any way to detach one of the BIO/SSL from the fd for
    > DTLS?

No.  How did you get into that situation in the first place?
My belief is that the DTLS API is suitable for (Secure)RTP only, and not for
CoAP-type usage. (or other DTLS server end-point usage)

According to some source code comments, you should have called connect() on
the socket after the first connection was received, and then (or
previously... there are race conditions either way), opened a new
socket.

I ran into this, and I wound up creating a new API, which is in a pull
request:
  https://github.com/openssl/openssl/pull/5024
  https://github.com/mcr/openssl/tree/dtls-listen-refactor

Sadly, the new test case I wrote is not running consistently, which I'm still
debugging.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  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
Reply | Threaded
Open this post in threaded view
|

Fwd: Information to detach a BIO from fd

Grace Priscilla Jero
In reply to this post by Grace Priscilla Jero

Hi All,

Below is our scenario on DTLS.

We have multiple connections to the same server. We have mapped one fd to the ssl in the server to receive all connections.

Whenever a connect is initiated from any client we need to know if it is already connected client or a new client. We are doing this by 
  • creating bio/ssl each time a polling happens on the server fd
  • fetching the peer using BIO_dgram_get_peer after ssl_accept 
  • Comparing it to the internally maintained list of peer
  • If it is a new peer we continue with handshake but if it is old peer we do the ssl_read.
The problem is that there are 2 bio/ssl that gets created for the same fd(when there are 2 clients) and the peer end up writing to latest of them and we don't get the message on the intended ssl.
Hence we are checking for a way to detach and remove the ssl/bio that gets created in already connected cases.

Any help is appreciated.

Any APIs available to close up the 2nd ssl associated with the fd. ssl_clear and ssl_free does not work.

Thanks,
Grace

On Thu, Jan 11, 2018 at 6:30 PM, Michael Richardson <[hidden email]> wrote:

Grace Priscilla Jero <[hidden email]> wrote:
    > We are having a scenario wherein we are having 2 BIOs for DTLS
    > attached to the same fd. Each BIO has a different SSL associated with
    > it. The messages are getting written to different BIO each time and we
    > are trying to resolve it.

    > Is there a API or any way to detach one of the BIO/SSL from the fd for
    > DTLS?

No.  How did you get into that situation in the first place?
My belief is that the DTLS API is suitable for (Secure)RTP only, and not for
CoAP-type usage. (or other DTLS server end-point usage)

According to some source code comments, you should have called connect() on
the socket after the first connection was received, and then (or
previously... there are race conditions either way), opened a new
socket.

I ran into this, and I wound up creating a new API, which is in a pull
request:
  https://github.com/openssl/openssl/pull/5024
  https://github.com/mcr/openssl/tree/dtls-listen-refactor

Sadly, the new test case I wrote is not running consistently, which I'm still
debugging.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Grace Priscilla Jero
> Sent: Friday, January 12, 2018 07:04


> Whenever a connect is initiated from any client we need to know if it is already connected client or a new client.
>  We are doing this by 
> • creating bio/ssl each time a polling happens on the server fd
> • fetching the peer using BIO_dgram_get_peer after ssl_accept 
> • Comparing it to the internally maintained list of peer

Don't create the BIO immediately. Use getpeername on the socket descriptor and check that against the list. Only create a new SSL object and BIO if it's not an already-established client.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

Grace Priscilla Jero


Hi Michael,
Without doing ssl_accept on the ssl will getpeername work? Also using the existing ssl with ssl_accept for the first connection we don’t get the information of second peer. Thus we ended up creating new bio/ssl each time we get a request.

Any suggestions?

Thanks,
Grace

On 12-Jan-2018, at 6:45 PM, Michael Wojcik <[hidden email]> wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of Grace Priscilla Jero
>> Sent: Friday, January 12, 2018 07:04
>
>
>> Whenever a connect is initiated from any client we need to know if it is already connected client or a new client.
>> We are doing this by
>> • creating bio/ssl each time a polling happens on the server fd
>> • fetching the peer using BIO_dgram_get_peer after ssl_accept
>> • Comparing it to the internally maintained list of peer
>
> Don't create the BIO immediately. Use getpeername on the socket descriptor and check that against the list. Only create a new SSL object and BIO if it's not an already-established client.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
> --
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

d3x0r
I'm not 100% sure what you're doing
I'd imagine that if SSL was managing the fd's you wouldn't have this issue.
You hvae to call accept() to get a new FD... and you'll only get that once, so when you accept() you should attach the bio and call ssl_accept(), no?

On Fri, Jan 12, 2018 at 5:52 PM, Priscilla Hero <[hidden email]> wrote:


Hi Michael,
Without doing ssl_accept on the ssl will getpeername work? Also using the existing ssl with ssl_accept for the first connection we don’t get the information of second peer. Thus we ended up creating new bio/ssl each time we get a request.

Any suggestions?

Thanks,
Grace

On 12-Jan-2018, at 6:45 PM, Michael Wojcik <[hidden email]> wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of Grace Priscilla Jero
>> Sent: Friday, January 12, 2018 07:04
>
>
>> Whenever a connect is initiated from any client we need to know if it is already connected client or a new client.
>> We are doing this by
>> • creating bio/ssl each time a polling happens on the server fd
>> • fetching the peer using BIO_dgram_get_peer after ssl_accept
>> • Comparing it to the internally maintained list of peer
>
> Don't create the BIO immediately. Use getpeername on the socket descriptor and check that against the list. Only create a new SSL object and BIO if it's not an already-established client.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
> --
> 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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

Michael Richardson

J Decker <[hidden email]> wrote:
    > I'm not 100% sure what you're doing I'd imagine that if SSL was
    > managing the fd's you wouldn't have this issue.  You hvae to call
    > accept() to get a new FD... and you'll only get that once, so when you
    > accept() you should attach the bio and call ssl_accept(), no?

accept(2) applies to TCP sockets only.

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


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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

Michael Richardson
In reply to this post by Grace Priscilla Jero

Priscilla Hero <[hidden email]> wrote:
    > Hi Michael, Without doing ssl_accept on the ssl will getpeername work?

ssl_accept() processes the packets on the socket.
getpeername() on a (Unix) socket will always work.

However, getpeername() on a UDP socket won't produce anything unless the
socket was connect(2)'ed.   In order to get the address of the remote system
one has to get it when receiving the packet.

That's why: https://github.com/mcr/openssl/commit/f764151782b4b32a752b4016336c0ceafa98ed5c
retrieves the peer name from the BIO.

    > On 12-Jan-2018, at 6:45 PM, Michael Wojcik
    > <[hidden email]> wrote:
    >> Don't create the BIO immediately. Use getpeername on the socket
    >> descriptor and check that against the list. Only create a new SSL
    >> object and BIO if it's not an already-established client.

That only works with TCP.

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


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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Michael Richardson
In reply to this post by Grace Priscilla Jero

Grace Priscilla Jero <[hidden email]> wrote:
    > Below is our scenario on DTLS.

    > We have multiple connections to the same server. We have mapped one fd
    > to the ssl in the server to receive all connections.

Are these connections from the same client (same 5-tuple), or are you just
talking about multiple clients?

    > Whenever a connect is initiated from any client we need to know if it
    > is already connected client or a new client. We are doing this by

    > * creating bio/ssl each time on the same fd

    > * fetching the peer using BIO_dgram_get_peer after ssl_accept

    > * Comparing it to the internally maintained list of peer

    > * If it is a new peer we continue with handshake but if it is old peer
    > we do the ssl_read.

I don't think this is going to work.

A UDP/DTLS server has two choices:

1) read all the packets on a unconnected socket and demultiplex them into
   appropriate BIOs/SSL structures.  I did not find an obvious way to do
   this, I think that a new BIO type would make this easiest.

   It also has the downside that it's hard to spread the load across
   multiple processes, although with the right locking multiple threads would
   likely work.

2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to
   the peer (by 5-tuple) so that all traffic from that peer arrives on the
   correct FD.
   AFAIK, there isn't anything to forbid two DTLS sessions between identical
   UDP sockets, as they could have differing session cookies, etc.


    > The problem is that there are 2 bio/ssl that gets created for the same
    > fd and the peer end up writing to one of them and we don't get the
    > message on the intended ssl.  Hence we are checking for a way to detach
    > and remove the ssl/bio that gets created in already connected case.

I don't think that is going to work.

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


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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Information to detach a BIO from fd

Michael Wojcik
In reply to this post by Michael Richardson
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Michael Richardson
> Sent: Saturday, January 13, 2018 16:34
>
>     > On 12-Jan-2018, at 6:45 PM, Michael Wojcik
>     > <[hidden email]> wrote:
>     >> Don't create the BIO immediately. Use getpeername on the socket
>     >> descriptor and check that against the list. Only create a new SSL
>     >> object and BIO if it's not an already-established client.
>
> That only works with TCP.

Yes, of course. I realized this myself when I saw the followup question. Post in haste, repent in leisure...

Thanks for the correction.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Grace Priscilla Jero
In reply to this post by Michael Richardson
Hi Michael,
The connections are from different peers and we are unable to use same SSL. 
Also getpeername on the UDP does not work as we have enabled SSL for the sender peer socket.
Any suggestions to resolve this?

When we have 2 SSL associated to a fd through BIO, on which BIO does the openssl do the read?
Can we restrict it to read from an SSL of user choice? 

We are just looking for an option to distinguish DTLS on UDP connections. We were'nt successful in doing it with DTLSv1_listen as it hangs on the SSL.

Thanks,
Grace

On Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson <[hidden email]> wrote:

Grace Priscilla Jero <[hidden email]> wrote:
    > Below is our scenario on DTLS.

    > We have multiple connections to the same server. We have mapped one fd
    > to the ssl in the server to receive all connections.

Are these connections from the same client (same 5-tuple), or are you just
talking about multiple clients?

    > Whenever a connect is initiated from any client we need to know if it
    > is already connected client or a new client. We are doing this by

    > * creating bio/ssl each time on the same fd

    > * fetching the peer using BIO_dgram_get_peer after ssl_accept

    > * Comparing it to the internally maintained list of peer

    > * If it is a new peer we continue with handshake but if it is old peer
    > we do the ssl_read.

I don't think this is going to work.

A UDP/DTLS server has two choices:

1) read all the packets on a unconnected socket and demultiplex them into
   appropriate BIOs/SSL structures.  I did not find an obvious way to do
   this, I think that a new BIO type would make this easiest.

   It also has the downside that it's hard to spread the load across
   multiple processes, although with the right locking multiple threads would
   likely work.

2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to
   the peer (by 5-tuple) so that all traffic from that peer arrives on the
   correct FD.
   AFAIK, there isn't anything to forbid two DTLS sessions between identical
   UDP sockets, as they could have differing session cookies, etc.


    > The problem is that there are 2 bio/ssl that gets created for the same
    > fd and the peer end up writing to one of them and we don't get the
    > message on the intended ssl.  Hence we are checking for a way to detach
    > and remove the ssl/bio that gets created in already connected case.

I don't think that is going to work.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  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
Reply | Threaded
Open this post in threaded view
|

Re: Information to detach a BIO from fd

Grace Priscilla Jero
Hi All,
We resolved the issue by using SSL_peek which does not clear the bio after read and we could also get the peer information after calling this API.
This helped us differentiate the peer connections.
Thanks for the multiple suggestions provided.

Thanks,
Grace

On Tue, Jan 16, 2018 at 12:34 PM, Grace Priscilla Jero <[hidden email]> wrote:
Hi Michael,
The connections are from different peers and we are unable to use same SSL. 
Also getpeername on the UDP does not work as we have enabled SSL for the sender peer socket.
Any suggestions to resolve this?

When we have 2 SSL associated to a fd through BIO, on which BIO does the openssl do the read?
Can we restrict it to read from an SSL of user choice? 

We are just looking for an option to distinguish DTLS on UDP connections. We were'nt successful in doing it with DTLSv1_listen as it hangs on the SSL.

Thanks,
Grace

On Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson <[hidden email]> wrote:

Grace Priscilla Jero <[hidden email]> wrote:
    > Below is our scenario on DTLS.

    > We have multiple connections to the same server. We have mapped one fd
    > to the ssl in the server to receive all connections.

Are these connections from the same client (same 5-tuple), or are you just
talking about multiple clients?

    > Whenever a connect is initiated from any client we need to know if it
    > is already connected client or a new client. We are doing this by

    > * creating bio/ssl each time on the same fd

    > * fetching the peer using BIO_dgram_get_peer after ssl_accept

    > * Comparing it to the internally maintained list of peer

    > * If it is a new peer we continue with handshake but if it is old peer
    > we do the ssl_read.

I don't think this is going to work.

A UDP/DTLS server has two choices:

1) read all the packets on a unconnected socket and demultiplex them into
   appropriate BIOs/SSL structures.  I did not find an obvious way to do
   this, I think that a new BIO type would make this easiest.

   It also has the downside that it's hard to spread the load across
   multiple processes, although with the right locking multiple threads would
   likely work.

2) after each call to DTLSv1_listen(), set up a new fd that is bind()/connect()ed to
   the peer (by 5-tuple) so that all traffic from that peer arrives on the
   correct FD.
   AFAIK, there isn't anything to forbid two DTLS sessions between identical
   UDP sockets, as they could have differing session cookies, etc.


    > The problem is that there are 2 bio/ssl that gets created for the same
    > fd and the peer end up writing to one of them and we don't get the
    > message on the intended ssl.  Hence we are checking for a way to detach
    > and remove the ssl/bio that gets created in already connected case.

I don't think that is going to work.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [hidden email]  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