[openssl-users] 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:openssl-users-bounces at openssl.org] On Behalf Of Grace Priscilla Jero
Sent: Friday, January 12, 2018 8:49 AM
To: openssl-users at openssl.org
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 <mcr at sandelman.ca<mailto:mcr at sandelman.ca>> wrote:

Grace Priscilla Jero <grace.priscilla at gmail.com<mailto:grace.priscilla at gmail.com>> 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  [
]     mcr at sandelman.ca<mailto:mcr at sandelman.ca>  http://www.sandelman.ca/        |   ruby on rails    [


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180112/b659029d/attachment-0001.html>