On Sat, May 23, 2009 at 05:30:54AM -0700, David Schwartz wrote:
Let me start out by saying I think you're correct on most of your
points, and I was incorrect. But I do want to clarify one issue.
> Set SSL_ACCEPT_MOVING_WRITE_BUFFER. The only requirement then is that you
> not try to "unwrite" data.
Here is the additional unpleasant requirement I believe I've observed.
I have two basically independent directions of data flow, which is unlike
most applications that run on top of SSL, since most of those seem to be
request/response protocols (e.g. HTTP or IMAP). So at any time, I might
initiate either an SSL_read() or an SSL_write() towards the peer.
Here is what I have seen go wrong at renegotiation time, which led me to
try to apply my (incorrect, as you've pointed out) rule:
1) I SSL_read(). It returns -1, WANT_READ.
2) Independently, I SSL_write(). Since a renegotiation is in progress,
it *also* returns -1, WANT_READ.
3) I select for read-ready, since OpenSSL told me to do so.
4) Now I reissue the SSL_read() (I intend to next do the SSL_write() of
course, since it is waiting for read too).
At this point, I have observed each of:
A) Protocol violations on the wire (bad SSL records).
B) SSL_ERROR_SSL from subsequent SSL_read() or SSL_write()
calls on my side.
With older versions of OpenSSL -- I haven't tested lately. I think now
I need to go write some simple test cases.
I know that in ordinary operation, if I get WANT_READ from SSL_read()
it's safe to continue to call SSL_write(). But it appears to me that
if the WANT_READ from SSL_read() was caused by a renegotiation, if I
do some other API call next, chaos ensues.
And I cannot tell WANT_READ caused by a renegotiation apart from
WANT_READ caused by no-data-ready, so whatever heuristic I use to work
around this, I have to apply it all the time. Obviously the same thing
applies with SSL_write() and an initial WANT_WRITE.
I take it it's not _supposed to_ be this way. Do you agree?
Thor
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
