We’ve asked the companies in our Who Has Your Back Program what they are doing to bolster encryption in light of the NSA’s unlawful surveillance of your communications. We’re pleased to see that four companies—Dropbox, Google, SpiderOak and Sonic.net—are implementing five out of five of our best practices for encryption. In addition, we appreciate that Yahoo! just announced several measures it plans to take to increase encryption, including the very critical encryption of data center links, and that Twitter has confirmed that it has encryption of data center links in progress. See the infographic.
By adopting these practices, described below, these service providers have taken a critical step towards protecting their users from warrantless seizure of their information off of fiber-optic cables. By enabling encryption across their networks, service providers can make backdoor surveillance more challenging, requiring the government to go to courts and use legal process. While Lavabit’s travails have shown how difficult that can be for service providers, at least there was the opportunity to fight back in court.
While not every company in our survey has implemented every recommendation, each step taken helps, and we appreciate those who have worked to strengthen their security. We hope that every online service provider adopts these best practices and continues to work to protect their networks and their users.
Crypto Survey Results
Encrypts data center links
Supports HTTPS
HTTPS Strict (HSTS)
Forward Secrecy
STARTTLS
undetermined
limited
undetermined
undetermined
(iCloud)
undetermined
(me.com, mac.com)
undetermined
undetermined
undetermined
(att.net)
undetermined
undetermined
undetermined
(comcast.net)
undetermined
planned
(facebook.com)
undetermined
undetermined
contemplating
planned 2014
planned 2014
planned 2014
contemplating
undetermined
(outlook.com)
undetermined
undetermined
undetermined
limited
undetermined
undetermined
undetermined
undetermined
(verizon.net)
undetermined
available
undetermined
planned 2014: default for mail, available for all services
undetermined
(yahoo.com)
Notes: The information in this chart comes from several sources; the companies who responded to our survey questions; information we have determined by independently examining the listed websites and services and published reports. Some of the surveyed companies did not respond to the survey.
Recognizing that some of these steps will take time to implement, we gave credit to companies that either (1) have implemented or (2) have concrete plans to implement the listed encryption process, as noted.
For STARTTLS, the red and grey shading indicates whether or not the company is a major email service provider. While we encourage all companies to implement STARTTLS, even if they only provide email for their own employees, the issue is most critical for companies providing email communications to the public.
This graphic is also available as an image file.
Why Crypto Is So Important
The National Security Agency’s MUSCULAR program, which tapped into the fiber-optic lines connecting the data centers of Internet giants like Google and Yahoo, exposed the tremendous vulnerabilities companies can face when up against as powerful an agency as the NSA. Bypassing the companies’ legal departments, the program grabbed extralegal access to your communications, without even the courtesy of an order from the secret rubber-stamp FISA court. The program is not right, and it’s not just.
With that in mind, EFF has asked service providers to implement strong encryption. We would like to see encryption on every step of the way for a communication on its way to, or within, a service provider’s systems.
For starters, we have asked companies to encrypt their websites with Hypertext Transfer Protocol Secure (HTTPS) by default. This means that when a user connects to their website, it will automatically use a channel that encrypts the communications from their computer to the website.
We have also asked them to flag all authentication cookies as secure. This means cookie communications are limited to encrypted transmission, which directs web browsers to use these cookies only through an encrypted connection. That stops network operators from stealing (or even logging) users’ identities by sniffing authentication cookies going over insecure connections.
To ensure that the communication remains secure, we have asked companies to enable HTTP Strict Transport Security (HSTS). HSTS essentially insists on using secure communications, preventing certain attacks where a network pretends that the site has asked to communicate insecurely.
All of these technologies are now industry-standard best practices. While they encrypt the communications from the end user to the server and back, the MUSCULAR revelations have shown this is not enough. Accordingly, we have asked service providers to encrypt communications between company cloud servers and data centers. Anytime a users’ data transits a network, it should be strongly encrypted, in case an attacker has access to the physical data links or has compromised the network equipment.
In addition, we have asked for email service providers to implement STARTTLS for email transfer. STARTTLS is an opportunistic encryption system, which encrypts communications between email servers that use the Simple Mail Transfer Protocol (SMTP) standard. When a user emails someone on a different provider (say, a Hotmail user writing to a Gmail user), the mail message will have to be delivered over the Internet. If both email servers understand STARTTLS, then the communications will be encrypted in transit. If only Gmail does but Hotmail does not (the current situation), they will be in the clear and exposed to eavesdropping, so it’s critical to get as many email service providers as possible to implement the system.
Finally, we have asked companies to use forward secrecy for their encryption keys. Forward secrecy, sometimes called ‘perfect forward secrecy,’ is designed to protect previously encrypted communications, even if one of the service providers’ keys is later compromised. Without forward secrecy, an attacker who learns a service provider’s secret key can use it to go back and read previously incomprehensible encrypted communications—perhaps ones that were recorded months or years in the past.
Related Issues:
Encrypting the Web
Share this: || Join EFF