Re: IMAPS problems...

[Brian Stafford <brian stafford uklinux net>]

On Wed, 22 August 16:18 Carlos Morgado wrote:

> ok, clear up, everytime i said 'tunnel' in this discussion i meant ssl 
> connection (imaps). not tunnel as in ssh tunnel. bad choice of word :(

clear now.  sorry about the misunderstanding.

> you connect to imaps, the server presents you with STARTTLS cap, you take it.
> TLS inside a SSL connection.

A correctly implemented client will ignore the STARTTLS capability if it is
already using TLS.

libESMTP does this - its quite possible that a STARTTLS capable server is
behind a STARTTLS wrapper, e.g. stunnel can negotiate STARTTLS using SMTP
and then connect to the real server, which offers STARTTLS.

Incidentally, this is one reason that authentication should be done in a
separate protocol command after negotiating up to the TLS connection.
The SASL EXTERNAL mechanism might be appropriate in this situation where
authentication might depend on credentials previously passed in the certificate.

> i'd say the imap server is beind sslwrapper and doesn't know imaps is being
> used.

Agreed.

> that's why balsa should be smart and not use TLS when it's doing imaps.

Agreed.  IMO, writing code that correctly layers TLS over TLS in one program
would be quite an amazing achievement...

In any case, since there is a variable declared something like
	SSL *ssl;
ignoring the STARTTLS extension when it is offered is as simple as
	extensions = get_protocol_extensions();
	if (ssl != NULL)
		extensions &= ~STARTTLS;
Not exactly rocket science, or even that smart!

> at least, the server config dialog must be updated ..

If a STARTTLS server is available, then unless it is seriously deficient
(or export crippled) it should not be behind sslwrapper, stunnel etc.

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.

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.

Let's stick with properly designed software.

Brian