What happens if STARTTLS dropped in SMTP?

Question

SMTP uses STARTTLS extension to upgrade SMTP to SMTP Secure (STMPS). According the the RFC, the client and server starts TLS as follows:

S: <waits for connection on TCP port 25>
   C: <opens connection>
   S: 220 mail.imc.org SMTP service ready
   C: EHLO mail.example.com
   S: 250-mail.imc.org offers a warm hug of welcome
   S: 250-8BITMIME
   S: 250-STARTTLS
   S: 250 DSN
   C: STARTTLS
   S: 220 Go ahead
   C: <starts TLS negotiation>
   C & S: <negotiate a TLS session>
   C & S: <check result of negotiation>
   C: EHLO mail.example.com
   S: 250-mail.imc.org touches your hand gently for a moment
   S: 250-8BITMIME
   S: 250 DSN

In the same document, the specs mention the possibility of MITM:

A man-in-the-middle attack can be launched by deleting the "250 STARTTLS" response from the server.

What I do not get it from the specs is: What delete exactly means? is it deleting the content of the message but sending it empty? (i.e. corrupting it) or dropping it so the client does not receive it?

If it means dropping the message so the client does not receive it, will the server send 250 DSN ? it is not clear to me if 250-STARTTLS dropped what is the next message going to be? how the client gets to know that it must send EHLO mail.example.com and that there is not 250-STARTTLS?

Steffen Ullrich · Accepted Answer · 2017-09-08T07:29:53.097

SMTP with STARTTLS works by first creating a plain connection to the server and then upgrading it to TLS if the server supports it. The server shows support for STARTTLS within the response to the EHLO command. A man in the middle could simply modify the response from the server and remove the information that it supports STARTTLS. In this case the client believes that STARTTLS is not supported and will not upgrade TLS.

For example the original SMTP dialog might look like this:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 STARTTLS

From this the client will know that STARTTLS is support. A man in the middle or a firewall like Cisco ASA (but also others) might modify the response to make the client believe that TLS is not supported in order to inspect the traffic in plain:

  << 220 welcome to example.org
  >> EHLO example.com
  << 250-example.org 
  << 250-HELP
  << 250-8BITMIME
  << 250 XXXXXXXX

Due to this modification (in this case replacing STARTTLS with XXXXXXXX) the client is not aware that the server supports TLS and thus will not try it. Even if the client still tries it the man in the middle could rewrite the STARTTLS command of the client into some other (maybe invalid) command so that the server seems to refuse the STARTTLS.

Note that the exact behavior in this case depends on the client configuration. While end user applications (i.e. MUA - mail user agent) are often configured to enforce TLS with the single configured mail server they use this is different with MTA (mail server - mail transfer agent) to MTA communication. MTA's usually don't know up front which next hop in delivery will support TLS so they just check if TLS is possible but continue in plain if it does not look like TLS is possible.

In summary: opportunistic encryption like this is a bad idea since a man in the middle can simply make both sides believe that the other side does not support encryption.

Man in the middle can make both sides believe that other side does not support encryption, but as long as client is configured to only accept encrypted connection (reject connection when no starttls is available), mitm could only cause denial of service. — yyy, Sep 08 '17 at 07:08
Thanks for the detailed answer. But my question was on the exact nature of modifying the 250 STARTTLS. If the MITM just dropped the message so the client did not get it at all, will the client still continue the handshake in clear? or will it fail? — user6875880, Sep 08 '17 at 07:22
@yyy: MUA (i.e. end user applications) usually only have one outgoing mail server and are commonly configured to enforce TLS or use SMTPS (i.e. implicit TLS from start) instead of STARTTLS. MTA (i.e. mail server to mail server) instead are usually configured with to use TLS only if available since they don't know up-front which MX supports TLS at all. — Steffen Ullrich, Sep 08 '17 at 07:23
@user6875880: I don't what you mean with "dropped the message". But, it should be visible from my example that the man in the middle *modifies* the original response so that the client believes that the server does not support STARTTLS. If the client continues in clear or abandons the connection depends on the configuration - but MTA's are usually configured for opportunistic encryption and thus just continue in plain. — Steffen Ullrich, Sep 08 '17 at 07:26

LSerni · Answer 2 · 2017-09-08T09:46:38.103

The man-in-the-middle sits between you and the SMTP server and hides the server capability broadcast of 250-STARTTLS (that's what deleting the "250 STARTTLS" response from the server means).

Therefore, the client will not know that TLS is possible; it will not attempt TLS; and if the client has not been instructed to require it, the conversation will follow in the clear, and the MitM will be able to read it at its leisure.

Usually, mail clients can be configured as "STARTTLS if available", "STARTTLS", "plain" and so on. In the interests of user experience, the first is often the default ("keep mail flowing no matter what"). In the interests of security, the second option is clearly better.

What happens if STARTTLS dropped in SMTP?

2 Answers2