Re: IMAPS problems...

[Carlos Morgado <chbm chbm nu>]

On 2001.08.22 17:54:41 +0100 Brian Stafford wrote:
> 
> > > 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.
> 

erm duh again. i wrote "imap". i meant "imaps". i must get more sleep :\
anyway for "imap" you are totally correct

> > 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!
> 
humm .. skiming over docs i got the impression you just have to put the right
certificates in the right directories and openssl will take care of it.
i suppose i got the wrong idea ? 

> > > 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.
i meant STARTTLS there. it there a better way to put it ?

> Both imaps on the "secure" port or standard imap negotiating in the
> STARTTLS command can end up using SSLv2, SSLv3 or TLSv1.
> 

so,

 [ ] STARTTLS 
 [ ] IMAPS

is more descriptive ?

> 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
> 
ok, that makes sense.
see if STARTTLS is available, if not try imaps on standard port (is there a 
good reason to let the user specify the port here ?).
if none are available and always is selected crap out.

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

hummmm

Use Secure IMAP:
[ ] Always 
[ ] When available, best method
[ ] Never

?
-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A
Software is like sex; it's better when it's free. - Linus Torvalds