On Tue, Jul 28, 2015 at 01:39:40AM +0200, Aaron Zauner wrote:
> > > * 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.
> >
>
> 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.
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.