[tpop3d-discuss] SSL support

[Chris Lightfoot]

On Sun, Jun 16, 2002 at 04:10:56PM +0200, Angel Marin wrote:

    [ handling of disconnects ]

> That is the espected behaviour, but I dont know why all this kind of
> programs keep some connections on CLOSE_WAIT state forever unless process
> exits. Many of them although suffer from these its not an issue as they are
> called from (x)inetd and die with the connection. Perhaps it is an OpenSSL
> problem that do not report the correct error sometimes, but
> SSL_ERROR_SYSCALL is reported mani times at the end of a transaction and
> connection does not close propertly.

Hmm. Is this occurring even if you call shutdown and close
on the socket?

    [ _WANT_READ / _WANT_WRITE ]
> > > It was in the thing I already had to implement, and it should not be a big
> > > problem I think.
> >
> > Errm. It's a bit more complicated than that. If your code
> > calls SSL_read and it returns 0 with SSL_WANT_READ,
> > xread_ssl will pass the 0 back to tpop3d, which will drop
> > the connection. What needs to be done (at least) is to add
> > a send buffer to the connection object and select-for-write
> > as well as for read. Then it requires thinking about the
> > SSL state machine some more. The helper process model is
> > much easier and less prone to trouble.
> 
> Of course, in my first post I said that it might be reimplemented. Once
> rewritten similar to xwrite_ssl you can implement a function thar handles
> rehandshake sittuations and call it in SSL_WANT_READ case.

Errm. I don't think that will work. Rehandshaking is
handled internally to OpenSSL but requires that reads and
writes be done on the socket. This means that we have to
use non-blocking IO so that we can drop back into the
select loop. At present tpop3d relies on operating system
buffering for all writes to clients; arguably this is bad,
but in reality it works fine. Adding SSL makes this more
complicated. It's not a catastrophic change, and perhaps
would be a better way to handle it.

> > > Another way of ahdling th same would be: From SSL_CTX_set_mode(3)
> > >
> > > SSL_MODE_AUTO_RETRY
> >     [...]
> > > I will investigate if this solves the problem :)
> >
> > Nope-- it's no good. The problem is that a malicious
> > client can always force renegotiation, then not send the
> > proper responses to the server. This would mean that
> > tpop3d would block indefinitely on SSL_write.
> 
> I agree, but it might be handled by ssl library, if it allows permanent
> rehandshakes it is a flaw.

I'm no expert on SSL, but my guess is that there's no
reason that a rehandshake ought to be timed out any faster
than a TCP connection is timed out, and that's quite a
long time. The reason that a problem occurs here is that
SSL is not compatible with the blocking IO + select model
which tpop3d (and many other programs) use. It would be
trivial to implement SSL support if tpop3d forked on
accept.


I'm going to be away for a bit in the land-beyond-email,
so I'll come back to this in about a week with whatever
thoughts I've had by then....

-- 
``Do we really need two North Dakotas?
  I mean, we already have South Dakota as an emergency spare.'' (Scott Adams)