On Wed, Oct 25, 2000 at 08:00:52PM -0400, Hugh Mandeville wrote:
> hello,
> i'm writing an SSL client whose transport isn't socket based, so i am using
> a BIO pair to manage the I/O.
>
> on one end of the BIO pair is the SSL BIO (ssl_bio) and on the other end the
> Client BIO (client_io).
>
> ssl_bio )---( client_io
>
> TO WRITE
> i write clear text into ssl_bio, read the cipher text from client_io and
> pass it on to the interface's send function.
>
> clear text --> ssl_bio )>>>( client_io --> cipher text --> send
>
> TO READ
> i call the interface's recv function, write the returned cipher text to
> client_io, and then read the clear text off of ssl_bio
>
> clear text <-- ssl_bio )<<<( client_io <-- cipher text <-- recv
I am not sure that you completely understood the useage of BIO pairs.
On the other hand, you might have understood correctly and simply got your
explanation wrong.
BIO-pairs are a kind of a two way buffering pipe. The SSL-engine needs
a BIO as underlying interface. This can be a socket-BIO for direct network
I/O, it can also be one side of the BIO-pair. Consider the pair having
"internal_bio" and "to_peer_bio".
You can now pipe/buffer things through this pair, it does however not do
any SSL-ish things.
Consider now you have an SSL "ssl", then you can connect "internal_bio"
to the "ssl" (SSL_set_bio()). This way your new interfaces are "ssl" for the
cleartext side and "to_peer_bio" for the communication with the peer
(send/recv). You will never touch "internal_bio" again!
If you don't like the SSL_read/write() interface, you can have another BIO
on top of the SSL, let's call it "application_bio" (BIO_set_ssl()).
You can now use the technique you describe like:
clear text --> application_bio )>>>( to_peer_bio --> cipher text --> send
clear text <-- application_bio )<<<( to_peer_bio <-- cipher text <-- recv
Now, at any time, BIO_ctrl_get_read_request(to_peer_bio) should always
return the number of bytes the SSL-engine requests you to reed from recv
and feed into to_peer_bio.
Whether or not the "application_bio" has been satisfied by the underlying
operations can then be checked by BIO_should_retry(application_bio) in
case BIO_read() did not succeed.
Best regards,
Lutz
--
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
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
