On Thu, Jul 30, 2015 at 06:16:53PM +0200, Aaron Zauner wrote:
> Still I think it's an interesting study, I
> don't know of anybody doing a similar one previously (as in: enumerating
> TLS for the whole IPv4 space.
Back in January 2015 I got some data conducted by a contact in
Germany who had access to a 50Gbps link for a few days. That scan
found 4.5 million IPv4 addresses with STARTTLS on port 25.
Today, I took a random sample of 100 hosts from that data, and was
able to complete a STARTTLS handshake with 76 of them. Extrapolating,
we can estimate 3 million SMTP hosts with STARTTLS in that dataset.
> Hubert Kario has monthly reports on the
> Alexa Top 1 Mio for HTTPS). I'm currently comparing to MX records
> associated with the Alexa Top 1 Mio, but these aren't necessarily
> domains that also amount to significant e-mail traffic.
The Alexa data correlates poorly with SMTP.
> What I do see
> there is that a huge percentage are using GMail, some Office 365 and
> similar cloud hosted solutions (run hasn't finished yet). Are you aware
> of any data that'd be similar to a Alexa list but for mail servers?
I am not aware of any good source of volume-ranked email domains,
or just mail-receiving domains. Google's transparency report is
not comprehensive. They don't list "small" domains. I receive
email from Gmail users, but my domain has never been listed in
Google's report. Still their report can be viewed a good sample
of the larger domains.
> What
> we can do is to compare to transparency reports by Google or compare to
> large universities, but that's far from definitive.
Yes, that's all one can do for now.
> > 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).
>
> Triple-DES would be the algorithm I'd chose here, it's below '128bit
> security' but is to be the algorithm with the least known cryptanalytic
> attacks known from the above list.
Ditto, but since its nominal ranking is 112-bits, RC2 comes out on
top much of the time.
> > Setting a floor security policy is left up to the client.
>
> I agree to some extent. The problem is that SSLv2 and v3 are deprecated
> protocols and these should /really/ be phased out. In terms of e-mail;
> everything is moving far slower there than for Web (browsers vendors
> penalize bad crypto settings).
With opportunistic security:
https://tools.ietf.org/html/rfc7435
when a server or client sets the crypto bar too high, the result
is not more security, but less, because peers often resort to
cleartext when TLS fails. Therefore, setting the bar too high is
counter-productive.
It is not very useful to measure the weakest ciphers supported,
you want to know the strongest supported (or most preferred), which
is what is negotiated in practice.
> I don't know of a similar approach for
> any mail protocol. People have suggested delaying e-mail from hosts that
> offer weak security. But in the end that's not a good solution - it only
> results in losing or annoying customers for providers that actively do
> this for penalizing..
That would be counter-productive (even foolish). Cleartext is
weaker still. The right thing to do is evangelize stronger security,
and encourage upgrades, so that once the weak options are inessential,
they can be dropped. This takes longer than in the browser space,
but that's to be expected. On the other hand 80% of Google's
outbound email is TLS encrypted. What do you think the ratio
of HTTPS to HTTP is?
> > 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:
Both of course *after* STARTTTLS, (there's another EHLO before
STARTTLS, but that's not the one I'm talking about).
> >
> > 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.
>
> That's another detail I wasn't aware of, hence we haven't scanned
> specifically for this (would also be useful to fingerprint the software
> vendor / distribution of the servers we're connecting to).
Yes, the particular Microsoft Exchange release number in the banner
is often a good indication of potential for this problem. But the
issue is also present in some other SMTP products running on Windows
2003 (server appliances).
> We can do this kind of scan still, if you're interested. Can't put it on
> the top of our priorities currently, but it would certainly be valuable
> information.
It would be very valuable to know which systems interoperate ONLY
via RC4-SHA/RC4-MD5 and fail with all other ciphers (despite
appearing to support 3DES). If that's something you can scan for,
that would be great.
I have a reasonable dataset of IPs (from January), but not the
bandwidth (or software on hand) to repeat the scan.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
