[tpop3d-discuss] SSL support

[Angel Marin]

> -----Mensaje original-----
> 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?

Yes, is a strange behaviour, but it happends. It is more frecuent when the
cliente is in the same network segment as the server. I dont know why, but
connection do not close sometimes and it doesnt matter what you do.

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

Using a non-blocking IO may cause the unspected behaviour decribed above.
Otherwise it may be a good idea reviewing other applicacions source.

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

Perhaps rehandshake is not timed out but frecuency betwing rehandshakes may
be checked.