[tpop3d-discuss] SSL support

[Angel Marin]

> -----Mensaje original-----
> On Sun, Jun 16, 2002 at 01:51:14PM +0200, Angel Marin wrote:
> > > -----Mensaje original-----
>     [...]
> > > The intention for enabling TLS support in tpop3d is to
> > > have it fork a helper process to do the TLS stuff (one
> > > could also use a thread, but let's not go there...). This
> > > is plenty ugly but probably preferable to implementing the
> > > horrid TLS state machine inside tpop3d. The actual proxy
> > > code for tpop3d would be something like proxy.c from
> > > tlsproxyd.
> >
> > The problem then may be the correct interaction of this two
> proceses in lets
> > say the case the peer disconects, or an ssl error happens. With
> the aproach
> > of tlsproxyd code or of any other product that does ssl proxing the
> > connections are not closed propertly in many cases (most of
> them are cused
> > by buggy clients) until the process dies (which is not our case, as it
> > should be handlad by a single process).
>
> Well... in the case that the peer disconnects, the helper
> process will see a return of 0 from read or SSL_read will
> indicate a closed connection; in this condition the helper
> process should close the connection to tpop3d and exit.
> Similarly for the case where tpop3d closes its connection.
> Other cases are handled, as at present, by timeouts. I
> don't think that this is a critical problem with this
> model.

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.

>
> > In my opinion its cleaner to implement it with blocking calls
> of SSL_write
> > an SSL_read and on SSL_ERROR_WANT_READ implementing the code to
> deal with
> > renegociation.
> >
> > 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.

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

Angel.