Jeremy Bennett <[EMAIL PROTECTED]>:
>>> 1) I see that SSL_write and SSL_read can result in errors
>>> SSL_ERROR_WANT_READ/WRITE. Since this is the case, can I have
>>> simultaneous outstanding SSL_reads and SSL_writes? That is, if I call
>>> SSL_read and it results in SSL_ERROR_WANT_WRITE can I go ahead and call
>>> SSL_write or should I wait for SSL_read to return success? (and vice
>>> versa)
>> Handling such situations is a little complicated, but it can be done.
>> The difficulty is that after you've called SSL_read or SSL_write, the
>> result code of the previous call to on of these functions may no
>> longer be valid. So if the second function reports success, you
>> should just retry the first one, because clearly something happened.
>> If both functions result in an SSL_ERROR_WANT_READ/WRITE result code,
>> then it's not obvious what should be done -- just retrying everything
>> may lead to busy waiting, but if you want to call select() instead you
>> don't know what you should really select() for.
> We have an event handler that will call a specific function when a
> socket is readable or writable. I was planning on registering the
> appropriate callback on these errors. What I needed to know was whether
> the underlying code could cope with this behavior. It sounds like it
> can.
> Question: if I call SSL_write, get WANT_READ, register a callback for
> the socket being readable, then call SSL_read, get WANT_READ, and
> register another callback, does it matter if I recall them in the
> opposite order? ie, when the socket is readable call SSL_read then
> SSL_write?
The order does not matter. If a handshake is currently going on,
either of these functions will continue the handshake before
attempting to handle application data. Also it is not harmful to call
SSL_read or SSL_write when you know the the SSL_ERROR_WANT_...
condition is not yet satisfied -- you just have to make sure that you
avoid busy waiting, and that the functions are finally called when
their conditions are fulfilled.
The event-based callback approach will work if no events are ever lost
(i.e. if, whenever one of the socket condition becomes true, all
waiting handlers for that condition are scheduled to be called).
However, if conditions are only tested while none of the handlers is
running, it will not work -- then you have the problem described above
that the first function's SSL_ERROR code may no longer be true after
the call to the second function.
>> The solution is to look at the underlying BIO layer. Before trying
>> SSL_read and SSL_write, record BIO_numer_read(rbio) and
>> BIO_number_written(wbio), where rbio and wbio are initialized
>> as SSL_get_rbio(ssl) and SSL_get_wbio(ssl), respectively.
>> Then call SSL_read and SSL_write. If it is not obvious whether
>> there was any protocol progress (i.e. if you get
>> SSL_ERROR_WANT_READ/WRITE for both calls), then by calling
>> BIO_number_read(rbio) and BIO_number_written(wbio) and comparing
>> these figures with the previous values you can find out whether
>> anything has happened. If one of the values has changed,
>> you can just enter another iteration of the loop without
>> risking busy waiting. If, on the other hand, both values
>> are the same as before SSL_read and SSL_write, then you can
>> be sure that the SSL_ERROR_WANT_READ/WRITE from the first of
>> these SSL_... operations is still valid; so you can select()
>> for the combination of the two SSL_ERROR_WANT_... codes.
>> Looking at the source code of other existing TLS proxies and
>> finding out how they can fail is left as an exercise.
>> If they don't evaluate BIO_number_read() and BIO_number_written(),
>> then probably they're buggy (or their use is restricted to
>> protocols where concurrent I/O in both directions is not
>> possible).
> Could you point me at one of these opensource proxies?
See pointers at <URL: http://www.openssl.org/related/apps.html>.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
