On Tue, May 26, 2009 at 05:02:59PM -0400, Aaron Wiebe wrote:
> >> You're looking for a BIO_s_mem.
> >
> > No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
>
> And this is where I'm running into confusing bits of information.
> Bluntly, the documentation that I can find is nearly useless.
>
> Let me put it this way, in pseudocode of how I would like to interact
> in my perfect world:
There is no "SSL_decrypt" because SSL is not a packet encryption format
it is a complex state-machine that supports multi-step hand-shakes,
renegotiation, internal buffering, 2-step shutdown, ...
With biopairs, you still call SSL_connect() when a client wants to
complete an SSL handshake to a server, SSL_accept() when a server wants to
complete an SSL handshake with a client, SSL_read() when your application
wants to read data and SSL_write() when you want to write data, ...
But, with biopairs, the SSL context has no direct connection to the
network and cannot do *any* I/O, when its output buffer is full, or when
a response requested or required and the input buffer is empty, the
SSL_connect()/SSL_accept()/SSL_read()/SSL_write() calls will fail
and the error status from SSL_get_error(TLScontext->con, retval) will
be either: SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ.
It is *that* point (demand for external I/O) that you'll need to (even
with WANT_READ) always first drain as much of the network bio output
buffer to the network as possible without blocking, in-case the peer is
waiting for your input and then read data from the socket (and write to
the network bio, making it available to SSL) also without blocking.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
