Hello,
Thanks again for answering my question, I appreciate it!
Bodo Moeller wrote:
> On Mon, Aug 09, 1999 at 10:48:54AM -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? 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 buffer size in the bio pair seems to be a little tricky. If the
> > buffers are not large enough to contain all the ssl data that the
> > BIO_f_ssl has generated the data will be transfered in chunks. The tricky
> > thing is that a BIO_read on the IO end will not make the BIO_f_ssl
> > transfer the rest of the data into the bio pair buffers automatically. To
> > trigger this you have to do a BIO_read or a BIO_write to the SSL end.
> > Again you can trick the filter by using zero-length buffers in your
> > BIO_read/write calls.
>
> If the write buffer fills up, writing to the SSL BIO will return -1
> and BIO_should_retry_write(ssl_bio) will be true. After taking the
> data from the I/O BIO, you have to call BIO_write for the SSL BIO
> again with the same parameters. Repeat until BIO_write reports
> success or a real error (and you've transferred the remaining data
> over the network or wherever you want to send it to).
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.
> > Does this all seem correct? I've tested my assumptions and so far this
> > seems to work but I'm a bit worried about rarely occuring conditions that
> > could make this fail. I'm integrating openssl into an application that is
> > multithreaded and some threads will be blocking while the "ssl thread"
> > does its thing so I have to be careful not to cause any deadlocks...
>
> The SSL library, when used with BIO pairs, never locks. Of course
> your handling of the BIO pair can block (when sending data obtained
> from the I/O BIO over a network, or when waiting for data from the
> network that has to be fed into the I/O BIO).
I understand that. What I meant is that I need to know how the ssl filter will
behave so that my application won't block when using it and communicating with
its peer. I was saying this just to indicate that I can't do something clean
and general as in ssltest.c, I need more understanding of how/when things will
happen and how to handle each case... The information you've given me so far
should be enough...
> > I've also had problems testing the behavior of my test programs when the
> > is no certificate or when the certificate is invalid. When I set both
> > communicating entities to verify certificates and I don't give a
> > certificate to the client it looks like the server is waiting forever for
> > the client cert. I thought the client would be sending something to tell
> > the server that it has no certificate. Am I right? Something similar
> > happens when I "disable" the trusted CA's certificate on the client side:
> > both the server and the client end up waiting for a message from its
> > peer. All this is happening in a relatively complex and very badly
> > written test program so I might very well be handling something
> > incorrectly.
>
> They should not be waiting (i.e. BIO_should_retry should return 0) --
> the calls to BIO_read/BIO_write return -1 because a real error
> occured.
I think that's the same problem again. It looks like as long as you stay on
the IO side the protocol failure is not noticed and the filter can still seem
to be waiting for data from its peer. If I do a BIO_write/read on the ssl end
the error is exposed. I'll simply have to be careful and retry the failing
BIO_read/write whenever I do anything on the IO end.
Thank you for your help...
Vincent Levesque
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
