[tpop3d-discuss] SSL support

[Chris Lightfoot]

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.

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

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

-- 
``If you talk about fish to a starving man, then you're a consultant.''
  (seen on the internet)