Blog

Today we’re announcing the launch of STARTTLS Everywhere, EFF’s initiative to improve the security of the email ecosystem.

Thanks to previous EFF efforts like Let's Encrypt, and Certbot, as well as help from the major web browsers, we've seen significantwins in encrypting the web. Now we want to do for email what we’ve done for web browsing: make it simple and easy for everyone to help ensure their communications aren’t vulnerable to mass surveillance.

Note that this is a high-level, general post about STARTTLS Everywhere. If you’d like a deeper dive intended for mailserver admins, with all the technical details and caveats, click here.

It’s important to note that STARTTLS Everywhere is designed to be run by mailserver admins, not regular users. No matter your role, you can join in the STARTTLS fun and find out how secure your current email provider is at:

Enter your email domain (the part of your email address after the “@” symbol), and we’ll check if your email provider has configured their server to use STARTTLS, whether or not they use a valid certificate, and whether or not they’re on the STARTTLS Preload List—all different indications of how secure (or vulnerable) your email provider is to mass surveillance.

Wait, Email Is Vulnerable to Mass Surveillance?

Email relies on something called the Simple Mail Transfer Protocol, or SMTP. SMTP is the technical language email servers use to communicate with each other. It was one of the very first application protocols developed for the Internet. It’s even older than HTTP, the protocol your browser uses to talk to webservers when you want to load a website!

Just like HTTP, SMTP was not developed with encryption or authentication in mind, as the trust model on the Internet today is starkly different from what it was in the 70s. Like regular old snail mail, senders can write whatever they want in the "From:" field, or even choose to omit it. And in the same way your post office or your postal carrier can read what you write on a postcard, machines responsible for delivering emails can read their contents, as can anyone who’s watching the traffic they send and receive. But unlike regular mail, the cost of sending emails, spoofing emails, collecting copies of emails, and altering emails in-transit is extremely low.

That means that without encryption, government agencies that perform mass surveillance, like the NSA, can easily sweep up and read everyone’s emails—no hacking or breaking encryption necessary.

So What Is STARTTLS?

STARTTLS is an addition to SMTP, which allows one email server to say to the other, “I want to deliver this email to you over an encrypted communications channel.” The recipient email server can then say “Sure! Let’s negotiate an encrypted communications channel.” The two servers then set up the channel and the email is delivered securely, so that anybody listening in on their traffic only sees encrypted data. In other words, network observers gobbling up worldwide information from Internet backbone access points (like the NSA or other governments) won't be able to see the contents of messages while they’re in transit, and will need to use more targeted, low-volume methods.

It’s important to note that if you don’t trust your mail provider and don’t want them to be able to read your emails, STARTTLS isn’t enough. That’s because STARTTLS only provides hop-to-hop encryption, not end-to-end. For example, if a Gmail user sends email to an EFF staffer, the operators of the Google and EFF mailservers can read and copy the contents of that email even if STARTTLS is negotiated perfectly. STARTTLS only encrypts the communications channel between the Google and EFF servers so that an outside party can’t see what the two say to each other—it doesn’t affect what the two servers themselves can see.

Thus, STARTTLS is not a replacement for secure end-to-end solutions. Instead, STARTTLS allows email service providers and administrators to provide a baseline measure of security against outside adversaries.

Great! So if STARTTLS Exists Everything’s Fine, Right?

Unfortunately, STARTTLS has some problems. Although many mailservers enable STARTTLS, most still do not validate certificates. Just like in HTTPS, certificates are what a server uses to prove it really is who it says it is. Without certificate validation, an active attacker on the network can get between two servers and impersonate one or both, allowing that attacker to read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice for emails servers to validate certificates, there’s often little incentive to present valid certificates in the first place.

As a result, the ecosystem is stuck in a sort of chicken-and-egg problem: no one validates certificates because the other party often doesn’t have a valid one, and the long tail of mailservers continue to use invalid certificates because no one is validating them anyway.

Additionally, even if you configure STARTTLS perfectly and use a valid certificate, there’s still no guarantee your communication will be encrypted. That’s because when a sending email server says, “I want to deliver this email to you over an encrypted communications channel,” that message is unencrypted. This means network attackers can jump in and block that part of the message, so that the recipient server never sees it. As a result, both servers think the other doesn’t support STARTTLS. This is known as a “downgrade attack,” and ISPs in the U.S. and abroad have been caught doing exactly this. In fact, in 2014 several researchers found that STARTTLS encryption on outbound email from several countries was being regularly stripped.

STARTTLS Everywhere to the Rescue!

STARTTLS Everywhere provides software that a sysadmin can run on an email server to automatically get a valid certificate from Let’s Encrypt. This software can also configure their email server software so that it uses STARTTLS, and presents the valid certificate to other email servers. Finally, STARTTLS Everywhere includes a “preload list” of email servers that have promised to support STARTTLS, which can help detect downgrade attacks. The net result: more secure email, and less mass surveillance.

If you appreciate the work we’ve done on STARTTLS Everywhere, you can also donate to EFF! Your contribution will help further the development of projects like STARTTLS Everywhere that help raise everyone’s level of security.

Today we’re announcing the launch of STARTTLS Everywhere, EFF’s initiative to improve the security of the email ecosystem.

Thanks to previous EFF efforts like Let's Encrypt, and Certbot, as well as help from the major web browsers, we've seen significantwins in encrypting the web. Now we want to do for email what we’ve done for web browsing: make it simple and easy for everyone to help ensure their communications aren’t vulnerable to mass surveillance.

Note that this is a technical deep dive into EFF’s new STARTTLS Everywhere project, which assumes familiarity with SMTP and STARTTLS. If you’re not familiar with those terms, you should first read our post intended for a general audience, available here.

The State of Email Security

There are two primary security models for email transmission: end-to-end, and hop-to-hop. Solutions like PGP and S/MIME were developed as end-to-end solutions for encrypted email, which ensure that only the intended recipient can decrypt and read a particular message.

Unlike PGP and S/MIME, STARTTLS provides hop-to-hop encryption (TLS for email), not end-to-end. Without requiring configuration on the end-user's part, a mailserver with STARTTLS support can protect email from passive network eavesdroppers. For instance, network observers gobbling up worldwide information from Internet backbone access points (like the NSA or other governments) won't be able to see the contents of messages, and will need more targeted, low-volume methods. In addition, if you are using PGP or S/MIME to encrypt your emails, STARTTLS prevents metadata leakage (like the "Subject" line, which is often not encrypted by either standard) and can negotiate forward secrecy for your emails.

Nobody Validates Certificates, and It’s Hard to Blame Them

Although many mailservers enable STARTTLS, most still do not validate certificates. Without certificate validation, an active attacker on the network can read and even modify emails sent through your supposedly “secure” connection. Since it’s not common practice to validate certificates, there’s often little incentive to present valid certificates in the first place. A brief experiment on Censys shows that about half of the mailservers that support STARTTLS use self-signed certificates.

On the web, when browsers encounter certificate errors, these errors are communicated to the end user, who can then decide whether to continue to the insecure site. With email, this is not an option, since an email user's client, like Thunderbird or the Gmail app on a user’s phone, runs separately from the machine responsible for actually sending the mail. Since breakage means the email simply won’t send, the email ecosystem is naturally more risk-averse than the browser ecosystem when it comes to breakages.

As a result, the ecosystem is stuck in a sort of chicken-and-egg problem: no one validates certificates because the other party often doesn’t have a valid one, and the long tail of mailservers continue to use invalid certificates because no one is validating them anyway.

Even If You’re Doing It Right, It Could Still Go Wrong

But let’s say you have STARTTLS enabled with a valid certificate, and so does the other party. You both validate certificates. What could go wrong?

When two mailservers support STARTTLS, their insecure connection is opportunistically upgraded to a secure one. In order to make that upgrade, the two mailservers ask each other if they support STARTTLS. Since this initial negotiation is unencrypted, network attackers can alter these messages to make it seem like neither server supports STARTTLS, causing any emails to be sent unencrypted. ISPs in the U.S. and abroad have been caught doing exactly this, and in 2014, several researchers found that encryption on outbound email from several countries were being regularly stripped.

Can DANE Fix These Problems?

Absolutely! If you are deep into the email world, you may have heard of DANE. DANE relies on DNSSEC, a protocol for publishing and validating signed DNS entries. Consistent and full DANE deployment presents a scalable solution for mailservers to clarify certificate validation rules and prevent downgrade attacks.

However, DANE is dependent on deployment and validation of DNSSEC, the latter of which has remained stagnant (at around 10-15% worldwide) for the past five years. STARTTLS Everywhere’s aim is to decouple secure email from DNSSEC adoption with a stop-gap, intermediate solution.

What About MTA-STS?

MTA-STS is a proposed standard that will allow mailservers to announce the security policies of their mailservers. In MTA-STS, a mailserver administrator creates a TXT record in their domain’s DNS entries, which indicates that the domain supports MTA-STS. They then post their security policy (whether to require STARTTLS or continue sending email on failure, which MX hosts to use, and how long the policy is valid) at a well-known HTTPS URL on their domain, so that senders can retrieve it and adhere to the policy.

The problem with MTA-STS is that since most DNS requests are still unauthenticated (see the section on DANE above), an active attacker can still MitM the initial DNS request and convince the sender that the recipient doesn’t support MTA-STS, and then later MitM the STARTTLS messages, so the sender will never know the recipient supports STARTTLS.

Wow, Everything’s So Messed Up. How Is STARTTLS Everywhere Going to Help?

We have three primary goals for STARTTLS Everywhere:

Improve STARTTLS adoption.

We want to make it easy to deploy STARTTLS with valid certificates on mailservers. We’re developing Certbot plugins for popular MTA software, starting with Postfix, to make this a reality.

If you run a mailserver and use Postfix, help test out our Certbot plugin. Please note that the plugin is still very much beta—if you have problems with it, you can report an issue.

Not using Postfix? We’re also working on Certbot plugins for Dovecot and Sendmail, so stay tuned. We also welcome contributions of installer plugins for other MTAs!

Prevent STARTTLS downgrade attacks.

In order to detect downgrade attacks, we’re hosting a policy list of mailservers that we know support STARTTLS. This list acts essentially as a preload list of MTA-STS security policies. We’ve already preloaded a select number of big-player email domains, like Gmail, Yahoo, and Outlook.

If you’d like to add your email domain to the list, try out our website; otherwise, you can also email starttls-policy@eff.org with validation details or submit a pull request yourself to the code repository where we host the list.

If you’d like to use the list, check out our guidelines for how to do so.

Lower the barriers to entry for running a secure mailserver.

Email was designed as a federated and decentralized communication protocol. Since then, the ecosystem has centralized dramatically, and it has become exponentially more difficult to run your own mailserver. The complexity of running an email service is compounded by the anti-spam arms race that small mail operators are thrust into. At the very least, we’d like to lower the barriers to entry for running a functional, secure mailserver.

Beyond developing and testing Certbot plugins for popular MTAs, we’re still brainstorming ideas to decentralize the email ecosystem. If you work on easy-to-deploy MTA software, let’s get in touch.

You can help, too!

All of our software packages are currently in a developer beta state, and our team is stretched thin working on all of these projects. You can help make the email ecosystem more secure by:

Of course, if you appreciate the work we’ve done on STARTTLS Everywhere, you can also donate to EFF! Your contribution will help further development of projects like STARTTLS Everywhere that help raise everyone’s level of security.

The Border Security and Immigration Reform Act (H.R. 6136), introduced before Congress last week, would offer immigrants a new path to citizenship in exchange for increased high tech government surveillance of citizens and immigrants alike. The bill calls for increased DNA and other biometric screening, updated automatic license plate readers, and expanded social media snooping. It also asks for 24 hours-a-day, five-days-a-week drone surveillance along the southern U.S. border.

This bill would give the U.S. Department of Homeland Security broad authority to spy on millions of individuals who live and work as far as 100 miles away from a U.S. border. It would enforce invasive biometric scans on innocent travelers, regardless of their citizenship or immigration status.

An Upcoming Vote

In mid-June, after months of stalled negotiations and failed legislative proposals, the Republican caucus of the House of Representatives agreed to a plan on immigration reform: Representatives would vote on two immigration bills.

Representatives smartly rejected one of those bills. The Securing America’s Future Act (H.R. 4760), which EFF opposed, failed in a 193-231 vote. That bill took a hardline stance on immigration and proposed the increased use of invasive surveillance technologies including biometric screening, social media monitoring, automatic license plate readers, and drones.

A vote is expected soon on the second bill: the Border Security and Immigration Reform Act. It would give children who came to this country without documentation—known as “Dreamers”—a path to citizenship. Unfortunately, this bill includes nearly the same bad border surveillance provisions as the bill that failed Thursday.

Given the grave impact this bill would have on individual privacy and rights, we urge Congress to vote the same way as it did Thursday and reject the Border Security and Immigration Reform Act.

More Surveillance Technologies and Drone Flights

The Border Security and Immigration Reform Act would fund multiple surveillance technologies across the United States. Near Detroit, for example, the bill calls for “mobile vehicle-mounted and man-portable surveillance capabilities” for U.S. Customers and Border Protection (CBP) agents. In Washington, the bill similarly calls for “advanced unattended surveillance sensors” and “ultralight aircraft detection capabilities.”

The bill also requires that CBP’s Air and Marine operations fly unmanned drones “on the southern border of the United States for not less than 24 hours per day for five days per week.”

This type of increased drone surveillance was proposed in H.R. 4760. As we previously wrote:

“Drones can capture personal information, including faces and license plates, from all of the people on the ground within the range and sightlines of a drone. Drones can do so secretly, thoroughly, inexpensively, and at great distances. Millions of U.S. citizens and immigrants live close to the U.S. border, and deployment of drones at the U.S. border will invariably capture personal information from vast numbers of innocent people.”

Similar to H.R. 4760, the Border Security and Immigration Reform Act includes no meaningful limitations on the drones’ flight paths, or the collection, storage, and sharing of captured data. The bill could lead to deep invasions into innocent bystanders’ lives, revealing their private information and whereabouts.

More Biometric Screening

The Border Security and Immigration Reform Act also proposes the establishment of a “biometric exit data system” that would require everyone leaving the country—immigrant or citizen—to have their biometric data screened against government biometric databases.

Relatedly, the bill would authorize the CBP Commissioner, “to the greatest extent practicable,” to use facial recognition scanning to inspect citizens traveling to the U.S. from nearly 40 visa waiver program countries, which include Japan, New Zealand, Australia, France, Germany, Italy, and Taiwan.

Further, the bill authorizes the Secretary of Homeland Security to “make every effort to collect biometric data using multiple modes of biometrics.” That means that fingerprints, facial recognition data, and iris scans could all be up for grabs in the future, so long as the Secretary of Homeland Security deems it necessary.

These proposals are similar to those included in H.R. 4760. They are worrying for the very same reasons:

“Biometric screening is a unique threat to our privacy: it is easy for other people to capture our biometrics, and once this happens, it is hard for us to do anything about it. Once the government collects our biometrics, data thieves might steal it, government employees might misuse it, and policy makers might deploy it to new government programs. Also, facial recognition has significant accuracy problems, especially for people of color.”

More Social Media Snooping on Visa Applicants

The Border Security and Immigration Reform bill also borrows the same deeply-flawed social media monitoring practices as those included in H.R. 4760.

The Border Security and Immigration Reform bill would authorize the Department of Homeland Security to look through the social media accounts of visa applicants from so-called “high-risk countries.” As we said about the proposal in H.R. 4760:

"This would codify and expand existing DHS and State Department programs of screening the social media of certain visa applicants. EFF opposestheseprograms. Congress should end them. They threaten the digital privacy and freedom of expression of innocent foreign travelers, and the many U.S. citizens and lawful permanent residents who communicate with them. The government permanently stores this captured social media information in a record system known as 'Alien Files.'"

And similar to H.R. 4760, the Border Security and Immigration Act authorizes the Secretary of Homeland Security to use literally any criteria they find appropriate to determine what countries classify as “high-risk.” This broad authority would allow the Secretary of Homeland Security to target Muslim-majority nations for social media collection.

No Compromising on Civil Liberties

As Congress weighs different factors in the ongoing immigration debate, we urge them to look closely at the expanded high-tech surveillance provisions in this proposed package. This bill would undermine the privacy of countless law-abiding Americans and visitors, regardless of citizenship. So, we urge a “no” vote.

So why do we know so little about it?

The U.S. Department of Homeland Security (DHS) is quietly building what will likely become the largest database of biometric and biographic data on citizens and foreigners in the United States. The agency’s new Homeland Advanced Recognition Technology (HART) database will include multiple forms of biometrics—from face recognition to DNA, data from questionable sources, and highly personal data on innocent people. It will be shared with federal agencies outside of DHS as well as state and local law enforcement and foreign governments. And yet, we still know very little about it.

The records DHS plans to include in HART will chill and deter people from exercising their First Amendment protected rights to speak, assemble, and associate. Data like face recognition makes it possible to identify and track people in real time, including at lawful political protests and other gatherings. Other data DHS is planning to collect—including information about people’s “relationship patterns” and from officer “encounters” with the public—can be used to identify political affiliations, religious activities, and familial and friendly relationships. These data points are also frequently colored by conjecture and bias.

In late May, EFF filed comments criticizing DHS’s plans to collect, store, and share biometric and biographic records it receives from external agencies and to exempt this information from the federal Privacy Act. These newly-designated “External Biometric Records” (EBRs) will be integral to DHS’s bigger plans to build out HART. As we told the agency in our comments, DHS must do more to minimize the threats to privacy and civil liberties posed by this vast new trove of highly sensitive personal data.

DHS’s new HART database will allow the agency to vastly expand the types of records it can collect and store. HART will support at least seven types of biometric identifiers, including face and voice data, DNA, scars and tattoos, and a blanket category for “other modalities.” It will also include biographic information, like name, date of birth, physical descriptors, country of origin, and government ID numbers. And it will include data we know to by highly subjective, including information collected from officer “encounters” with the public and information about people’s “relationship patterns.”

DHS slide showing expansion of its new HART biometric and biographic database

HART will Impinge on First Amendment Rights

DHS plans to include records in HART that will chill speech and deter people from associating with others.

DHS’s face recognition roll-out is especially concerning. The agency uses mobile biometric devices that can identify faces and capture face data in the field, allowing its ICE (immigration) and CBP (customs) officers to scan everyone with whom they come into contact, whether or not those people are suspected of any criminal activity or an immigration violation. DHS is also partnering with airlines and other third parties to collect face images from travelers entering and leaving the U.S. When combined with data from other government agencies, these troubling collection practices will allow DHS to build a database large enough to identify and track all people in public places, without their knowledge—not just in places the agency oversees, like airports, but anywhere there are cameras.

Police abuse of facial recognition technology is not a theoretical issue: it’s happening today. Law enforcement has already used face recognition on public streets and at political protests. During the protests surrounding the death of Freddie Gray in 2015, Baltimore Police ran social media photos against a face recognition database to identify protesters and arrest them. Recent Amazon promotional videos encourage police agencies to acquire that company’s face “Rekognition” capabilities and use them with body cameras and smart cameras to track people throughout cities. At least two U.S. cities are already using Rekognition.

DHS compounds face recognition’s threat to anonymity and free speech by planning to include “records related to the analysis of relationship patterns among individuals.” We don’t know where DHS or its external partners will be getting these “relationship pattern” records, but they could come from social media profiles and posts, which the government plans to track by collecting social media user names from all foreign travelers entering the country.

Social media records, even if they are publicly available, can include highly personal and private information, and the fear that the government may be collecting and searching through this information may cause people to self-censor what they say online. The data collected also won’t be limited to information about foreign travelers—travelers’ social media records may include information on family members and friends who are U.S. citizens or lawful permanent residents, two groups protected explicitly by the Privacy Act. As the recent, repeated Facebook scandals are showing us, even when you think you have done everything you can to protect your own data, it could easily be disclosed without your control through the actions of your friends and contacts or Facebook itself.

DHS’s “relationship pattern” records will likely be misleading or inaccurate. DHS acknowledges that these records will include “non-obvious relationships.” However, if the relationships are “non-obvious,” one has to question whether they truly exist. Instead, DHS could be seeing connections among people that are based on nothing more than “liking” the same news article, using the same foreign words, or following the same organization on social media. This is highly problematic because records like these frequently inform officer decisions to stop, search, and arrest people.

DHS plans to include additional records in HART that could be based on or impact First Amendment protected speech and activity. Records will include “miscellaneous officer comment information” and “encounter data.” These types of information come from police interactions with civilians, and are often collected under extremely questionable legal circumstances. For example, ICE officers use mobile devices to collect biometric and biographic data from people they “encounter” in the field, including via unauthorized entry into people’s homes and Bible study groups, and in public places where people congregate with other members of their community, such as on soccer fields, in community centers, and on buses. “Encounters” like these, whether they are conducted by ICE or by state or local police, are frequently not based on individualized suspicion that a civilian has done anything wrong, but that doesn’t prevent the officer from stockpiling any information obtained from the civilian during the encounter.

Finally, DHS relies on data from gang databases (its own and those from states), which often contain unsubstantiated data concerning people’s status and associations and are notoriously inaccurate. DHS has even fabricated gang status as an excuse to deport people.

HART Will Include Inaccurate Data and Will Share that Data with Other Agencies

DHS is not taking necessary steps with its new HART database to determine whether its own data and the data collected from its external partners are sufficiently accurate to prevent innocent people from being identified as criminal suspects, immigration law violators, or terrorists.

DHS has stated that it intends to rely on face recognition to identify data subjects across a variety of its mission areas, and “face matching” is one of the first components of the HART database to be built out. However, face recognition frequently is an inaccurate and unreliable biometric identifier. DHS’s tests of its own systems found significantly high levels of inaccuracy—the systems falsely rejected as many as 1 in 25 travelers. As a Georgetown report recently noted, “DHS’ error-prone face scanning system could cause 1,632 passengers to be wrongfully delayed or denied boarding every day at New York’s John F. Kennedy (JFK) International Airport alone.”

DHS’s external partners are also employing face recognition systems with high rates of inaccuracy. For example, FBI has admitted that its Next Generation Identification database “may not be sufficiently reliable to accurately locate other photos of the same identity, resulting in an increased percentage of misidentifications.” Potential foreign partners such as police departments in the United Kingdom use face recognition systems with false positive rates as high as a 98%—meaning that for every 100 people identified as suspects, 98 in fact were not suspects.

DHS Slide Showing Partner Agencies

People of color and immigrants will shoulder much more of the burden of these misidentifications. For example, people of color are disproportionately represented in criminal and immigration databases, due to the unfair legacy of discrimination in our criminal justice and immigration systems. Moreover, FBI and MIT research has shown that current face recognition systems misidentify people of color and women at higher rates than whites and men, and the number of mistaken IDs increases for people with darker skin tones. False positives represent real people who may erroneously become suspects in a law enforcement or immigration investigation. This is true even if a face recognition system offers several results for a search instead of one; each of the people identified could be detained or brought in for questioning, even if there is nothing else linking them to a crime or violation.

In addition to accuracy problems inherent in face recognition, DHS’s own immigration data has also been shown to be unacceptably inaccurate. A 2005 Migration Policy Institute study analyzing records obtained through FOIA found “42% of NCIC immigration hits in response to police queries were ‘false positives’ where DHS was unable to confirm that the individual was an actual immigration violator.” A 2011 study of DHS’s Secure Communities program found approximately 3,600 United States citizens were improperly caught up in the program due to incorrect immigration records. As these inaccurate records are propagated throughout DHS’s partner agencies’ systems, it will become impossible to determine the source of the inaccuracy and correct the data.

HART Is Fatally Flawed and Must Be Stopped

DHS’s plans for future data collection and use should make us all very worried. For example, despite pushback from EFF, Georgetown, ACLU, and others, DHS believes it’s legally authorized to collect and retain face data from millions of U.S. citizens traveling internationally. However, as Georgetown’s Center on Privacy and Technology notes, Congress has never authorized face scans of American citizens.

Despite this, DHS plans to roll out its face recognition program to every international flight in the country within the next four years. DHS has stated “the only way for an individual to ensure he or she is not subject to collection of biometric information when traveling internationally is to refrain from traveling.”

This is just the tip of the iceberg. CBP Commissioner Kevin McAleenan has stated CBP wants to be able to use biometrics to “confirm the identity of travelers at any point in their travel,” not just at entry to or exit from the United States. This includes creating a “biometric pathway” to track all travelers through airports, from check-in, through security, into airport lounges and shops, and onto flights. Given CBP’s recent partnerships with airlines and plans to collect social media credentials, this could also mean CBP plans to track travelers from the moment they begin their internet travel research. Several Congress members have introduced legislation to legitimize some of these plans.

Congress has expressed concerns with DHS’s biometric programs. Senators Edward Markey and Mike Lee, in a recent letter addressed to the agency, stated, “[w]e are concerned that the use of the program on U.S. citizens remains facially unauthorized[.] . . . We request that DHS stop the expansion of this program and provide Congress with its explicit statutory authority to use and expand a biometric exit program on U.S. citizens.” The senators have urged DHS to propose a rulemaking to clarify its plans for biometric exit. Congress also withheld funds last year from DHS’s Office of Biometric Identity Management.

DHS’s Inspector General criticized the agency last year for failure to properly train its personnel on how biometric systems worked and noted that the agency’s reliance on third parties to verify travelers leaving the country “occasionally provided false departure or arrival status on visitors.” The OIG is again investigating the biometric exit program this year and plans to “assess whether biometric data collected at pilot locations has improved DHS's ability to verify departures.” The Government Accountability Office has also looked into the agency’s programs, criticizing the reliability of DHS’s data and the agency’s failure to evaluate whether a program that collects biometrics from all travelers leaving the country was even feasible.

However, these actions are not enough. DHS needs to end its plans to use its HART database to collect even more biometric and biographic information about U.S. citizens and foreigners. This system poses a very real threat to First Amendment-protected activities. Further, DHS has a well-documented history of poor data management, and face recognition has a high rate of misidentifications. Congress must step in with more oversight and act now to put the brakes on DHS’s broad expansion of data collection.

Previously, EFF recommended to PGP users that, because of new attacks revealed by researchers from Münster University of Applied Sciences, Ruhr University Bochum, and NXP Semiconductors, they should disable the PGP plugins in their email clients for now. You can read more detailed rationale for this advice in our FAQ on the topic, but undoubtedly the most frequently asked question has been: how long is for now? When will it be safe to use PGP for email again?

The TL;DR (although you really should read the rest of this article): coders and researchers across the PGP email ecosystem have been hard at work addressing the problems highlighted by the paper—and after their sterling efforts, we believe some parts are now safe for use, with sufficient precautions.

If you use PGP for email using Thunderbird 52.8 and Enigmail 2.0.6, you can update to the latest versions of Enigmail, turn on “View as Plain Text” (see below), re-enable Enigmail, and get back to using PGP in email.

Other email clients have specific weaknesses reported in the EFAIL paper which may or may not have since been patched. Even if they were patched, depending on how the patch was implemented, they may or may not still be vulnerable to other exploits in the class of vulnerabilities described in the paper. So be careful out there: keep your software regularly updated, and choose conservative privacy settings for the client you use to decrypt and encrypt PGP mail. In particular, we continue to not recommend using PGP with email clients that display HTML mail. If possible, turn off that feature—and if you can’t, consider decrypting and encrypting messages using an external, dedicated application.

And remember, the safety of your messages also depends on the security of your correspondents, so encourage them to use clients that are safe from EFAIL too. You should even think about asking them to confirm which versions they’re using to ensure it’s safe to correspond.

The Fixes in Detail

The researchers’ publication contains a proof-of-concept exploit that affected users who protect their communications with PGP. The exploit allowed an attacker to use the victim’s own email client to decrypt previously acquired messages (or other protected information) and return the decrypted content to the attacker without alerting the victim. The attacker needed access to the previous (still encrypted) text. Unfortunately, an attacker that has access to your old encrypted emails is exactly the serious threat that the most targeted populations use PGP to protect against.

The attack, once understood, is simple to deploy. However, despite the fact that the vulnerability had been disclosed to the relevant developers months ago, many of the most popular ways of using PGP and email had no protection against the attack at the time of the paper’s publication. Because so many people in extremely vulnerable roles—such as journalists, human rights defenders, and dissidents—expect PGP to protect them against this kind of attack, we warned PGP users to hold off using it for secure communications and disable PGP plugins in their email clients until these problems were fixed.

That advice prompted a lot of discussion: some approving, some less so. We’re talking to everybody we can in the PGP community to hear about their experiences, and we hope to publish the deeper lessons we, and others, have learned from EFAIL and how it was handled.

But for now, we’ve been concentrating on testing whether the exploit has been successfully patched in the software setups most used by vulnerable groups.

Turning Off HTML vs Disabling Remote Content Loading

Many experts, after reading the research paper, were surprised we recommended disabling PGP in email, when it seemed like some less drastic options (such as turning off remote resource loading, and/or turning off their email client’s ability to read and decrypt HTML mail) would have sufficed to fend off the most obvious EFAIL attack.

But upon closer reading of the text of the paper, it becomes clear that the researchers describe exactly how to circumvent mail clients' attempts to block the remote loading of resources. Other researchers have created, and continue to create, exploits that can defeat this supposed protection. Further, with remote content turned off, a button is usually present to load remote content by choice. An alternative label for that innocuous-seeming button would be, “Leak all of my past encrypted emails to an attacker.” Having that button available to users is giving them an opportunity to shoot themselves in the foot.

Then there’s the other option for protection: turning off HTML in mail clients. At the time, the researchers were not confident that this protection was sufficient: they had already discovered a way of defeating S/MIME, a comparable email encryption standard, with HTML mail turned off. And while their simplest example used HTML to steal data, they also spelled out hypothetical attacks that might not need it.

Turning off HTML mail appears to be holding up as a defense. Unfortunately, not every client has this as an option: you can consistently turn off HTML in Thunderbird, but not in Apple Mail.

So, our first recommendation: whatever client you use, turn off HTML email. We have instructions for this in Thunderbird below.

Thunderbird+Enigmail Users Can Turn PGP Back On

Thunderbird and Enigmail’s developers have been working on ways to protect against the EFAIL vulnerabilities. As of version 2.0.6 (released Sunday May 27), Enigmail has released patches that defend against all known exploits described in the EFAIL paper, along with some new ones in the same class that other researchers were able to devise, which beat earlier Enigmail fixes. Each new fix made it a little harder for an attackerto get through Enigmail’s defenses. We feel confident that, if you update to this version of Enigmail (and keep updating!), Thunderbird users can turn their PGP back on.

But, while Enigmail now defends against most known attacks even with HTML on, the EFAIL vulnerability demonstrated just how dangerous HTML in email is for security. Thus, we recommend that Enigmail users also turn off HTML by going to View > Message Body As > Plain Text.

1. First click on the Thunderbird hamburger menu (the three horizontal lines).

2. Select “View” from the right side of the menu that appears.

3. Select “Message Body As” from the menu that appears, then select the “Plain Text” radio option.

Viewing all email in plaintext can be hard, and not just because many services send only HTML emails. Turning off HTML mail can pose some usability problems, such as some attachments failing to show up. Thunderbird users shouldn't have to make this trade-off between usability and security, so we hope that Thunderbird will take a closer look at supporting their plaintext community from now on. As the software is now, however, users will need to decide for themselves whether to take the risk of using HTML mail; the most vulnerable users should probably not take that risk, but the right choice for your community is a judgment call based on your situation.

Apple Mail+GPGTools Users Should Keep PGP Disabled For Now

Since Apple Mail doesn’t provide a supported plugin interface, the GPGTools developers have faced a difficult challenge in updating GPGTools to defend against EFAIL. Additionally, Apple Mail has no option for users to view all emails without HTML (also called plaintext-only). Apple Mail only provides an option to disable remote content loading, which does not defend against existing attacks.

Despite the challenges with Apple Mail, the GPGTools developers are working hard on fixes for all reported EFAIL-related attacks, and a release is expected very soon. That said, we do not recommend re-enabling GPGMail with Apple Mail yet.

Other Clients

The EFAIL researchers did a great job reviewing and finding problems with a wide set of desktop email clients. Using one of the lesser-known clients may or may not leave you vulnerable to the specific vulnerabilities outlined in the paper. And depending on the way the patches work, the patches may or may not protect against problems discovered by future research into the same class of problems.

Our advice for all PGP email users remains the same: if you depend on your email client to decipher PGP messages, make sure it doesn’t decode HTML mail, and check with its creators to see whether they’ve been working on protecting against EFAIL.

The Future of Pretty Good Privacy

Unlike situations where a fix only requires one piece of software to be mended and upgraded, some of the EFAIL problems come from interaction between all the different pieces of using PGP with email: email clients like Thunderbird, PGP plugins like Enigmail, and PGP implementations like GnuPG.

There are lots of moving parts to be fixed, and some of the fixes involve changes to the very core of how they function. It’s not surprising that it takes time to coordinate against attacks that exploit the complex interconnections between all of these parts.

EFF has fought, in the courts and in the corridors of power, for the right to write, export, and use decentralized and open source encryption tools, for as long as PGP has existed. We’re under no illusion about how hard this work is, or how underappreciated and underfunded it can be, or how vital its results are, especially for those targeted by the most powerful and determined of attackers. The transparent and public cooperation of all the parts of the PGP system make for some hard conversations sometimes, but that’s what keeps it honest and accountable—and that’s what keeps us all safe.

But if we’re to continue to use and recommend PGP for the cases where it is most appropriate—protecting the most vulnerable and targeted of Internet users—we need to carry on that conversation. We need to cooperate to radically improve the secure email experience, to learn from what we know about modern cryptography and usability, and to decide what true 21st-century secure email must look like.

It’s time to upgrade not just your PGP email client, but also the entire secure email ecosystem, so that it’s usable, universal, and stable.

EFF has joined the ACLU and a coalition of civil liberties organizations demanding that Amazon stop powering a government surveillance infrastructure. Last week, we signed onto a letter to Amazon condemning the company for developing a new face recognition product that enables real-time government surveillance through police body cameras and the smart cameras blanketing many cities. Amazon has been heavily marketing this tool—called “Rekognition”—to law enforcement, and it’s already being used by agencies in Florida and Oregon. This system affords the government vast and dangerous surveillance powers, and it poses a threat to the privacy and freedom of communities across the country. That includes many of Amazon’s own customers, who represent more than 75 percent of U.S. online consumers.

As the joint letter to Amazon CEO Jeff Bezos explains, Amazon’s face recognition technology is “readily available to violate rights and target communities of color.” And as we’ve discussed extensively before, face recognition technology like this allows the government to amp up surveillance in already over-policed communities of color, continuously track immigrants, and identify and arrestprotesters and activists. This technology will not only invade our privacy and unfairly burden minority and immigrant communities, but it will also chill our free speech.

Amazon should stand up for civil liberties, including those of its own customers, and get out of the surveillance business.

Since the ACLU sounded the alarm, others have started to push back on Amazon. The Congressional Black Caucus wrote a separate letter to Bezos last week, stating, “We are troubled by the profound negative unintended consequences this form of artificial intelligence could have for African Americans, undocumented immigrants, and protesters.” The CBC pointed out the “race-based ‘blind spots’ in artificial intelligence” that result in higher numbers of misidentifications for African Americans and women than for whites and men, and called on Amazon to hire more lawyers, engineers, and data scientists of color. Two other members of Congress followed up with another letter on Friday.

Amazon’s partnership with law enforcement isn’t new. Amazon already works with agencies across the country, offering cloud storage services through Amazon Web Services (AWS) that allow agencies to store the extremely large video files generated by body and other surveillance cameras. Rekognition is an inexpensive add-on to AWS, costing agencies approximately $6-$12 per month.

Rekognition doesn’t just identify faces. It also can track people through a scene, even if their faces aren’t visible. It can identify and catalog a person’s gender, what they’re doing, what they’re wearing, and whether they’re happy or sad. It can identify other things in a scene, like dogs, cars, or trees, and can recognize text, including street signs and license plates. It also offers to flag things it considers “unsafe” or “inappropriate.”

And the technology is powerful, if Amazon’s marketing materials are accurate. According to the company, Rekognition can identify people in real-time by instantaneously searching databases containing tens of millions of faces, detect up to 100 people in “challenging crowded” images, and track people through video—within a single shot and across multiple shots, and even when the camera is in motion—which makes “investigation and monitoring of individuals easy and accurate” for “security and surveillance applications.” Amazon has even advertised Rekognition for use on police officer “bodycams.” (The company took mention of bodycams off its website after the ACLU voiced concern, but “[t]hat appears to be the extent of its response[.]”)

This is an example of what can go wrong when police departments unilaterally decide what privacy invasions are in the public interest, without any public oversight or input. That’s why EFF supports Community Control Over Police Surveillance (CCOPS) measures, which ensure that local police can't do deals with surveillance technology companies without going through local city councils and the public. People deserve a say in what types of surveillance technology police use in their communities, and what policies and safeguards the police follow. Further, governments must make more balanced, accountable decisions about surveillance when communities and elected officials are involved in the decision-making process.

Amazon responded to the uproar surrounding the announcement of its government surveillance work by defending the usefulness of the program, noting that it has been used to find lost children in amusement parks and to identify faces in the crowd at the royal wedding. But it failed to grapple with the bigger issue: as one journalist put it, “Nobody is forcing these companies to supply more sensitive image-recognition technology to those who might use it in violation of human or civil rights.”

Amazon should stand up for civil liberties, including those of its own customers, and get out of the surveillance business. It should cut law enforcement off from using its face recognition technology, not help usher in a surveillance state. And communities across the country should demand baseline measures to stop law enforcement from acquiring and using powerful new surveillance systems without any public oversight or accountability in the future.

When we wrote of award-winning journalist Wael Abbas being silenced by social media platforms in February, we never suspected that those suspensions would reach beyond the internet to help silence him in real life. But, following Abbas's detention on Wednesday by police in Cairo, we now fear that decisions—and lack of transparency—made by Silicon Valley companies will help Egyptian authorities in their crackdown on journalists and human rights activists.

Abbas was taken at dawn on May 23 by police to an undisclosed location, according to news reports which quote his lawyer, Gamal Eid. The Arabic Network for Human Rights Information (ANHRI) reported that Abbas was not shown a warrant or given a reason for his arrest. He appeared in front of state security yesterday and was questioned and ordered by prosecutors to be held for fifteen days. According to the Association for Freedom of Thought and Expression (AFTE), Abbas was charged with “involvement in a terrorist group”, “spreading false news” and “misuse of social networks.”

As we detailed previously, Abbas is known for his work exposing police brutality and other abuses by Egyptian authorities, and as such, he's faced backlash from the state before. He was convicted in 2010 on charges of "providing telecommunications service to the public without permission from authorities" after publishing a series of blog posts in which he accused the Egyptian government of human rights abuses.

Twitter does not comment publicly on individual accounts, but in December, Abbas claimed in a Facebook post that Twitter had not provided him with a reason for his suspension. Now, at least one local media outlet is reporting that Abbas's Twitter account—which was suspended in December 2017—was taken down due to incitement to violence.

It seems clear that the messaging around Abbas' detention is that his arrest was connected to his posts on Facebook and Twitter, and that the prosecution and media are using his suspension by these services as part of the evidence for his guilt.

In the medium term, this is yet another reason why we need more transparency and clarity in social media takedowns. Without transparency, these acts of private censorship are already effectively a hidden court, with little due process. These decisions are being used as evidence by media campaigns against activists, by real-world courts (some, like the "media committees" that judged Abbas, with little due process of their own) — and with real consequences.

In the short term, however, the far more importanct step is for the Egyptian state to immediately release Wael Abbas, an independent journalist, from these ridiculous charges, and restore his freedom and the freedom of the online Egyptian press. We call on Egypt to Free Wael Abbas.

We’ve learned that the FBI has been misinforming Congress and the public as part of its call for backdoor access to encrypted devices. For months, the Bureau has claimed that encryption prevented it from legally searching the contents of nearly 7,800 devices in 2017, but today the Washington Post reports that the actual number is far lower due to "programming errors" by the FBI.

Frankly, we’re not surprised. FBI Director Christopher Wray and others argue that law enforcement needs some sort of backdoor “exceptional access” in order to deal with the increased adoption of encryption, particularly on mobile devices. And the 7,775 supposedly unhackable phones encountered by the FBI in 2017 have been central to Wray’s claim that their investigations are “Going Dark.” But the scope of this problem is called into doubt by services offered by third-party vendors like Cellebrite and Grayshift, which can reportedly bypass encryption on even the newest phones. The Bureau’s credibility on this issue was also undercut by a recent DOJ Office of the Inspector General report, which found that internal failures of communication caused the government to make false statements about its need for Apple to assist in unlocking a seized iPhone as part of the San Bernardino case.

Given the availability of these third-party solutions, we’ve questioned how and why the FBI finds itself thwarted by so many locked phones. That’s why last week, EFF submitted a FOIA request for records related to Wray’s talking points about the 7,800 unhackable phones and the FBI’s use of outside vendors to bypass encryption.

The stakes here are high. Imposing an exceptional access mandate on encryption providers would be extraordinarily dangerous from a security perspective, but the government has never provided details about the scope of the supposed Going Dark problem. The latest revision to Director Wray’s favorite talking point demonstrates that the case for legislation is even weaker than we thought. We hope that the government is suitably forthcoming to our FOIA request so that we can get to the bottom of this issue.

A group of researchers recently released a paper that describes a new class of serious vulnerabilities in the popular encryption standard PGP (including GPG) as implemented in email clients. Until the flaws described in the paper are more widely understood and fixed, users should arrange for the use of alternative end-to-end secure channels, such as Signal, and temporarily stop sending and especially reading PGP-encrypted email. See EFF’s analysis and FAQ for more detail.

Our current recommendation is to disable PGP integration in email clients. This is the number one thing you can do to protect your past messages, and prevent future messages that you receive from being read by an attacker. You should also encourage your contacts to do the same.

Methods for reading encrypted email on the command line vary between operating systems, so separate instructions are needed. The instructions linked above for disabling the plugin from your mail client leave your PGP keyring in place, so you will use the same passphrase when prompted.

If you have disabled the PGP plugin from your mail client and saved a copy of an encrypted email to your desktop, this guide will help you read that message in as safe a way as possible given what we know about the vulnerability described by EFAIL.

Note that the first three steps (opening the terminal) will vary between desktop environments.

Open the Activities view by clicking all the way in the top left corner of your screen.

2. Type “terminal” into the search bar, and press Enter. This will open the command prompt.

3. Type “cd Desktop” to go to your desktop. Mind the capital ‘D’!

4. Type “gpg -d encrypted.eml” using the name of the file you saved earlier. This may prompt you for your PGP passphrase depending on your configuration and recent usage, and will output the full email in the terminal window.