CertaDNS
Skip to lesson

The Transport Problem · lesson 1 of 2

What opportunistic TLS leaves open

After this lesson you can

Describe the downgrade an on-path attacker performs, and why the sender never notices.

Most mail between servers is encrypted, and the encryption is worth almost nothing against an attacker who is on the path. Understanding exactly why is the whole basis for everything in this course.

How STARTTLS works

Sender                          Receiver
  |-- connect on port 25 ---------->|
  |<------- 220 mx.example ESMTP ---|
  |-- EHLO sender.example --------->|
  |<------- 250-STARTTLS -----------|   "I support TLS"
  |-- STARTTLS -------------------->|
  |<------- 220 Ready --------------|
  |===== TLS handshake ============>|
  |===== message, encrypted =======>|

The negotiation happens in cleartext, and the decision to use TLS is made entirely on the strength of the receiver advertising it. RFC 3207 specifies exactly this.

The downgrade

An attacker between the two servers removes STARTTLS from the capability list. The sender sees a receiver that does not support TLS, does the only thing it can, and delivers in cleartext.

  |-- EHLO sender.example --------->|
  |<--- 250-SIZE 35882577 ----------|   STARTTLS quietly removed
  |-- MAIL FROM: ... -------------->|   in the clear
  |-- DATA ------------------------>|   in the clear
  • Nothing fails. The message is delivered. Both parties consider the transaction successful.
  • Nothing is logged as a problem. A sender that delivered in cleartext to a server that appeared not to support TLS did the right thing.
  • The certificate is not the issue. The attacker never has to present one, because no TLS session is ever attempted.

The second gap

Even when TLS is negotiated, sending MTAs have historically not validated the certificate — an expired, self-signed or entirely unrelated certificate is accepted, because rejecting it would mean bouncing mail that would otherwise have been delivered in the clear. So an on-path attacker can also answer the connection themselves with any certificate at all.

Opportunistic means exactly what it says

TLS is used if it appears to be available, with whatever certificate is presented. It protects against passive interception, which is a real threat and the reason it is worth having. It does not protect against anyone who can modify the traffic, and it was never designed to.

What would fix it

The sender needs to know, before connecting, that this receiver requires TLS and which certificate identity to expect — information that cannot come from the connection itself, because the connection is what the attacker controls. It has to come from somewhere else, authenticated independently. That is the problem MTA-STS and DANE both solve, by different means.

Last reviewed