David Schwartz wrote:
An innocent OpenSSL API user is not told that OpenSSL can not do
half-duplex connections and that he must not try.
Nonsense. It is impossible for him to try, so it's pointless to warn him not
to. We don't warn people not to become invisible because it's impossible for
people to become invisible. There is no function analogous to
shutdown(SHUT_RD) for SSL connections. No such function exists.
Spoken in the proudest "All the world's a VAX" and "Everyting is obvous
to a professor" traditions.
You have become very familiar with the internal structure and behaviour
of the OpenSSL implementation, but you now appear (to me) to be unable
to recognize things as non-obvious and non-reasonable to an honest new
OpenSSL API programmer.
Nor to consider the involvement of other SSL implementations at the
remote side.
So, I want to reset you: make an honest attempt to place yourself in the
position of a decent, reasonable, diligent programmer new to OpenSSL.
You and I are going to write a simple proxy: tunneling a plaintext file
descriptor over an OpenSSL connection. A bit like 'stunnel'.
--
For starters, we wouldn't know whether a shutdown(SHUT_RD) variant does
or does not exist in some corner of the enormous jungle of the OpenSSL
API. The proxy we're going to build never needs to initiate it. But who
knows whether the remote peer might use some trick of OpenSSL to
initiate it on his end.
But furthermore, who even knows whether the remote peer uses OpenSSL at
all. The remote peer might use some other SSL library that does contain
a function to initiate half-duplex shutdown of SSL connections for all
we know.
So, being diligent programmers committed to not dropping data left in
our care if we can help it, we make the conservative "build for quality"
decision that our proxy will properly handle half-duplex connections,
even though our proxy itself never initiates them.
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.
We find nothing in the OpenSSL documentation that forbids this, so we're
safe to go.
It is understood that OpenSSL takes over the file descriptor of the
underlying TCP connection at the point where we call SSL_set_fd(), and
will do the read() calls from that point on.
Because OpenSSL has now very explicitly assumed ownership of the file
descriptor with SSL_set_fd(), we entirely expect that OpenSSL will take
the state of that file descriptor into account when we call
SSL_want_read()/_write(). Because those two functions exist for the sole
and explicit purpose of assisting in non-blocking I/O select() or poll()
calls. And because there is no other way that we could know.
Do you feel that you and I are now bad programmers when we follow this
path? I don't.
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
