[tpop3d-discuss] SSL support

[Angel Marin]

> -----Mensaje original-----
> On Sun, Jun 16, 2002 at 12:13:48PM +0200, Angel Marin wrote:
> > I have started the development of the ssl support for tpop3d. I have a
> > working snapshot, but its only an starting point of what shoud be. So if
> > anybody whants to test it and send problems/bugs/suggestions I
> will do my
> > best to improve it.
>
> Thanks for your contribution, but there's a serious
> problem with this patch which also applies to Ben
> Schumacher's earlier patch, which is that a call to
> SSL_write may block on a read from the client, if it has
> requested renegotiation. This means, in effect, that you
> can't safely mix blocking calls to SSL_read and SSL_write
> with the use of select(2). This is fine during the
> transaction phase, but no good during the authentication
> phase.
>
> See
>
> http://lists.beasts.org/pipermail/tpop3d-discuss/2002-January/000380.html
>

Oops i should have revised better the list archives before :/

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

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.


Another way of ahdling th same would be: From SSL_CTX_set_mode(3)

SSL_MODE_AUTO_RETRY
           Never bother the application with retries if the transport is
blocking.  If a renegotiation
           take place during normal operation, a SSL_read(3) or SSL_write(3)
would return with -1 and
           indicate the need to retry with SSL_ERROR_WANT_READ.  In a
non-blocking environment
           applications must be prepared to handle incomplete read/write
operations.  In a blocking
           environment, applications are not always prepared to deal with
read/write operations
           returning without success report. The flag SSL_MODE_AUTO_RETRY
will cause read/write
           operations to only return after the handshake and successful
completion.

The worse thing is:

HISTORY
       SSL_MODE_AUTO_RETRY as been added in OpenSSL 0.9.6

I will investigate if this solves the problem :)

Angel