Subject: Re: [Uta] E-Mail Protocol Security Measurements

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Jul 2015 23:16:44 +0000

On Mon, Jul 27, 2015 at 03:17:52PM +0200, Aaron Zauner wrote:

> https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf
> 
>  * RC4 support is at about 83-85%
>  * unsurprisingly TLS 1.0 is most widely supported
>  * ~60% of certificates are self-signed
>  * a huge number of servers offer AUTH PLAIN (some without STARTTLS)
>  * ECDH: most use 256bit group size

No surprises in the above.

>  * 512bit DH(E) primes are very common

With export ciphers, or with non-export ciphers?  I would expect
non-export ciphersuites to be accompanied by stronger DHE primes,
with 512-bit DHE primarily used with export ciphers.  Do you have
a break-down?

>  * RC2-CBC-MD5 is supported by 40% of SMTP servers we've studied,

This looks implausible, I've not seen it once in SMTP connection
logs.  Slide 8 even mentions this "preferred" by ~25% of servers.
Preferred to what?

This is an SSL 2.0 ciphersuite, and OpenSSL will never choose it
unless the selected protocol is SSL 2.0.  And indeed it is by
default the most preferred ciphersuite if you force SSL 2.0.

But SSLv2-only servers are VERY rare (at least for SMTP), the above
datapoint is at least misleading.

>  * IDEA-CBC-MD5 by 14%

This is also SSLv2 only.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Mon, 27 Jul 2015 15:17:52 +0200

Hi,

UTA chairs recommended sending a mail about this to the UTA and IETF
lists. We're currently analyzing our datasets -- so more/detailed data
will become available shortly.

Over the past couple of months we've been collecting SMTP, IMAP and POP
(implicit TLS, STARTTLS) security measurements (primarily relating to
TLS, X.509 Certs and offered protocol extensions). I've given a short
talk at IETF93 in SAAG on the topic, the slides can be found over here:
https://www.ietf.org/proceedings/93/slides/slides-93-saag-2.pdf

We've also found 5-6% support of export ciphers in these protocols.

If you have any questions regarding any of our scans or need data points
for your drafts, recommendations or any current work - we'd be happy to
help you out there as best as we can.

Note that we have an outstanding TLS enumeration scan on port 587. We've
collected banner messages and certificates from 465 and 587 already though.

We don't yet have a publication ready and our data sets are currently
not public, but will be in the foreseeable future. However we're happy
to provide details if any of you have questions.

Thanks,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 28 Jul 2015 01:39:40 +0200

> No surprises in the above.

Yep, we didn't expect anything else. This is also consistent with
reports we've seen from E-mail Service Providers and universities.

> with 512-bit DHE primarily used with export ciphers.  Do you have

I'll provide a detailed mapping in the coming days.

> datapoint is at least misleading.

Yes, these are exclusive SSLv2 cipher-suites. With about 40% of SMTP
servers still supporting SSLv2 this seems to be correct. Note that
these are not measurements of how many mail servers do actually
establish connections on these protocols, it's just a figure of
support for protocols/cipher-suites. That wasn't meant to be
misleading, thanks for pointing out that my slides do not explicitly
state the tested protocol version there.

Please keep in mind that these are rough numbers from our initial
aggregation of data in the data-sets we've collected, not a paper.

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 18:27:18 +0000

> aggregation of data in the data-sets we've collected, not a paper.

Yes, if you offer only SSLv2, then I'd expect to see a lot of
RC2-CBC-MD5, because "RC4" is by default pushed to the bottom of
the list of 128-bit ciphers by OpenSSL, so anything other than RC4
looks "better" (and perhaps actually is better).

Since almost nobody negotiates SSLv2 (by default disabled in the
Postfix SMTP client for example, and also in the server along SSLv3
in more recent releases), this data-point is much less alarming
than it seems.  With SSLv2 the choice (in OpenSSL) of > 64-bit
ciphers is rather limited:

    IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5
    RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
    RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5

Which would you choose?  (Arguably 3DES, but its strength is 112-bit
in many implementations, so it often sorts after the nominally
128-bit peers).

The remedy is mostly to not bother with SSLv2.  Beyond perhaps
noting which servers support it, the details are hardly relevant,
and even measuring SSLv2 support is largely pointless, servers in
opportunistic TLS are generally willing to do whatever the client
is capable of, because (barring othe factors) even weak crypto is
better than cleartext.  Setting a floor security policy is left up
to the client.

The only issue is whether offering weaker options to some clients
creates downgrade opportunities against other clients.  With Logjam
as a recent example, we're deprecating "export" ciphers, single-DES,
SSLv2 and SSLv3  in Postfix SMTP servers, because no real clients
need these.  The plan is to drop support for weak crypto once it
is no longer needed for interoperability.  For now, we're retaing
RC4 support until the number of systems requiring RC4 drops further.

So what's important to measure is which servers support *only* RC4.
Note that Exchange 2003 appears to also support 3DES, but that
implementation is broken (post-handshake).  To detect those systems,
if the negotiated cipher is DES-CBC3-SHA, you need to send both
EHLO and QUIT:

	C: EHLO <yourname><CRLF>
	S: 250-...
	   ...
	S: 250 ...
	C: QUIT<CRLLF>
	S: 221 Goodbye

and if TLS detects problems with the QUIT response (garbage in the
TLS record-layer) then you have a server that supports only RC4
(the 3DES implementation is broken due to incorrect padding).

Such servers also only process the first 64 ciphersuite code-points
in the client handshake.  If their desired RC4-SHA or RC4-MD5 does
not appear in the first 64 slots, they'll try use 3DES and fail if
that does.

Dropping support for RC4 in Postfix is blocked on the substantial
disappearance of such servers, and measuring their population
periodically would be very useful.

-- 
	Viktor.

P.S.

If you have a dataset of hosts that offer STARTTLS on port 25, and
especially if that also includes the CN or first DNS altname in
the certificate (and/or the hostname from the first line of the
EHLO response), that would be most useful for my DANE surveys.

Drop me a line if you're willing to share.  My DANE SMTP server
hunt has so far found around 1700 DNSSEC domains served by just
over 900 DNSSEC TLSA-record validated MX hosts.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 19:11:08 +0000

On Wed, Jul 29, 2015 at 06:41:10PM +0000, Salz, Rich wrote:

> It kinda bothers me that at times the entire Internet security policy is
> being driven solely by data from one particular MTA.

You don't have to read all my posts... :-)

Also, my perspective is not from "one particular MTA", rather it
is a perspective based on a decade and half of building usable SMTP
transport security, which is a diverse mixture of opportunistic
and mandatory TLS, and interacts in interesting ways with DNS.

The converse viewpoint is that for too long Internet security has
been too narrowly driven solely by HTTPS.  Perhaps it is time to
consider additional perspectives (though of course not only such
perspectives).

There is a large majority of folks in all the various WGs who are
not working on SMTP let alone Postfix.  I don't think there's a
serious risk of hyper-focus.

-- 
	Viktor.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2015 11:09:16 -0400

>  * RC4 support is at about 83-85% * unsurprisingly TLS 1.0 is most

RC4 is supported by 83% of end points that support crypto, or of 83% of
end points that answer TCP?

What percentage support some kind of crypto, even if we might call it pretend
crypto now.

I didn't see the total number of hosts scanned in the slides.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Jul 2015 18:41:10 +0000

It kinda bothers me that at times the entire Internet security policy is being driven solely by data from one particular MTA.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 30 Jul 2015 00:28:44 -0400

On Wed 2015-07-29 14:41:10 -0400, Salz, Rich wrote:
> It kinda bothers me that at times the entire Internet security policy
> is being driven solely by data from one particular MTA.

I share Rich's concern, and wish that more people were doing the kind of
excellent work that Victor is doing with Postfix.  We need more
engagement from other MTAs (and other network applications for that
matter).

Victor, thanks for your work, please keep it up.

          --dkg

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 18:34:49 +0200

Hi Michael,

> end points that answer TCP?

This percentage is based on hosts that did complete a SSL/TLS handshake.

> I didn't see the total number of hosts scanned in the slides.

The number fluctuates from scan to scan (also our blacklist grows
slowly, but surely -- admins that wish their host or range to be excluded).

For the RC4 specific results:

	Supports RC4 | Does not Support RC4 |Total
SMTPS	2346023		505575		2851598
SMTP	1343406		213882		1557288
IMAPS	3373919		673466		4047385
IMAP	654987		109224		764211
POP3S	3303738		641314		3945052
POP3	3035752		473240		3508992

Our initial scans were based on Hosts collected by UMichigan (dataset:
3d2hbz9r9kh2fbrk-zgrab-results-25-smtp-starttls-full_ipv4-20150413T040703.json)
- We've since gone on to do our own IPv4 wide discovery scans (which
also include banners and X.509 data).

Aaron

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Jul 2015 18:46:11 +0200

> end points that answer TCP?

We got successful STARTTLS handshakes on about 33.14 % (4'951'172) of
all IPv4 hosts answering on TCP port 25 (9'988'616 don't indicate
STARTTLS support at all or don't complete).  2'973'202 do TLS1.0 and
1.2, 1'934'518 do TLS1.0 only, and the other numbers are small (e.g.,
2'721 SSLv3 only).

(Reporting on Julian Kornberger's work.)

Grüße, Carsten

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Jul 2015 15:11:20 -0400

I see what was written as the conclusions; you're the first, more data 
is needed and you have data for others to see.  What were the goals? 
  EMail is not secured?

Thanks

--
HLS

-- 
HLS

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 30 Jul 2015 21:14:31 +0200

Hi Hector,

> is needed and you have data for others to see.  What were the goals?

Getting a better view of TLS and security extensions as deployed
currently on the internet for e-mail protocols and possible to track
change over time. People do these scans regularly for the Web (HTTPS), I
think it's important to have such studies for E-Mail as well.

Aaron

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Jul 2015 16:10:56 -0400

Aaron Zauner <[email-masked]> wrote:
    >> RC4 is supported by 83% of end points that support crypto, or of 83%
    >> of end points that answer TCP?

    > This percentage is based on hosts that did complete a SSL/TLS

okay, so whle we might cringe at how many hosts are using weak crypto,
we might also be elated (if we had numbers) about how many hosts support
*any* crypto...

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jul 2015 21:50:08 +0000

> we might also be elated (if we had numbers) about how many hosts support

Note that RC4 *use* is much lower than RC4 *support*...

Lots of servers support RC4, to interoperate with legacy peers,
but in practice very rarely negotiate it.  Many of the below support
RC4, but in practice you get much stronger crypto:

    $ for d in gmail.com outlook.com yahoo.com aol.com hotmail.com microsoft.com gmx.de t-online.de web.de
      do
	posttls-finger -c -lencrypt -Lsummary $d
      done
    posttls-finger: ... gmail-smtp-in.l.google.com... TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... mta7.am0.yahoodns.net... TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
    posttls-finger: ... mailin-03.mx.aol.com... TLSv1 with cipher ADH-AES256-SHA (256/256 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... microsoft-com.mail.protection.outlook.com... TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)
    posttls-finger: ... mx01.emig.gmx.net... TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    posttls-finger: ... mx03.t-online.de... TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    posttls-finger: ... mx-ha03.web.de... TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

    $ for d in gmail.com outlook.com yahoo.com aol.com hotmail.com microsoft.com gmx.de t-online.de web.de
      do
	posttls-finger -c -lencrypt -o tls_medium_cipherlist=RC4-SHA -Lsummary $d
      done
    posttls-finger: ... gmail-smtp-in.l.google.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mx4.hotmail.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mta5.am0.yahoodns.net... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mailin-01.mx.aol.com... TLSv1 with cipher RC4-SHA (128/128 bits)
    posttls-finger: ... mx2.hotmail.com... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: SSL_connect error to microsoft-com.mail.protection.outlook.com... lost connection
    posttls-finger: SSL_connect error to mx01.emig.gmx.net... -1
    posttls-finger: ... mx03.t-online.de... TLSv1.2 with cipher RC4-SHA (128/128 bits)
    posttls-finger: SSL_connect error to mx-ha02.web.de... -1

Lack of RC4 support at three of the above just means that email
they receive from some legacy systems is sent in the clear.

It has been rumoured that Yahoo's outboud systems prefer RC4, and
unless servers impose their own cipher priority, mail from Yahoo
uses RC4.  I've not personally tested that for some time, so that
"factoid" may be stale...

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 31 Jul 2015 09:53:33 +0200

> we might also be elated (if we had numbers) about how many hosts support

I think Carsten Bormann should have already pointed this out in his
message to this list earlier. His numbers are pretty similar to what we see.

Aaron

---

From: Tony Finch <[email-masked]>
Date: Fri, 31 Jul 2015 12:58:52 +0100

Viktor Dukhovni <[email-masked]> wrote:
> but in practice very rarely negotiate it.

Yes (with help from Viktor) my servers have a special cipher priority list
to ensure that they negotiate RC4 with old Windows 2003 Exchange servers.
I haven't checked recently if this is still necessary...

http://archives.neohapsis.com/archives/postfix/2013-11/0121.html

> uses RC4.

That's what it looks like to me.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Bailey: Northeasterly 6 to gale 8 at first in northwest, otherwise cyclonic 4
or 5. Rough at first in northwest, otherwise moderate. Rain or showers. Good,
occasionally poor.