Re: [dane] SMTP STARTTLS stripping in the wild

[Viktor Dukhovni <[e-mail]>]

[ Resending, as this is not in the list archive, and Google does 
  not seem to find it anywhere.  Perhaps this never made it to the
  list.  I am hoping someone from Comcast will read past the TL;DR to
  the end of the message and deploy real keys for their MX hosts. ]

On Thu, Nov 13, 2014 at 02:59:04PM -0500, Paul Wouters wrote:

> 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.

Thanks for the nod in my direction.  Note however, that we still
need a lot more MTAs to adopt DNSSEC and publish TLSA RRs.  Please
encourage server operators to move forward.

However, my curated list stands at 337 domains, with:

    * 1 with expired RRSIGs
    * 2 with DS RRs that don't match the zone keyset
    * 1 with an incorrect TLSA RR post key rotation
    * 1 with an incorrect TLSA usage (2 instead of 3).

[ FWIW, since Nov 13th the working domain count has reached 441. ]

In addition I've run into 8 domains with PKIX-EE(1) TLSA RRs which
are not "usable" for SMTP.  Therefore, I'd like to suggest that
while system operators should adopt SMTP with DANE, they should
not do so as "fashion statement".  Do it right, or don't do it at
all.  Having a bunch of published broken domains discourages others
from deploying and creates headaches for those who've enabled
verification.

The error rate would have been higher, were it not for some successes
in notifying most of the problem domains of their mistakes, with
almost all fixing the problem as a result.

Once the new testing site is up and running, I'm hoping we can
successfully "market" it to would-be SMTP with DANE operators, and
avoid most mistakes in the future.

The site will support testing of live systems (catch mistakes after
the fact) and testing of planned configurations (catch mistakes
before they happen).

A Cable operator in Germany with ~500K users has enabled DANE.

IIRC a Comcast engineer was present at the DANE meeting yesterday.
Since the comcast.net zone is signed, I was hoping that a good step
in the same direction might have been.

    _25._tcp.mx1.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4
    _25._tcp.mx2.comcast.net. IN TLSA 3 1 1 3D0CE5F401FE33EFA5ADB136D1E6EDAFBD72DB82FEC50E3CB69CF0943ACBA8D4

Sadly the certificates in question appear to be from a stock keypair:

    Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number: 2 (0x2)
	Signature Algorithm: sha1WithRSAEncryption
	    Issuer: C=US, O=Sample, Inc., OU=IT Team, CN=CA
	    Validity
		Not Before: Nov 18 14:58:26 2010 GMT
		Not After : Nov 15 14:58:26 2020 GMT
	    Subject: C=US, O=Sample, Inc., OU=IT Team, CN=Server
	    Subject Public Key Info:
		Public Key Algorithm: rsaEncryption
		    Public-Key: (1024 bit)
		    Modulus:
			...
		    Exponent: 65537 (0x10001)
	    X509v3 extensions:
		X509v3 Basic Constraints:
		    CA:FALSE
		Netscape Comment:
		    Sample server certificate, do not use on production systems!
    ...

Likely same key previously noted in:

    http://markgamache.blogspot.com/2014_01_01_archive.html
    https://community.virginmedia.com/t5/Email/Sample-server-certificate-do-not-use-on-production-systems/td-p/2142440

So we still have some way to go.

-- 
	Viktor.