Nanno Langstraat wrote:

> 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.


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.

> 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'.


Okay. You can be new to OpenSSL, but you have to understand SSL in detail to
use *any* SSL library.

> 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.


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.

> 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.


It's true that we don't care what the peer might do.

> 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.


I'm not sure how we could do this, since it's not clear to me what a
half-duplex SSL connection would be. But okay.

> 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.

> 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.


Okay.

> Do you feel that you and I are now bad programmers when we follow this
> path? I don't.


So what's the problem? As soon as our first call to SSL_write also fails,
we'll correctly terminate.

Are you assuming we continue to call SSL_read even though it has indicated a
fatal error? That would be our bad. Are you assuming we keep the connection
open just to send data and then never call SSL_write? That would be our bad
too.

What's the problem with this?

DS


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org