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 [EMAIL PROTECTED]
