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 <grace.priscilla@xxxxxxxxx> 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,GraceOn Sun, Jan 14, 2018 at 3:12 AM, Michael Richardson <mcr@xxxxxxxxxxxx> wrote:--
Grace Priscilla Jero <grace.priscilla@xxxxxxxxx> 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 [
] mcr@xxxxxxxxxxxx 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
