RE: Man In The Middle Attacks and STARTTLS

["Scott Roberts (Exchange)" <scotro@xxxxxxxxxxxxxxxxxxxxxx>]

As long as the client requires a specific security level to be reached
before sending the message, which is outlined in the RFC, the message will
never be sent. The MITM in the middle attack would still cause havoc but it
would be the same havoc as if the transaction was in the clear-text. At
least the successful TLS negotiation will ensure that the message will be
sent to the correct server encrypted. An incorrectly implemented Firewall
could fall into the MITM category.

Scott
> -----Original Message-----
> From: Dan Wing [mailto:dwing@xxxxxxxxx]
> Sent: Thursday, April 15, 1999 2:01 PM
> To: Paul Hoffman / IMC
> Cc: ietf-apps-tls@xxxxxxx
> Subject: Re: Man In The Middle Attacks and STARTTLS
> 
> 
> On Thu, 15 Apr 1999 12:02 -0700, Paul Hoffman / IMC wrote:
> 
> I think you can protect against this attack, but you do need 
> to describe
> how in the security considerations section.
> 
> To protect against the MITM attack you describe below, the 
> client needs to
> treat "454 TLS not available due to temporary reason"  
> exactly the same as
> a missing "250 STARTTLS" from the EHLO response.
> 
> -Dan Wing
> 
> > 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.
> > 
> > If you have an MITM attacker, they can (a) delete important 
> parts of one or 
> > both sides of the conversation, (b) insert sides of the 
> conversation and/or 
> > (c) change parts of the conversation.
> > 
> > RFC 2487 only looked at (a). If the attacker deleted the 
> "250 STARTTLS" 
> > line from the ESMTP response, the client wouldn't know to 
> start a TLS 
> > session; the recommendation was to remember which servers 
> had said that 
> > they did STARTTLS in the past and make some decision based 
> seeing that 
> > change to the server now not saying that it does STARTTLS.
> > 
> > However, 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.
> > 
> > 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.
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
>