Re: [dane] SMTP STARTTLS stripping in the wild

[Chris Newman <[e-mail]>]

--On November 14, 2014 0:52:53 +0000 Viktor Dukhovni <[e-mail]>
wrote:
> On Fri, Nov 14, 2014 at 12:43:13AM -0000, John Levine wrote:
>> > https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
>> 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.
> 
> 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?

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