Re: IMAPS problems...
- From: Carlos Morgado <chbm chbm nu>
- To: Balsa List <balsa-list gnome org>
- Subject: Re: IMAPS problems...
- Date: Wed, 22 Aug 2001 18:10:39 +0100
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
> > > 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
> > > and should be smashed up into little pieces and banished to the
> > >
> > 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.
[ ] 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
> 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. ;)
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
] [Thread Prev