Subject: [dane] SMTP STARTTLS stripping in the wild

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Nov 2014 14:59:04 -0500 (EST)

https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks

 	"In recent months, researchers have reported ISPs in the US and Thailand
 	 intercepting their customers' data to strip a security flag—called
 	 STARTTLS—from email traffic."

Thanks to Viktor, properly configured postfix clients deployed with DANE should
detect this and refuse to send the email unencrypted.

Paul

---

From: "John Levine" <[email-masked]>
Date: 14 Nov 2014 00:43:13 -0000

>detect this and refuse to send the email unencrypted.

This is an anti-spam measure on port 25 traffic on a few mobile
networks.  I expect there aren't a lot of copies of Postfix running
on mobile devices.  For all those other mobile users, if they're
configured correctly they're submitting over port 587 or 465, and
nobody tries to filter that.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Nov 2014 00:52:53 +0000

> nobody tries to filter that.

Indeed most such configurations are likely to have similarly mundane
explanations.  I used Paul's message as an excuse for a marketing
message, but forgot to voice my skepticism as to whether this is
an actual attack at work.

I am far more curious about what happened to Google's outbound
TLS mail stats around Oct 14th:

    https://www.google.com/transparencyreport/saferemail/

but this seems likely to remain a mystery.  Perhaps some large peer
botched their TLS settings?

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 13 Nov 2014 20:11:16 -0500 (EST)

On Thu, 14 Nov 2014, John Levine wrote:

> networks.

With friends like these,....

It's time for opportunistic encryption to kick in against "helpful"
rewriting of people's packets.

This also fits in with today's human rights presentation at SAAG. This
kind of downgrade attack would be candy for oppressive regimes.

> I expect there aren't a lot of copies of Postfix running

You are wrongly assuming all must clients relay via another location.
(yes I know, you say reality, I say morality)

Paul

---

From: "John R Levine" <[email-masked]>
Date: 13 Nov 2014 15:19:19 -1000

> (yes I know, you say reality, I say morality)

As I pointed out in another context, an ISP can trivially create an 
EFF-compatible spam filter by hijacking all port 25 sessions to its own 
mail server, which does STARTTLS.

There are problems that need solving.  This is not one of them.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Chris Newman <[email-masked]>
Date: Thu, 13 Nov 2014 15:57:05 -1000

> botched their TLS settings?

My speculation:

There's no specification for SMTP relay fallback from STARTTLS to cleartext. So
if a provider turns on fully RFC 3207 client-side STARTTLS for relay and that
software doesn't also implement the unspecified fallback, it will stop the flow
of mail to peers that advertise STARTTLS but implement it incorrectly. Once the
queue buildup is noticed, the client-side site has to:
1. turn off client-side STARTTLS
2. upgrade to a software version implementing the unspecified protocol, if
available.
3. manually configure no-STARTTLS for each endpoint that has a broken STARTTLS
implementation.
4. bounce mail to legitimate recipients with a bogus STARTTLS implementation.

Incidentally, I suspect 1 is a common service provider response to this
situation.

		- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Nov 2014 02:27:16 +0000

On Thu, Nov 13, 2014 at 03:57:05PM -1000, Chris Newman wrote:

> There's no specification for SMTP relay fallback from STARTTLS to cleartext.

Correct, Sendmail defers the mail, while Postfix falls back to
cleartext (eventually).

> So if a provider turns on fully RFC 3207 client-side STARTTLS for relay

Google is the sender in this case.  The drop in TLS traffic started
on Oct 7th, fell sharply on the 11th and ended on Oct 15th.  Outbound
TLS support at Google is far from new.

> and that
> of mail to peers that advertise STARTTLS but implement it incorrectly.

So I think you're saying that Google may have disabled its previous
STARTTLS to cleartext fallback, and after a few days found that a
lot of mail got deferred.  And that point either selectively or
globally re-enabled fallback?

I'd have hoped they would notice a lot sooner, the drop is from
75% to 50% of mail using TLS.  If the missing TLS mail is queued,
that would rapidly lead to enourmous mail backlogs.  It seems far
more likely that some remote peer broke their TLS, or Google tried
some fancy TLS settings, and ran into interoperability issues.  In
either case Google likely then delivered in cleartext.

> Once the queue buildup is noticed, the client-side site has to:
>

Note what happened at Google, since the TLS rate did not go to zero.

> 4. bounce mail to legitimate recipients with a bogus STARTTLS implementation.

They probably had cleartext fallback all along, and I think deferred
mail at that volume would have been noticed rather quickly.

> Incidentally, I suspect 1 is a common service provider response to this

That is rather plausible.

-- 
	Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 22:22:07 -0500

John Levine <[email-masked]> wrote:
    >> "In recent months, researchers have reported ISPs in the US and
    >> Thailand intercepting their customers' data to strip a security
    >> flag—called STARTTLS—from email traffic."
    >> 
    >> Thanks to Viktor, properly configured postfix clients deployed with
    >> DANE should detect this and refuse to send the email unencrypted.

    > networks.  I expect there aren't a lot of copies of Postfix running on
    > mobile devices.  For all those other mobile users, if they're

Any person with a laptop with postfix on it being "tethered" might do this.
I do it regularly; I don't do direct delivery, but do authenticated (via
STARTTLS cert) relaying to a machine in the cloud... I have been using port
26 for this for a decade plus due to port 25 being blocked.

While the submit port might make sense, it was easier to configure this
as straight SMTP.

At least, if this happened to me, the relay would refuse to accept my email,
since it wasn't authenticated; I don't think that I force TLS on the client,
but I probably could.

It's not unusual for an entire office to wind up tethered to someone's mobile
device (or mifi) when a backhoe event occurs.

{and I'm happy to relay for friends and family}

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-