Re: Non-blocking SSL shutdown

2007-10-16 Thread Nanno Langstraat
Darryl Miles wrote: David Schwartz wrote: Why are you doing a shutdown(WR) in response to a read()=0 ? Euh! [...] Did you miss the "on the local drain file descriptor" part? No. read()=0 means the shutdown(WR) was performed on the remote end! Darryl, David Schwartz tries to point out that

Re: Non-blocking SSL shutdown

2007-10-16 Thread Darryl Miles
David Schwartz wrote: Nanno Langstraat wrote: * Our TCP proxy gets read()==0 on the TCP socket. * In response, our proxy does shutdown(WR) on the local drain file descriptor (the other side of the proxy). This propagates the "read()==0" event to the local endpoint process t

RE: Non-blocking SSL shutdown

2007-10-16 Thread David Schwartz
> I want to repeat: it's also OK by me if the documentation *explicitly* > says somewhere > > "SSL can not operate half-duplex like TCP can. SSL_read()==0 means > the connection is truly dead. You should not do SSL_write() anymore, > and you can not use the results of SSL_want*() anymo

RE: Non-blocking SSL shutdown

2007-10-16 Thread David Schwartz
> Nanno Langstraat wrote: > >* Remote side completely closes its socket. > This causes read()=0 and write()=-1/EPIPE on the local side. > > > > >* Our TCP proxy gets read()==0 on the TCP socket. > > > >* In response, our proxy does shutdown(WR) on the local drain file > > descrip

Re: Non-blocking SSL shutdown

2007-10-16 Thread Darryl Miles
Nanno Langstraat wrote: * Remote side completely closes its socket. This causes read()=0 and write()=-1/EPIPE on the local side. * Our TCP proxy gets read()==0 on the TCP socket. * In response, our proxy does shutdown(WR) on the local drain file descriptor (the other side of

Re: Non-blocking SSL shutdown

2007-10-16 Thread Darryl Miles
Nanno Langstraat wrote: That's the very reason Darryl Miles asked me to change the thread title, if you'll remember. LOL, but you also have to remove your References: header, but still too late now. This is still in the same thread, to start a new thread post a new email (do not use the Repl

Re: Non-blocking SSL shutdown

2007-10-16 Thread Nanno Langstraat
David Schwartz wrote: 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. This is ins

Re: Non-blocking SSL shutdown

2007-10-16 Thread Nanno Langstraat
Thor Lancelot Simon wrote: On Tue, Oct 16, 2007 at 02:41:15AM +0200, Nanno Langstraat wrote: 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. That's unreasonable, particularly

Re: Non-blocking SSL shutdown

2007-10-16 Thread Darryl Miles
David Schwartz wrote: This is insane. Imagine if SSL_want_read and SSL_want_write both returned false. Then you wouldn't ever notice that the socket had been closed, you could wait for new inbound data forever, and your proxy would stall. But end-of-stream is an error condition, so you should b

RE: Non-blocking SSL shutdown

2007-10-15 Thread David Schwartz
The scenario you are describing is simply impossible. > 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. True. > The half-

Re: Non-blocking SSL shutdown

2007-10-15 Thread Thor Lancelot Simon
On Tue, Oct 16, 2007 at 02:41:15AM +0200, Nanno Langstraat wrote: > > 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. That's unreasonable, particularly because you're asking for the

Re: Non-blocking SSL shutdown

2007-10-15 Thread Nanno Langstraat
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

RE: Non-blocking SSL shutdown

2007-10-15 Thread David Schwartz
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 f

Re: Non-blocking SSL shutdown

2007-10-15 Thread Nanno Langstraat
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 fo

RE: Non-blocking SSL shutdown

2007-10-15 Thread David Schwartz
> TCP can do half-duplex connections (read side shut down, write side > still operating). > OpenSSL can not do half-duplex connections. True. > 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 h

Re: Non-blocking SSL shutdown

2007-10-15 Thread Nanno Langstraat
David Schwartz wrote: Nanno Langstraat: Quote chapter and verse of the OpenSSL API documentation, or desist from such vehement statements. You can not scold an API user for violating rules that are not in the documentation. OpenSSL does its best to document where it fails to make SSL c

Re: Non-blocking SSL shutdown

2007-10-15 Thread Nanno Langstraat
Darryl Miles wrote: The SSL_want() man page indicates it does not account for errors or any other special overriding circumstances and the values only make sense when the SSL channel is in a normal condition. I'm sure you will agree that SSL channel is not in a normal state as soon as it star

Re: Non-blocking SSL shutdown

2007-10-15 Thread Darryl Miles
Nanno Langstraat wrote: Can we agree on the convention that as long as no OpenSSL call has returned -1, there is no error condition in effect, at least as far as the application knows? Nope. A return value of 0 from SSL_read() is also a special case. The same is true of the kernel call rea

Re: Non-blocking SSL shutdown

2007-10-15 Thread Nanno Langstraat
Darryl Miles wrote: Nanno Langstraat wrote: It turns out that the problem does *not* directly involve SSL_shutdown(), but it *is* attributable to OpenSSL, and specifically OpenSSL's non-blocking shutdown semantics. Okat thats cleared that up, it is indeed unrelated to the OP of this thread.