Surveillance
Self-Defense

Blog

Sextortion Scam: What to Do If You Get the Latest Phishing Spam Demanding Bitcoin

You may have arrived at this post because you received an email from a purported hacker who is demanding payment or else they will send compromising information—such as pictures sexual in nature—to all your friends and family. You’re searching for what to do in this frightening situation.

Don’t panic. Contrary to the claims in your email, you haven't been hacked (or at least, that's not what prompted that email). This is merely a new variation on an old scam which is popularly being called "sextortion." This is a type of online phishing that is targeting people around the world and preying off digital-age fears.

We’ll talk about a few steps to take to protect yourself, but the first and foremost piece of advice we have: do not pay the ransom.

We have pasted a few examples of these emails at the bottom of this post. The general gist is that a hacker claims to have compromised your computer and says they will release embarrassing information—such as images of you captured through your web camera or your pornographic browsing history—to your friends, family, and co-workers.  The hacker promises to go away if you send them thousands of dollars, usually with bitcoin.

What makes the email especially alarming is that, to prove their authenticity, they begin the emails showing you a password you once used or currently use.

Again, this still doesn't mean you've been hacked. The scammers in this case likely matched up a database of emails and stolen passwords and sent this scam out to potentially millions of people, hoping that enough of them would be worried enough and pay out that the scam would become profitable.

EFF researched some of the bitcoin wallets being used by the scammers. Of the five wallets we looked at only one had received any bitcoin, in total about 0.5 bitcoin or $4,000 at the time of this writing.  It’s hard to say how much the scammers have received in total at this point since they appear to be using different bitcoin addresses for each attack, but it’s clear that at least some people are already falling for this scam.

Here are some quick  answers to the questions many people ask after receiving these emails.

They have my password! How did they get my password?

Unfortunately, in the modern age, data breaches are common and massive sets of passwords make their way to the criminal corners of the Internet. Scammers likely obtained such a list for the express purpose of including a kernel of truth in an otherwise boilerplate mass email.

If the password emailed to you is one that you still use, in any context whatsoever,  STOP USING IT and change it NOW! And regardless of whether or not you still use that password it's always a good idea to use a password manager.

And of course, you should always change your password when you’re alerted that your information has been leaked in a breach. You can also use a service like Have I Been Pwned to check whether you have been part of one of the more well-known password dumps.

Should I respond to the email?

Absolutely not. With this type of scam, the perpetrator relies on the likelihood that a small number of people will respond out of a batch of potentially millions. Fundamentally this isn't that much different from the old Nigerian prince scam, just with a different hook. By default they expect most people will not even open the email, let alone read it. But once they get a response—and a conversation is initiated—they will likely move into a more advanced stage of the scam. It’s better to not respond at all.

So,  I shouldn’t pay the ransom?

You should not pay the ransom. If you pay the ransom, you’re not only losing money but you’re encouraging the scammers to continue phishing other people. If you do pay, then the scammers may also use that as a pressure point to continue to blackmail you, knowing that you’re are susceptible.

What should I do instead?

As we said before, for sure stop using the password that the scammer used in the phishing email, and consider employing a password manager to keep your passwords strong and unique. Moving forward, you should make sure to enable two-factor authentication whenever that is an option on your online accounts. You can also check out our Surveillance Self-Defense guide for more tips on how to protect your security and privacy online.

One other thing to do to protect yourself is apply a cover over your computer’s camera. We offer some through our store, but a small strip of electrical tape will do.

We know this experience isn't fun, but it's also not the end of the world. Just ignore the scammers' empty threats and practice good password hygiene going forward!

Example 1

I am aware one of your passphrase: password. Lets get directly to point. Not a single person has compensated me to investigate about you. You do not know me and you are probably wondering why you're getting this e mail?actually, I actually installed a software on the adult vids (sex sites) site and you know what, you visited this web site to have fun (you know what I mean). When you were viewing videos, your internet browser initiated working as a Remote control Desktop that has a key logger which provided me access to your display screen and also web cam. Right after that, my software program collected your complete contacts from your Messenger, FB, and email . After that I created a double-screen video. 1st part shows the video you were viewing (you've got a good taste haha . . .), and 2nd part shows the view of your webcam, and its u. 
You do have only 2 alternatives. We are going to understand these types of choices in aspects:
1st solution is to disregard this message. In this case, I am going to send your actual video clip to just about all of your contacts and thus you can easily imagine about the disgrace you feel. Not to mention should you be in a relationship, just how it will eventually affect?
Number two choice will be to pay me $3000. We will think of it as a donation. As a consequence, I most certainly will without delay eliminate your videotape. You will keep going on your daily life like this never happened and you will not hear back again from me.
You'll make the payment through Bitcoin (if you do not know this, search for "how to buy bitcoin" in Google).

Example 2

Hi, victim.I write yоu becаusе I put а mаlware оn the wеb раge with porn whiсh yоu hаve visitеd.My virus grаbbed all your рersonal infо аnd turnеd on yоur сamеrа which сaрtured the рroсеss оf your onаnism. Just aftеr that the soft savеd yоur соntaсt list.I will dеlеte thе сompromising video and infо if you pаy me 999 USD in bitcoin. This is address fоr рaymеnt : 1K2jNTLdbHEwaALQWKMeGoKLWD67Cb6q8BI give yоu 30 hоurs aftеr you ореn my mеssаge for making the trаnsactiоn.As sоon аs yоu reаd the mеssаgе I'll see it right awаy.It is nоt necessary tо tell mе thаt you hаve sеnt money to me. This address is соnneсtеd tо yоu, my systеm will dеlete еverything automаtically aftеr trаnsfer соnfirmаtiоn.If yоu nееd 48 h just reрly оn this letter with +.Yоu сan visit thе pоlicе stаtion but nobоdy cаn hеlp yоu.If you try to dеceive mе , I'll sеe it right аway !I dont live in yоur соuntry. So they саn nоt track my lосаtiоn evеn for 9 months.Goodbyе. Dоnt fоrget аbоut thе shame and tо ignore, Yоur life can be ruined.

Example 3

𝕨hat's up.
If you were more vigilant while playing with yourself, I wouldn't worry you. I don't think that playing with yourself is very bad, but when all colleagues, relatives and friends get video record of it- it is obviously for u.
I adjusted virus on a porn web-site which you have visited. When the victim press on a play button, device begins recording the screen and all cameras on your device starts working.
мoreover, my program makes a dedicated desktop supplied with key logger function from your device , so I could get all contacts from ya e-mail, messengers and other social networks. I've chosen this e-mail cuz It's your working address, so u should read it.
Ì think that 730 usd is pretty enough for this little false. I made a split screen vid(records from screen (u have interesting tastes ) and camera ooooooh... its awful ᾷF)
Ŝo its your choice, if u want me to erase this сompromising evidence use my ƅitсȯin wᾷllеt aďdrеss-  1JEjgJzaWAYYXsyVvU2kTTgvR9ENCAGJ35 
Ƴou have one day after opening my message, I put the special tracking pixel in it, so when you will open it I will know.If ya want me to share proofs with ya, reply on this message and I will send my creation to five contacts that I've got from ur contacts.
P.S... You can try to complain to cops, but I don't think that they can solve ur problem, the investigation will last for several months- I'm from Estonia - so I dgf LOL

Example 4

I know, password, is your pass word. You may not know me and you're most likely wondering why you are getting this e mail, correct?
In fact, I placed a malware on the adult vids (porn material) web-site and you know what, you visited this website to have fun (you know what I mean). While you were watching video clips, your internet browser initiated operating as a RDP (Remote Desktop) that has a keylogger which provided me access to your screen and also webcam. Immediately after that, my software program gathered your entire contacts from your Messenger, social networks, as well as email.
What did I do?
I made a double-screen video. 1st part shows the video you were watching (you have a good taste lmao), and 2nd part shows the recording of your webcam.
exactly what should you do?

Well, I believe, $2900 is a fair price for our little secret. You'll make the payment by Bitcoin (if you don't know this, search "how to buy bitcoin" in Google).
BTC Address: 1MQNUSnquwPM9eQgs7KtjDcQZBfaW7iVge
(It is cAsE sensitive, so copy and paste it)

Note:
You have one day in order to make the payment. (I have a specific pixel in this email message, and at this moment I know that you have read through this email message). If I do not get the BitCoins, I will definitely send out your video recording to all of your contacts including family members, coworkers, etc. However, if I do get paid, I'll destroy the video immidiately. If you want to have evidence, reply with "Yes!" and I will certainly send out your video to your 14 contacts. This is the non-negotiable offer, so please don't waste my personal time and yours by responding to this email message.

Moving Your Site From "Not Secure" to Secure

Maybe you’re a beginner to web development, but you’ve done the hard work: you taught yourself what you needed to know, and you’ve lovingly made that website and filled it with precious content. But one last task remains: you don’t have that little green padlock with the word “secure” beside your website’s address. You don’t yet have that magical “S” after “HTTP”.

You might have heard or noticed recently that something is different on Google Chrome: if your website does not have a HTTPS certificate, your visitors will see a warning on your pages, cautioning them about your page’s security. This is because Google Chrome browser is now marking unencrypted websites that don’t provide HTTPS as “Not Secure.”

If you want to:

  • mark your website as secure
  • retain visitors to your website and boost search engine optimization
  • provide privacy to your site visitors
  • keep out nosey neighbors peeping on your and your users’ connections
  • prevent malicious actors from tampering with content on your site
  • prove that your site is not being impersonated (or prevent some malicious actor from pretending to be you)
  • do this all for free

Then, this post about getting an HTTPS certificate is for you! If transport-layer security, certificate authorities, and HTTPS are new concepts for you, check out this comic from How HTTPS Works: https://howhttps.works/.

The details about how to enable HTTPS on your site depend crucially on your hosting environment. Depending on the provider and software your site is hosted with, HTTPS setup could range anywhere from automatic, to a single click, to impossible (if your hosting provider specifically doesn’t allow HTTPS). For many web site owners, the most challenging or unfamiliar step in enabling HTTPS is getting a certificate, a document issued by a publicly-trusted certificate authority.  A valid certificate is required for browsers to confirm that encrypted connections to your site are secure.

EFF helped create a free, automated, publicly-trusted certificate authority called Let’s Encrypt, which is now the most-used certificate authority on the web. In this post, we’re going to provide advice about the process of getting a certificate from Let’s Encrypt. It’s a convenient option in many cases because it doesn’t charge money for the certificates, they’re accepted by all mainstream browsers, and the certificate renewal process can often be automated with EFF’s tool Certbot.

There are also many other certificate authorities (CAs), which have different policies and procedures for getting certificates. Most will expect you to pay for a certificate unless you have some other relationship with them (for example, through a university that gets free certificates from a particular CA, or if you use a web host that has a commercial relationship with a CA to let subscribers get certificates at no additional charge). For most purposes, you won’t get a different level of privacy or security protection by choosing one CA rather than another, so you can choose whichever public CA you conclude best meets your needs.

We’ve compiled some resources that we’re sharing here for beginners who are new to getting their own HTTPS certificates from the Let’s Encrypt Certificate Authority.

This blogpost isn’t a full tutorial, but is intended to help you get started with the journey to get a HTTPS certificate:

  1. Find whether your web hosting provider already provides free HTTPS certificates.
  2. Confirm with your web hosting provider to see what options are available for HTTPS.
  3. Learn what system and software your server uses.
  4. Troubleshoot until you find an appropriate tutorial to get HTTPS certificates for your site.
  5. Check that HTTPS is working!

We’re trying to improve this process to encrypt the web. When Let’s Encrypt first launched in 2016, only 40% of website connections were encrypted. Today, that number is as high as 73%. Help websites get to 100% encrypted and make the Internet more secure for everyone.

1. Find whether your web hosting provider already provides free HTTPS certificates.

Do you use Tumblr? Github pages? Weebly? Or a variety of other hosting providers?

There’s a chance that your web host already provides an option to obtain a certificate automatically, either from Let’s Encrypt or a different CA. Check if this is already described in your web host’s site or administrative interface. You can also check if they’re on this master list of web hosts supporting Let’s Encrypt, and if they have up-to-date instructions.

If you find your web host on the list of supported providers, or you already know that it has a tutorial or guide for using its HTTPS support, follow their instructions for enabling HTTPS on your site. If it is not supported, proceed below.

2. Confirm with your web hosting provider to see what options are available for HTTPS.

See if your site administration page has an option to enable HTTPS.

A lot of providers—including many that aren't on that community list—use software like cPanel on some of their hosting plans to let subscribers configure their hosting services. cPanel normally has a feature to let the subscriber automatically get a certificate for free (which may be either from Let's Encrypt or another CA).

Some of cPanel's competitors such as Plesk also have this configurable option. However, some hosts may be running outdated software or have deliberately disabled the ability to get a free certificate.

Get in touch with your provider and ask them about their options of HTTPS support.

Many providers are already working on making HTTPS available or  or may already provide an HTTPS feature. You can contact them and ask to see if this might be an option.

“Dear [company],

I would like to obtain a free HTTPS certificate for my site. I was wondering if this is already in the works?

Thank you.”

Your provider may then be able to guide you about whether your hosting plan allows you administrative access to the server (in which case a tool like Certbot may be relevant for you). See the next step if this is your circumstance.

3. Learn what system and software your server uses.

If your hosting provider doesn’t integrate Let’s Encrypt but you do have administrative access to your server, you can use software to obtain and install a certificate. This is dependent on what software your web server is using, and what operating system your server is running on.

If the above sounds like unfamiliar jargon and you’re not sure about what software or system you’re using, don’t worry! You can email your webhost to get that information

Try using the following language in an email to your webhost (influenced from Matt Mitchell).

“Dear [company],

I am using your hosting service. I’m interested in using Certbot to use a free certificate from Let’s Encrypt.. Can you send me the support webpage on how to do this? In particular, I’m wondering how I can SSH into your server from my computer? I need to know what software the server is using, and what system the server is on.

Thank you.”

If you know what software and operating system your web server is on and know how to use the command line, Certbot might be a good tool for you.

Check EFF’s Certbot site to generate instructions for getting Let’s Encrypt certificates on Unix servers that you administer. If you don’t see your server’s software and operating system reflected on Certbot, or are unable to get a certificate from following the Certbot instructions for your configurations, proceed to step 4.

4. Troubleshoot until you find an appropriate tutorial to get HTTPS certificates for your site.

This is the messy part: there are many, many tutorials out there for many possible situations. If you’re new to using your command line, we recommend calling a friend with experience in configuring a Let’s Encrypt certificate on their site to help. Be prepared to copy and paste error messages, and spend some time troubleshooting.

Try checking the service https://letsdebug.net/ for an analysis of your setup that can help point out a number of common problems. Try searching the Let’s Encrypt Community Forum for similar questions. If you don’t find the answer from the community’s responses, try submitting your own question to the Let’s Encrypt Community Forum, or calling a friend.

Some other things to look for as you set up HTTPS include:

  • Get the certificate to automatically renew every 90 days. This means you won’t have to go through the pains of configuring a new HTTPS certificate manually, or leaving your site with an expired certificate warning in web browsers if you forget to repeat these steps 3 months from now.
  • Redirect your sites to HTTPS by default, so that it doesn’t default to the HTTP connection.
  • Check with your site host if a wildcard certificate is available for you. This just means that it’ll apply to all your sites that are subdomains of the same domain (if the domain is “example.com”, the subdomains “transactions.example.com” and “email.example.com” will be covered by a “*.example.com” wildcard certificate).

Once you’ve found a tutorial and enabled HTTPS, you’re almost there!

5. Check that HTTPS is working!

Now, visit your site in your own browser and troubleshoot the HTTPS configuration for your site to make sure it’s working. If you have problems, some resources include:

For checking the certificate itself: https://www.ssllabs.com/ssltest/index.html

For checking the reason for security error messages in your browser: https://www.whynopadlock.com/

Google Chrome Now Marks HTTP Sites "Not Secure"

Last week, the movement to encrypt the web achieved another milestone: Google’s Chrome browser made good on its promise to mark all HTTP sites “not secure.” EFF welcomes this move, and we are calling on other browsers to follow suit.

This is the latest in the web’s massive shift from non-secure HTTP to the more secure, encrypted HTTPS protocol. All web servers use one of these two protocols to get web pages from the server to your browser. HTTP has serious problems that make it vulnerable to eavesdropping and content hijacking. HTTPS fixes most of these problems. That’s why EFF and others have been working to encourage websites to offer HTTPS by default.

Users should be able to expect HTTPS by default.

And browsers have been an important part of the equation to push secure browsing forward. Last year, Chrome and Firefox started showing users “Not secure” warnings when HTTP websites asked them to submit password or credit card information. And last October, Chrome expanded the warning to cover all input fields, as well as all pages viewed over HTTP in Incognito mode.

Chrome’s most recent move to show “not secure” warnings on all HTTP pages reflects an important, ongoing shift for user expectations: users should be able to expect HTTPS encryption—and the privacy and integrity it ensures—by default. Looking ahead, Chrome plans to remove the “Secure” indicator next to HTTPS sites, indicating that encrypted HTTPS connections are increasingly the norm (even on sites that don’t accept user input).

For website owners and administrators, these changes come at a time when offering HTTPS is easier and cheaper than ever thanks to certificate authorities like Let’s Encrypt. Certificate Authorities (CAs) issue signed, digital certificates to website owners that help web users and their browsers independently verify the association between a particular HTTPS site and a cryptographic key. Let's Encrypt stands out because it offers these certificates for free and in a manner that facilitates automation. And, with EFF’s Certbot and other Let’s Encrypt client applications, certificates are easier than ever for web masters and website administrators to get.

What Website Owners and Users Can Do

If you’re a website owner or administrator new to getting your own HTTPS certificate, check out these resources for moving your site from “not secure” to secure.

If you're a user, you can take steps to protect your browsing. Download HTTPS Everywhere to make sure your browser uses an encrypted HTTPS connection where ever possible.

Announcing STARTTLS Everywhere: Securing Hop-to-Hop Email Delivery

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 significant wins 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:

https://www.starttls-everywhere.org/

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.

Thanks to multiple efforts over the years, effective STARTTLS encryption is as high as 89% according to Google's Email Transparency Report—a big improvement from 39% just five years ago.

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!

That’s where STARTTLS Everywhere comes in.

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.

Mailserver admins can read more about how STARTTLS Everywhere’s list is designed, how to run it on your mailserver, and how to get your mailserver added to the preload list.

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.

Donate to EFF

With all that we have accomplished together to improve the state of encrypted communications on the Internet, it’s about time we focus on upgrading email, the backbone of communication for a large part of the world. STARTTLS Everywhere is a natural step in that direction, but there’s still plenty of work to do, so let’s get hopping on hop-to-hop encryption!

A Technical Deep Dive into STARTTLS Everywhere

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 significant wins 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.

Thanks to multiple efforts over the years, effective STARTTLS encryption is as high as 89% according to Google's Email Transparency Report—a big improvement from 39% just five years ago.

However, as we explain in our general STARTTLS Everywhere announcement, STARTTLS has some problems.

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.

Donate to EFF

With all that we have accomplished together to improve the state of encrypted communications on the Internet, it’s about time we focus on upgrading email, the backbone of communication for a large part of the world. STARTTLS Everywhere is a natural step in that direction, but there’s still plenty of work to do, so let’s get hopping on hop-to-hop encryption!

Border Spy Tech Shouldn’t Be a Requirement for a Path to Citizenship

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 opposes these programs. 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.

HART: Homeland Security’s Massive New Database Will Include Face Recognition, DNA, and Peoples’ “Non-Obvious Relationships”

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 Biometrics Systems—From IDENT to HART

DHS Growth of BiometricsDHS slide showing growth of its legacy IDENT biometric database

DHS currently collects a lot of data. Its legacy IDENT fingerprint database contains information on 220-million unique individuals and processes 350,000 fingerprint transactions every day. This is an exponential increase from 20 years ago when IDENT only contained information on 1.8-million people. Between IDENT and other DHS-managed databases, the agency manages over 10-billion biographic records and adds 10-15 million more each week.

DHS Data LandscapeDHS slide showing breadth of DHS biometric and biographic 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 HART TimelineDHS 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 Partner AgenciesDHS 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.

Related Cases: FBI's Next Generation Identification Biometrics Database

How To Turn PGP Back On As Safely As Possible

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.

For other popular clients: the answer is hazier. If you use GPGTools and Apple Mail, you should still wait. That system is still vulnerable, as this video from First Look’s Micah Lee shows.

mytubethumb
play
%3Ciframe%20allow%3D%22autoplay%3B%20encrypted-media%22%20allowfullscreen%3D%22%22%20frameborder%3D%220%22%20height%3D%22365%22%20src%3D%22https%3A%2F%2Fwww.youtube.com%2Fembed%2FIMPKe-GJSh0%3Fautoplay%3D1%22%20width%3D%22650...

Privacy info. This embed will serve content from youtube.com

 

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).

Screenshot showing the Thunderbird hamburger menu selected

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

Screenshot showing the "View" option selected

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

Screenshot showing the "Message Body As" then "Plain Text" options selected

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.

Amazon, Stop Powering Government Surveillance

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 arrest protesters 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.

 

Egyptian Blogger and Activist Wael Abbas Detained

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.

 

Páginas

JavaScript license information