Sophos Cloud Optix
Yahoo, following the lead of Google and Microsoft, has now enabled HTTPS encryption for all Yahoo Mail users by default.
A short company blog post by Jeff Bonforte, Yahoo’s senior vice president of Communication Products on Tuesday said:
As we promised back in October, we are now automatically encrypting all connections between our users and Yahoo Mail. Anytime you use Yahoo Mail - whether it’s on the web, mobile web, mobile apps, or via IMAP, POP or SMTP- it is 100% encrypted by default and protected with 2,048 bit certificates. This encryption extends to your emails, attachments, contacts, as well as Calendar and Messenger in Mail.
The implementation of encrypted connections, which came in a day earlier than the company’s self-imposed January 8 deadline, is part of Yahoo’s plans to beef up its security in response to growing concerns over government surveillance activities across the internet.
The leak of confidential documents by former NSA contractor Edward Snowden, which revealed how the NSA was collecting email metadata and snooping on other forms of internet communication, has prompted Yahoo and several other tech giants to work on making such surveillance significantly harder.
Some observers have pointed out that Yahoo hasn’t gone the whole way with HTTPS, notably because it hasn’t implemented what’s known as “forward secrecy.”
If you’re not familiar with the idea of forward secrecy, you might want to take a look at Paul Ducklin’s explanation of it from November 2013, when Twitter started using it.
Plain HTTPS connections use a public-private keypair so that your traffic to the server is encrypted, and the server is vouched for by the HTTPS certificate it presents.
But you can use the server’s private key later on to decrypt all current and previous traffic, assuming the earlier traffic was logged somewhere.
Forward secrecy adds a second layer of encryption, effectively using a throw-away public-private keypair to scramble each session, as well as using the server’s public-private keypair to identify that you are connected to the right server.
If the throw-away keypairs really are thrown away after each session, encrypted traffic can’t be unscrambled later.
Of course, webmail services have access to your unencrypted emails anyway, at least for a while, but forward secrecy nevertheless adds some additional security comfort.
On the other hand, forward secrecy also increases latency (more network traffic is needed when you login) and processing requirements (more CPU power is required to do the extra cryptographic calculations).
That’s probably why Yahoo hasn’t yet added it.
Google has offered HTTPS by default on Gmail since 2010. Facebook also began rolling out HTTPS on by default in November while Microsoft’s webmail service – Outlook.com – launched with the service back in July 2012.
Yahoo did actually introduce full-session HTTPS for its webmail users at the end of 2012 but it wasn’t implemented by default – users had to opt in prior to this week.
While current events bring light to the importance of security the average person is unlikely to even notice the change from http to https.
Hmmm. I would say that the performance of the Yahoo Android webmail app is noticeably affected. The performance of a Core 2 Duo T5500 running XP and IE8 also seems to be affected. No benchmarks though, just these subjective results.
“But you can use the server’s private key later on to decrypt all current and previous traffic, assuming the earlier traffic was logged somewhere.”
This is an incomplete and somewhat misleading description. HTTPS (SSL/TLS) itself generates and transmits a session key to the client, using the server’s public/private key pair (asymmetric encryption) to protect that handshake, then the transmitted temporary session key is used to symmetrically encrypt the data transferred during the session. Encryption using the assymetrical (public/private) keys is WAY too slow to be practical for actual data transfer. So asymmetrical encryption is used to securely transmit things like hashes and session keys that are useful with algorithms that are computationally much (much) faster.
On the other hand, encryption and decryption using AES symmetrical encryption is very fast. Essentially negligible, really.
This handshake/key transfer is done for each new HTTPS connection, which means that the content returned on a single page might in fact have been encrypted using more than one temporary symmetric encryption key. This is one reason why a poorly-designed web page or service or server, one which requires many new connections to serve all the content from a given URL–rather than minimizing distinct requests, and using keep-alives to further minimize the need for fresh connections to server–suffers performance issues when you just switch it to HTTPS. The extra round trips and CPU cost of the asymmetrical encryption takes a toll. Design the service properly, and the cost is dramatically reduced.
Either way, the data transmitted CAN NOT be decrypted “using the server’s private key.” However, the initial request handshakes COULD be decrypted using the server’s private key, and the temporary symmetrical encryption keys could be extracted that way, then used to decrypt the actual data that was transferred. You would have to do this for each connection that was made during the session,and match the right symmetrical key up with the right chunk of data to properly decrypt it. But that could be done if the interested party got their hands on the private half of the server’s key pair.
So, I’m all for perfect forward secrecy, 100%. I’m just saying that the statement about decrypting “all current and previous traffic” using the server’s private key is a tiny bit inaccurate.
I think it’s accurate enough (though I cringe a tiny bit to hear myself say that).
If you have a combination safe, and you write down the combo and lock the piece of paper in a strongbox, then, strictly speaking, the strongbox key doesn’t open the safe.
But if you give me the strongbox key…guess what? I can get into your safe! The semantics of exactly which key popped which lock are suddenly unimportant 🙂
Without the private key, you can’t decrypt any session data you logged earlier. With the private key but without “forward secrecy”, then assuming you logged all (or enough) session data, you *can* decrypt the session data later.