Security Expert: Yahoo's Email Encryption Needs Work 123
itwbennett writes "On Tuesday, Yahoo delivered on a promise that it made in October to enable email encryption for everyone by default by January 8. While this is a great step, the company's HTTPS implementation appears to be inconsistent across servers and even technically insecure in some cases, according to Ivan Ristic, director of application security research at security firm Qualys. For example, some of Yahoo's HTTPS email servers use RC4 as the preferred cipher with most clients. 'RC4 is considered weak, which is why we advise that people either don't use it, or if they feel they must, use it as a last resort,' Ristic said."
"[U]se [RC4] as a last resort." (Score:5, Informative)
Unfortunately — in Firefox, at least — ciphers can only be toggled, not given a priority. Control over cipher selection (and other HTTPS parameters, such as key length, key exchange, hash (MD5/SHA)., etc.) lies with the server operator. In my own testing, the arbitrated HTTPS parameters are most frequently prioritized in some order without regard to strength, or prioritized from weakest-to-strongest (or perhaps least-to-most expensive to execute).
In order to retain manageable security, I have only TLS 1.0-1.2 enabled, MD5 disabled, all RC4-employing combos disabled, with the last being switchable via a check box provided by "CipherFox." [github.com] (Additional features of use to "CipherFox" users are provided by "Calomel SSL Validation." [calomel.org]; I recommend both.)
Re: Momentum (Score:3, Informative)
This is not "email encryption" (Score:5, Informative)
While the article is correct and uses precise terminology, the summary is wrong to use the term "email encryption". That term is for encrypted email messages using PGP/GPG/S-MIME.
Yahoo have no framework for email encryption. This article is about use of HTTPS for their webmail service and (a) whether that has been implemented and, if so, (b) whether it has been done correctly.
The answers to which are: (a) mostly and (b) no.
Re:Ya-what? (Score:3, Informative)
Because it leads in Asia, ahead of Google.
RC4, BEAST, perfect forward security, recommendati (Score:3, Informative)
It's important to remember that only a year ago RC4 was a recommended solution and TLS1.2 support in browsers like Firefox and older operating systems has been slow to arrive.
It was only recommended as a counter to the BEAST attack, which exploited the way block ciphers worked. Since RC4 is a stream cipher it was not subject to this exploit, but a lot of people were uneasy about the recommendation. This is because while it was resilient against BEAST, everyone knew that RC4 was/is on its last legs, but it was the lesser of two evils.
When a workaround for BEAST was created (n/n-1 record splitting), and implemented in just about every browser, the BEAST attack became mostly moot, and at that point people should have put RC4 lower down on the list of allowed ciphers, whose only purpose was to support legacy clients (read: XP).
So basically RC4 should have been put at the bottom of the cipher list for about 18-24 months:
https://www.imperialviolet.org/2012/01/15/beastfollowup.html
If you're running a Unix system with OpenSSL 0.9.8, then put the following in your Apache configuration:
SSLHonorCipherOrder On
SSLCipherSuite DHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA:HIGH:!MD5:!ADH:!DES
If you have OpenSSL 1.0.1+, then:
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AES128:DH+AES128:RSA+AES128:RC4-SHA:HIGH:!ADH:!AECDH:!MD5:!DES
More details:
https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
TLS 1.2 everwhere will add to the security, but the above will go a long way for SSL 3 and TLS 1.0:
https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what
PS: the above two weblogs are two good resources on keep up to date on TLS stuff. The traffic is low, and so when they do post, it's usually worth looking at.