Replies below vvvvv
Thor Lancelot Simon wrote:
The pattern is like this:
1) I have data to write, and the SSL session's descriptor
selects as ready-to-write.
2) I call SSL_renegotiate. I do understand that in a server
application this merely sends the client a request to
do a new handshake, which the client can ignore.
3) I generate more data and several more SSL_writes() complete
normally.
4) Eventualy the SSL session's file descriptor selects as
ready-to-read.
5) I call SSL_read with a 4096-byte buffer. SSL_read returns
-1 and error is SSL_ERROR_WANT_READ.
6) I set a flag to ensure I do not call SSL_write() (it isn't
clear to me this is necessary -- the documentation is vague)
and select on the SSL session's descriptor for read.
It should not be, the OpenSSL API should gracefully handle a SSL_write()
it doesn't want just yet.
7) The SSL session's file descriptor selects as ready for read,
I call SSL with the same 4096 byte buffer at the same address,
and SSL_read returns -1 and error is SSL_ERROR_SSL.
SSL_ERROR_SSL as I'm sure you know is for a protocol level error this
should never happen (no matter how hard you attempt abuse the
application level APIs). Presumptions aside (such as both ends support
and can agree on exactly which encryption/MAC and other things they will
both use).
It should only report this problem when the other end violates the
protocol specification. Since both ends are OpenSSL this there is a bug
somewhere in OpenSSL.
I cannot understand why #7 occurs. Is SSL_MODE_ENABLE_PARTIAL_WRITE just
incompatible with non-blocking mode and renegotiations?
It is possible it relies on the behavior as if
SSL_MODE_ENABLE_PARTIAL_WRITE was not set.
SSL_MODE_ENABLE_PARTIAL_WRITE was probably added as an after thought to
the behavior without.
Do you have a minimal testcase application that can be started up as
either the A or B end and with and without the PARTIAL_WRITE options in use.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
