On Tue, Jun 20, 2000 at 12:34:56AM +0200, Doris Diedrich wrote:
> On Mon, 19 Jun 2000, Arun Venkataraman wrote:
> > First of all, BIOs by themselves are not blocking or non-blocking. It is the
> > underlying file descriptor that is blocking or non-blocking. Thus, u can
> > have a blocking BIO as well as a non-blocking BIO. I haven't used BIOs
> > myself, but I believe they are some kind of a wrapper on the SSL struct and
> > some other stuff.
> This helps a bit. And they are absolutely no network based (something you
> could see from the outside) thingies?
>
> Anybody knows where those BIOs are implemented?
> Or anybody knows what they rely on? 'Just' files?? Pipes?? Something
> else??
BIOs are everywhere :-)
The implementation is in crypto/bio.
Consider you have a TLS engine that does need two interfaces, one for the
application side, one for the network side:
application
----------- * interface
TLS-engine
----------- * interface
network
These two interface must be realized. The application/TLS-engine interface
is directly available using the SSL_read()/SSL_write() calls.
The TLS-engine/network interface is more complicated. It must allow the
TLS-engine to read from/write to the network. To realize this in a
portable way, a BIO is used. If you use SSL_set_fd() to connect the
TLS-engine directly to the network, a network-BIO is transparently
created for you:
application
| SSL_read()/SSL_write()
TLS-engine
| BIO-interface
BIO (network)
| read()/write() from/to the socket
network
The socket setting (blocking/non-blocking) is passed through the network-BIO
and the TLS-engine. If the socket is blocking, the network BIO (using the
blocking read()/write() calls) will block also as will the TLS-engine.
If the socket is non-blocking, the read()/write() calls will not completely
satisfy the network BIO and TLS-engine, so that the TLS-engine will return
to the application with the "try again" error condition until all necessary
network operations for performed for success.
Another possible implementation is the use of a BIO-pair below the TLS-engine:
[The following comment taken from my Postfix/TLS patchkit global/pfixtls.c]
/*
* DESCRIPTION: Keeping control of the network interface using BIO-pairs.
*
* When the TLS layer is active, all input/output must be filtered through
* it. On the other hand to handle timeout conditions, full control over
* the network socket must be kept. This rules out the "normal way" of
* connecting the TLS layer directly to the socket.
* The TLS layer is realized with a BIO-pair:
*
* postfix | TLS-engine
* | |
* +--------> SSL_operations()
* | /\ ||
* | || \/
* | BIO-pair (internal_bio)
* +--------< BIO-pair (network_bio)
* | |
* socket |
*
* The normal postfix operations connect to the SSL operations to send
* and retrieve (cleartext) data. Inside the TLS-engine the data are converted
* to/from TLS protocol. The TLS functionality itself is only connected to
* the internal_bio and hence only has status information about this internal
* interface.
* Thus, if the SSL_operations() return successfully (SSL_ERROR_NONE) or want
* to read (SSL_ERROR_WANT_READ) there may as well be data inside the buffering
* BIO-pair. So whenever an SSL_operation() returns without a fatal error,
* the BIO-pair internal buffer must be flushed to the network.
* NOTE: This is especially true in the SSL_ERROR_WANT_READ case: the TLS-layer
* might want to read handshake data, that will never come since its own
* written data will only reach the peer after flushing the buffer!
*
* ...
*/
It is then used with
...
BIO_new_bio_pair(&TLScontext->internal_bio, BIO_bufsiz,
&TLScontext->network_bio, BIO_bufsiz));
...
SSL_set_bio(TLScontext->con, TLScontext->internal_bio,
TLScontext->internal_bio);
...
SSL_accept()/_read()/_write() operations...
...
Hence, using BIO-pairs you have complete control over what goes into the
TLS-engine and what goes out on both sides of the TLS-engine.
Best regards,
Lutz
PS. Following actual statements on this list the discussion should be
moved to openssl-users!
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
