Re: Man In The Middle Attacks and STARTTLS

On Thu, Apr 15, 1999 at 12:02:19PM -0700, Paul Hoffman / IMC wrote:

> Greetings again. I thinking about the recent messages, I realized that we 
> have missed a major problem here, one that might not be fixable at all.
> [...]    we missed an attack that uses (b) and/or (c).
> 1) The server says "250 STARTTLS". The attacker lets this go by.
> 2) The client says "STARTTLS". The attacker changes the command to "NOOP" 
> or some other harmless command before the server sees it.
> 3) The server replies to the NOOP. The attacker changes the status reply to 
> "454 TLS not available due to temporary reason" before the client sees it.

> No one suspects anything.

Well, I certainly do :-), was my message of March 26 too vague?  See
the first sentence of my reply:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Date: Fri, 26 Mar 1999 19:43:07 +0100
From: Bodo Moeller <[email protected]>
To: Scott Roberts <[email protected]>
Cc: [email protected], [email protected]
Subject: Re: Interop problem with SMTP STARTTLS and Cisco PIX firewall
Message-ID: <[email protected]>
References: <002f01be77b0$28e49110$01731fac@scotthome>

On Fri, Mar 26, 1999 at 09:43:26AM -0800, Scott Roberts wrote:

> The RFC for STARTTLS has a section for dealing with the middleman attack
> where the client should keep track of each server's TLS and remember the
> last time it was advertised. If a server stops advertising STARTTLS due to
> an invalid certificate or invalid configuration it could lead to false
> security issues and alerts when the problem was just a bad certificate that
> caused it to stop advertising the STARTTLS during the EHLO.

The "454 TLS not available due to temporary reason" answer to STARTTLS
could just as well indicate an MITM attack.  If the server is
misconfigured, it is very unlikely that waiting after the 454 response
will fix the problem (how often do people change their mail server's
configuration?) -- similarly, an incorrect "RCPT TO:" typically will
not generate "451 User does not yet exist" :-)

>     [...] The server will return a '454 TLS not available due to temporary
> reason' to any client that issues the STARTTLS command and fails.  If we do
> not advertise STARTTLS when there is ANY problem with the certificate or
> configuration than why have this error code?

"Temporary reasons" for unavailability of TLS could have several
reasons: E.g., after a reboot the server needs a password to decrypt
its key; or a decrypting smart card was just removed from the
interface because a new one with a new key is to be inserted.
A configuration mistake _might_ be a good reason, but only for limited
time (namely, while someone is working on the configuration: E.g., an
old certificate and key have just been deleted, but the new one is not
yet installed), not for more than, say, one day at most.
I think this proposal makes sense:

>> As I see it the real question is whether the mail can be sent within a
>> reasonable amount of time. If a server has had a working TLS
>> configuration that doesn't work just now then it should advertise
>> STARTTLS but if it has never been configured then it shouldn't. Five
>> days seems to be a common queue return time and so I suggest that if a
>> valid configuration has not existed in the last five days then it can be
>> deemed to have never existed.

This time-out should be configurable, but three days (one weekend) or
five days are probably a reasonable default.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

> I do not see a way around this problem. If no one comes up with a solution, 
> I'll change the security considerations of RFC 2487 to discuss this. And, 
> then, we can move forwards with the correct wording for what to do when a 
> server is not ready to do TLS.