How do session accept timeout with OpenSSL

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

How do session accept timeout with OpenSSL

Charles Mills
Thanks Dave for your time and patience.

I am porting an existing Windows-based TCP/IP server (receive-only, not a Web server) to OpenSSL.

The way it works with TCP/IP is it sets up a socket, binds it to the desired port, sets up a timeval, and issues a select. When the select is satisfied if the socket is ready it starts a thread that issues an accept and goes into a receive loop. Otherwise it does some housekeeping like checking for a "quit" flag. In any event it loops back around to the select. Pretty typical I think.

Most of that ports fairly straightforwardly to OpenSSL. Not one to one, but pretty straghtforward: BIO_new_accept(), BIO_do_accept() * 2, BIO_pop(), SSL_setbio(), ...

What about the select? Is there some sort of BIO_select()? Is there some way to do SSL on native sockets rather than BIO objects? BIO has (I think!) a regular system socket under the covers -- is there a supported API for getting that socket so I can do a select on it?

Or do I have to re-write somehow with non-blocking sockets and/or using signals for my timeout rather than select()? Or ... ?

I have tried getting TCP/IP bind and BIO_do/new_accept() to coexist but they don't want to share a port, and my BIO_do_accept fails in the absence of a preceding BIO_do/new_accept().

Thanks much. Tried searching for an answer but "accept" and "bind" and "select" are such common keywords, and most of the hits are either for select for determining when a socket is readable or writable, or for OpenSSL's session timeouts.
Reply | Threaded
Open this post in threaded view
|

RE: How do session accept timeout with OpenSSL

Charles Mills
Okay, I think I get it. Every OpenSSL example I have seen uses BIO, but
there is no need to use BIO, right (unless one wants I/O-type-independence)?

I have eliminated all of my BIO usage. I'm using normal TCP/IP bind(),
select(), accept(), and then SSL_set_fd(ssl, socket) and SSL_accept(); I
then use SSL_read() to read data on the session. It seems to be working
(with some loose ends, but I am getting farther than before).

Is there anything wrong with this approach? Is this approach a bad idea?

Charles
-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of CharlesTSR
Sent: Tuesday, August 14, 2012 5:12 PM
To: [hidden email]
Subject: How do session accept timeout with OpenSSL


Thanks Dave for your time and patience.

I am porting an existing Windows-based TCP/IP server (receive-only, not a
Web server) to OpenSSL.

The way it works with TCP/IP is it sets up a socket, binds it to the desired
port, sets up a timeval, and issues a select. When the select is satisfied
if the socket is ready it starts a thread that issues an accept and goes
into a receive loop. Otherwise it does some housekeeping like checking for a
"quit" flag. In any event it loops back around to the select. Pretty typical
I think.

Most of that ports fairly straightforwardly to OpenSSL. Not one to one, but
pretty straghtforward: BIO_new_accept(), BIO_do_accept() * 2, BIO_pop(),
SSL_setbio(), ...

What about the select? Is there some sort of BIO_select()? Is there some way
to do SSL on native sockets rather than BIO objects? BIO has (I think!) a

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: How do session accept timeout with OpenSSL

Holger Weiss
* Charles Mills <[hidden email]> [2012-08-15 17:31]:
> Every OpenSSL example I have seen uses BIO, but there is no need to use
> BIO, right (unless one wants I/O-type-independence).

That's right, though the socket BIO methods also abstract away quite a
few obscure platform specifics.

> I have eliminated all of my BIO usage. I'm using normal TCP/IP bind(),
> select(), accept(), and then SSL_set_fd(ssl, socket) and SSL_accept(); I
> then use SSL_read() to read data on the session. It seems to be working
> (with some loose ends, but I am getting farther than before).
>
> Is there anything wrong with this approach?

No.  However, SSL_set_fd() automatically creates a socket BIO, so you
don't save an abstraction layer by setting up the socket manually.

> What about the select? Is there some sort of BIO_select()?

There's no such thing, but you could retrieve the underlying socket
descriptor with BIO_get_fd() and call select() on that.

Holger
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How do session accept timeout with OpenSSL

Dave Thompson-5
In reply to this post by Charles Mills
> From: [hidden email] On Behalf Of CharlesTSR
> Sent: Tuesday, 14 August, 2012 17:12

You've already followed-up with some, but a few more points:

> I am porting an existing Windows-based TCP/IP server
> (receive-only, not a Web server) to OpenSSL.
>
> The way it works with TCP/IP is it sets up a socket, binds it
> to the desired port [and select's with a timeout] <snip>
> Most of that ports fairly straightforwardly to OpenSSL. Not
> one to one, but
> pretty straghtforward: BIO_new_accept(), BIO_do_accept() * 2,
> BIO_pop(), SSL_setbio(), ...
>
> What about the select? Is there some sort of BIO_select()? Is
> there some way
> to do SSL on native sockets rather than BIO objects? BIO has
> (I think!) a
> regular system socket under the covers -- is there a supported API for
> getting that socket so I can do a select on it?
>
No and yes. socketBIO, and its variants acceptBIO and connectBIO,
are fairly thin wrappers on Unix sockets or Windows winsock.
(Technically sockets+netdb because for historical reasons they
are considered separate although almost always used together.)

If you use BIO to open a socket, BIO_get_fd returns sd or HANDLE,
you can use for native calls like select/poll and get/setsockopt.
(Technically you could call send and recv, but adding or removing
data will screw up the SSL protocol, which won't be helpful.)

Alternatively as you've already found you can open the socket
with socket() gethostbyname() bind() listen() connect() accept()
as applicable, and then SSL_set_fd, which wraps it in a BIO.

> Or do I have to re-write somehow with non-blocking sockets
> and/or using
> signals for my timeout rather than select()? Or ... ?
>
You do need to use nonblocking if/when you want a timelimit,
and SSL_get_error to tell you which direction to select for.
For accept=handshake it's obvious you need both directions,
but even for _read and _write (if you do those nonblocking)
your code should be able to select for the 'wrong' direction
in order to handle renegotiation.

I think you can set nonblocking only during SSL_accept (or
_connect) and switch to blocking for data if you want that,
but I haven't actually tested that combination.

> I have tried getting TCP/IP bind and BIO_do/new_accept() to
> coexist but they
> don't want to share a port, and my BIO_do_accept fails in the
> absence of a
> preceding BIO_do/new_accept().
>
> Thanks much. Tried searching for an answer but "accept" and "bind" and
> "select" are such common keywords, and most of the hits are either for
> select for determining when a socket is readable or writable, or for
> OpenSSL's session timeouts.

Details are in SSL_get_error manpage, which is admittedly not the most
obvious search, but SSL_connect/accept/read/write do point to it.


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]