Based only on the story that you cited, and your observation about
telcos being the sources of the info, might it be the case that the
telcos were also the mail providers? I'm not sure how to interpret
the slides the the cite story included. That sort of explanation
would be consistent with Ned's observations about commercial provider
use of SSL to protect IMAP/POP access.
It is almost certainly the case that large ISPs and MSPs are what's being
targeted, because, to paraphrase the quote falsely attributed to Willie Sutton,
"That's where the data is".
So perhaps we should, you know, take a closer look at the current state of play
in this space. Given the relatively small number of players this isn't
all that difficult.
For my testing I used a client that supported the following ciphersuites:
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
TLS_DHE_DSS_WITH_RC4_128_SHA (0x0066)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
TLS_RSA_WITH_SEED_CBC_SHA (0x0096)
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
SSL_RSA_WITH_RC4_128_MD5 (0x0004)
SSL_RSA_WITH_RC4_128_SHA (0x0005)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)
SSL_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
SSL_CK_RC4_128_WITH_MD5 (0xff01)
SSL_CK_RC2_128_CBC_WITH_MD5 (0xff03)
SSL_CK_DES_192_EDE3_CBC_WITH_MD5 (0xff07)
As most people are probably aware, the way SSL/TLS works is the client
proposes then the server selects the ciphersuite to use. The client I'm
using lets me enable whatever ciphersuite set I want, so when the server
selected something less than stellar I used this capability to see if I could
force a better result.
I mostly tested large MSPs and North American ISPs, but I tried a few European
and Australian ones as well. I attemped a few Asian and Middle Eastern
sites, but setup directions written in scripts I don't understand proved to
be too much of an obstable.
Anyway, the results are as follows:
1and1.com - imaps and imap, imap allows starttls
imap.1and1.com - TLS_RSA_WITH_AES_256_CBC_SHA
no DHE variants available
Apple: imaps only
imap.mail.me.com - SSL_RSA_WITH_RC4_128_MD5,
SSL_RSA_WITH_3DES_EDE_CBC_SHA if RC4 disabled,
TLS_RSA_WITH_AES_256_CBC_SHA will be used if only AES ciphers allowed,
no DHE variants available
AOL: imaps and imap, imap allows starttls
imap.aol.com - TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA available
Cox Cable: imaps only
imap.cox.net - TLS_RSA_WITH_AES_256_CBC_SHA, no DHE variants available
Charter: imaps only
mobile.charter.net - TLS_RSA_WITH_AES_256_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA available
Covad: imaps and imap, imap allows starttls
mail.covad.net - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA if Camillia disabled
no DHE variants available
Eastlink: imaps and imap, imap allows starttls
mail.eastlink.ca - TLS_RSA_WITH_AES_256_CBC_SHA, no DHE variants available
free.fr: imaps and imap, imap w/o starttls
imap.free.fr - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
GoDaddy: imaps and imap, imap allows starttls
imap.secureserver.net - TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA if Camillia disabled,
no DHE variants available
Gmail: imaps only
imap.gmail.com - SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA if RC4 disabled, no DHE variants available
GMX Mail: imaps and imap, imap w/o starttls
imap.gmx.com - TLS_RSA_WITH_AES_256_CBC_SHA
no DHE variants available
Hotmail: imaps only
imap-mail.outlook.com - TLS_RSA_WITH_AES_128_CBC_SHA,
no DHE variants available
iinet: imaps and imap, imap allows starttls
mail.iinet.net.au - TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA available
Insight Communications: imaps and imap, imap allows starttls
mail.insightbb.com - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Internode: imaps and imap, imap w/o starttls
mail.internode.on.net - SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA if RC4 disabled,
TLS_RSA_WITH_AES_128_CBC_SHA if only AES ciphers allowed,
no DHE variants available
Namesco: imaps and imap, imap w/o starttls
imap.hosts.co.uk - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
neuf.fr: imaps and imap, imap w/o starttls
imap.neuf.fr - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
Optus Broadband: imaps and imap, imap allows starttls
mail.optusnet.com.au - TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA is Camilla disabled
telefonica.net: imap w/o starttls
imap.telefonica.net
tre.it: imap w/o starttls (8 year old server software!)
imap.tre.it
Yahoo: imaps and imap, imap requires starttls
imap.mail.yahoo.com - SSL_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA if RC4 disabled,
no DHE variants available
Videotron: imap w/o starttls
imap.videotron.ca
Notes:
(1) Verizon, Comcast, Netzero, Earthlink, Mindspring, Sprint (?),
Shaw Cable, lightspeed.ca, Cogeco, Time Warner Cable,
CableVision(OptimumOnline) (?), Bigpond, and Mediacom do not support IMAP
(2) AT&T?, Rogers Cable use Yahoo for IMAP
(3) Cable One, Telecable uses gmail for IMAP
(4) The presence of Camellia as an option is explained by the fact that in
NSS if Camillia is enabled at all it is used preferentially. (Although
maybe not in the case of Optus Broadband.)
Keeping in mind that this is hardly a comprehensive list of the world's ISPs,
I'll first note that the ciphersuite situation is better than I expected. A
minority of services, albeit some of the biggest ones, prefer RC4. And nobody
insisted on it. Quite a few even go so far as to prefer a DHE variant. But more
of them need to support and prefer something in the DHE/AES set. This is a place
where some clear guidance would probably be helpful, as long as it involves
using ciphersuites for which support is readily available. (The obvious starting
point is for servers to always prefer AES to RC4 and always prefer DHE variants
to non-DHE variants. I'll the ranking of those two to those more pedantic than
I.)
Only three of the services tested, one in North America and the others in
Europe, offered no SSL/TLS at all. That strikes me as pretty good coverage
overall, and perhaps the Snoden revelations will make something good happen to
those, as it is doing at Yahoo.
But these results, while encouraging, don't say anything good about the IETF's
ability to mandate security. The IETF recommended best operational practice
(effectively a SHOULD in RFC 3501) is to only offer port 143 and require
STARTTLS on that port, as indicated by the LOGINDISABLED capability. Not a
single provider I tested implemented that specific variant. Not. One.
The closest was Yahoo - you know, the folks whose web mail has no security at
all - which does operate port 143 that way, but they also offered the
nonstandard imaps on port 993. Five services, including most of the largest
ones, offered the nonstandard imaps only. An equal number offered imaps but no
SSL/TLS capability on port 143. (These results are explained by the use of load
balancers that act as the termination point for SSL/TLS.)
Anyway, I've spent enough time on this, but if anyone else wants to throw
additional results for large ISPs and MSPs my way, especially from places using
scripts I don't grok, I'd appreciate it.
Ned
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
