Hey Viktor,
Viktor Dukhovni wrote: > 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). That I didn't know. Interesting detail on OpenSSL. Of course there's a very small percentage of hosts that only offer SSLv2. Another issue we have is in figuring out what the e.g. SMTP hosts we find actually are. Could be embedded devices or printers exposed on the internet that don't really do a lot of traffic. 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. 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. 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? What we can do is to compare to transparency reports by Google or compare to large universities, but that's far from definitive. > 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). 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. > 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. 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). 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.. > > 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. Sure, that's also the only option I currently see. Good that people are working on that and giving some thought to this though! > 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. 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). 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. > Dropping support for RC4 in Postfix is blocked on the substantial > disappearance of such servers, and measuring their population > periodically would be very useful. Sure. I hope we can continue these scans for as long as is relevant to give some insights into deployment / security of the email ecosystem. Details like the one's you've mentioned are exactly stuff we're looking for if we're to continue our scans. Thanks a lot for all your operational insights, very valuable! Aaron
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
