David Schwartz wrote:
You have to be extremely familiar with SSL internals to be able to use
OpenSSL. This is a fact that is ignored to everyone's peril.
[...]
Okay. You can be new to OpenSSL, but you have to understand SSL in detail to
use *any* SSL library.
[...]
We wouldn't know whether there is some API to do that. But we would know
about SSL's record logic and how negotitation requires a back and forth
exchange. You can't use SSL without understanding SSL negotiation. So we
would know that a simplex SSL connection is a contradiction in terms.
I'll agree that there is give-and-take in any library API. But requiring
*that* level of very intricate internal knowledge *and* deduction from
the bog-standard user of a library is frankly perverse. It defeats the
entire purpose of having a library and an abstract API in the first place.
All the more because such hardship is easily avoidable in cases such as
this.
If you say "We know both SSL and OpenSSL are far from cuddly and will
always have pitfalls, but we will either fix this behaviour or document
it for the next hapless sap to avoid", that's utterly fine.
If you say "The OpenSSL project is becoming comatose, we need
contributors, could you provide a (documentation or code) patch for
this", that's utterly fine.
But instead insisting that it is normal that all new normal users should
forever more divine OpenSSL's undocumented API rules including this one
by individually counting every comma in a standards draft that's 473
pages long, is indefensible. (apologies to Linus Torvalds for lifting
that quote)
When the remote peer has closed the downstream direction, we will keep
doing SSL_write() calls with the upstream data entrusted to us, until
SSL_write() also indicates no-go.
So the scenario is that 'read' has indicated normal closure and we are
attempting to write some last data. Fine.
[...]
So what's the problem? As soon as our first call to SSL_write also fails,
we'll correctly terminate.
It is possible (even very likely) that the upstream plaintext buffer in
the "stunnel-like half-duplex-handling proxy application" happens to be
empty, but that the local plaintext source file descriptor is still open.
The half-duplex-handling proxy application that you and I decided to
build says: "Fine, I'll use poll() to sleep until the plaintext source
file descriptor delivers some data that we can then SSL_write()".
So, the proxy event loop that we built so nicely registers the local
plaintext source file descriptor for POLLIN, and it registers the
SSL-TCP file descriptor for POLLIN/POLLOUT guided by
SSL_want_read()/_write(), like it always does. And then it does poll().
At that point we get stung because SSL_want_read() erroneously returned
'true' and we therefore registered the SSL-TCP file descriptor for
POLLIN, even though OpenSSL (and only OpenSSL) knows that the SSL-TCP
file descriptor has already returned read()==0.
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
