Re: IMAPS problems...

[Brian Stafford <brian stafford uklinux net>]

> > One potential problem though is if the server offers STARTTLS, it may
> > require
> > the client certificate for authentication.  The only way to get it is to
> > negotiate TLS.  However a correctly implemented client ignores STARTTLS
> > because its already using TLS via sslwrapper!  In this case the server will
> > refuse to authenticate the client even though sslwrapper/stunnel was
> > perfectly happy with the client certificate.
> > 
> about the same case as LOGINDISABLE STARTTLS over imap.

Well when either STARTTLS or SASL is available, the IMAP LOGIN command
must be disabled because it bypasses the higher quality mechanisms, i.e.
X.509 certificate based authentication and SASL.

> i don't think we support client certs at this point though ;)

I was writing code for this and other TLS related stuff last night.
Christophe's plight with tunnelling finally goaded me into action on the
TLS and certificate handling area.  Getting encryption is easy.  Getting
session information like the cipher is easy.  Loading the client certificate
is easy.  Getting hold of the server cerificiate is easy.  Validating the
server certificate CA chain is easy.  But reading the X.509v3 extensions ...
not so simple.  I'm trying to figure out how to read the subjectAltName from
the server certificate ... aargh!

> > Methinks that SSL/TLS tunnels, port forwarding etc. are menaces to society
> > and should be smashed up into little pieces and banished to the wilderness.
> > 
> i'm thinking radio buttons instead of the current "Use SSL"
> 
> * IMAP TLS
> * SSL (imaps)

Dont forget TLS is really just the next version of SSL after SSLv3.
Both imaps on the "secure" port or standard imap negotiating in the
STARTTLS command can end up using SSLv2, SSLv3 or TLSv1.

In libESMTP the options are Use TLS: never/if possible/always.  Since I
don't implement ssmtp the alternative "secure" port is not a problem.
However I figure the correct strategy if the user wants a secure connection
is to first try the standard port and see if STARTTLS is offered.  If not
try the "secure" port.  I feel that this strategy should be automatic and not
a user option.  If clicking on an imaps: url, we know in advance that the
secure port is to be used, so go straight to that using SSL/TLS

> and then i have to read about SASL and session encription with SASL. sigh.

And again a properly inplemented client will not negotiate encryption in the
SASL exchange if SSL/TLS is already in use. ;)

Brian