On Tue, Aug 10, 1999 at 10:55:05AM -0400, Vincent Levesque wrote:
>>> The ssl handshake is not initiated until a BIO_read or a BIO_write to the
>>> SSL end of the filter. In order to force the initialization of the
>>> handshake without actually exchanging data it is possible to call those
>>> functions with the buffer length set to 0. The calls to BIO_read and
>>> BIO_write will return -1 until the handshake is completed.
>>> BIO_should_retry(ssl_bio) will return 1, which means that we have to
>>> retry the call with the same arguments later.
>> Yes. However most people seam to prefer not to use the SSL BIO
>> (implemented in ssl/bio_ssl.c), but to use the SSL_... API directly.
>> Then you can call SSL_connect or SSL_accept directly if you want to.
> I'm confused. Are you saying that I could still use a bio pair
> combined with a BIO_f_ssl but use SSL_read/write/accept/connect(ssl)
> instead of BIO_read/write(client_io/c_ssl_bio)? Or should I drop the
> BIO_f_ssl and use SSL_ calls?
The latter -- if you want to have a clean way to enforce handling the
handshake and so on. BIO_f_ssl hides these things from the
application, and you are trying to do them anyway, so why not use the
SSL_... API directly? You don't have to, of course; but if you look
at ssl/bio_ssl.c (in combination with crypto/bio/bio.h and
crypto/bio/bio_lib.c), you'll see that BIO_f_ssl does not really do a
lot.
> I don't fully understand how the SSL_
> calls are operating or for that matter exactly how the BIOs
> interact. I assumed bio pairs should be used as in ssltest.c but if
> there is a better way I'm all for it...
The decision between the SSL_... API and BIO_f_ssl does not make a
difference as far as the BIO pairs are concerned. The wiring is
as follows:
__________________________________________
| |
| Application |
| ______ |
|"real" application /stream\ |
|___________________________/relaying\____|
| | |
| | |
- - - - - - | |
| | |
| SSL_f_bio |
(optional)| | I/O
- - - - - - |
| |
______|_______ |
| | |
| SSL libary | |
|____________| |
| |
_____|____________________|_______
| |
| BIO pair |
|________________________________|
[...]
> This makes perfect sense. I think I was sending all the available
> data to the socket and then I was blocking on the socket read
> because something was indicating the filter was waiting for data
> (probably BIO_should_read). The right way to do it then is to retry
> the BIO_read/write whenever an action is performed at the socket/IO
> level, and not to trust that the "state" of the ssl filter has been
> updated after the action on the IO end.
Yes. The BIO_should_retry... state of a BIO is updated only when you
use one of its input or output functions; BIO_should_retry...(bio)
just looks at the stored flags without testing if they are still valid.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
