Hacker News new | past | comments | ask | show | jobs | submit login
An Analysis of the ProtonMail Cryptographic Architecture [pdf] (iacr.org)
61 points by phoe-krk 4 months ago | hide | past | web | favorite | 26 comments



I've quickly skimmed through the paper and the ProtonMail whitepaper the author supposedly based their analysis on. Sorry to be harsh, but the conclusions of the analysis are pretty much BS. The reason is that the threat model defined by the author is obviously not the one ProtonMail defends against.

The author makes-up a straw-man threat model which is not based on anything that ProtonMail has published:

> A crucial security assumption, based on ProtonMail's self-professed security goals in its specification documents (Ÿ2.1), is that the ProtonMail server P is untrusted.

AFAIK, ProtonMail only claims that your email are unencryptable while you don't access the service. Since they have to receive and relay emails to regular SMTP servers and they provide access via IMAP to regular mail programs, obviously their servers at some point will touch your unencrypted email. Therefore, you put a certain amount of trust on them.

So, yes, under the defined straw-man threat model, ProtonMail is not secure. Thank you Captain Obvious!


Unless you count the promises on their front page. "All emails are secured automatically with end-to-end encryption. This means even we cannot decrypt and read your emails. As a result, your encrypted emails cannot be shared with third parties."

Obviously that's not possible when receiving mail via SMTP and providing access via IMAP. But that's not clear to non-technical users. I think it's fair to say that putting the above quote on the landing page is misleading.

EDIT: I was wrong on IMAP, which requires users to install a bridge application that handles decryption. That doesn't change anything about SMTP, though.


> Obviously that's not possible when receiving mail via SMTP and providing access via IMAP.

Afaik on desktop all those involve the use of the ProtonMail Bridge application [0]? At least that was my understanding when I couldn't get my Thunderbird setup to check ProtonMail accounts, it requires the Bridge application.

The paper is weird in that context because the Bridge application is mentioned only once in the whole paper, as a side note: "For simplicity, we group it with smartphone applications."

But from what I understand their whole Outlook client setup wouldn't even work without it, so desktop clients are just as secure as the smartphone applications when they use the Bridge?

[0] https://protonmail.com/support/knowledge-base/imap-smtp-and-...


Oh, looks like you're right on IMAP. But they still receive mail via SMTP from other servers, there's no way around it if you want to be able to receive email from people not using your service. You need to be confident that their receiving servers encrypt your email without storing an unencrypted copy elsewhere.


Yes, for not technical users this can be misleading. Protonmail could have been more up-front.


"ProtonMail only claims that your email are unencryptable while you don't access the service."

Why would they be unencryptable when ProtonMail controls the javascript that "encrypts" the message in the first place?

The main point of Kobeissi's analysis is that ProtonMail could, at their whim, serve whatever javascript they want to the client, including javascript that compromises the encryption or hands over the keys to ProtonMail. If they do this, then it's pretty obvious that the message on ProtonMail's servers would be decryptable by them, no?


There are good general observations on e2e claims for any web app (5.1 and part of conclusions section), which apply to almost any web app, aside from design flaws in the protonmail itself.


I think it's worth comparing to the deployment to the phone apps and the threat model there. AFAIK the phone apps are not open source, so what if I don't trust the developers? OK, let's assume I trust the developers, but their build server gets compromised (probably much less attack surface then their web interface, but still)?

But if it were open-source, available on F-droid and reproducibly buildable then it could be potentially more secure than a web application. But even then the users either have to audit the source themselves (unlikely), or trust the developers, or trust one or more 3rd party auditors and make sure they run the same code as audited.

For a web application auditing the client code every time you log in is impractical and you can never be sure you run the same code as a third party auditor.


In fact, due to browser execution model, it’s not impractical - it’s impossible - it can mutate any moment.


These "design flaws" are more like design choices, which this paper misrepresents as flaws.

For example, the password brute force argument. That's actually a part of the paper that does not make sense to us. ZKPP provides guarantees related to the handshake between the client and server. It does not mean and never has meant that the server itself could not mount a brute-force attack on the user password. That would be possible from the server with any PAKE, including SRP, which we use. Having the key encrypted with a derivative of the password does not change this, because it was possible already. Slow password hashes throughout make this difficult of course.

He also attacks the encrypt outside feature, but a malicious third party email provider was never part of the threat model for this feature.

Finally, he attacks the fact that we allow weak passwords. Well, not enforcing strong passwords is a design choice, and not a crypto weakness. You can disagree with this choice, but it's going too far to try to dress it up as a crypto flaw.


I do get your arguments very well: having to advocate ZKPP primitive in our own solution I end in discussions about ‘ZKPP does not prevent brute force’ a lot. But it’s unfair to rule out the analysis because this is a choice - these are weaknesses, they are making the system weaker. The fact that you’re providing ibcremental security in many spheres of your influence does not mean that, when being questioned, they are atill weak against practical risks. ‘Secure against chosen threat model’ is OK when threat model reflects reality, paper’s author, I think, is coming not from basis of your threat models, but from basis of security challenges of modern e-mail.

Quite frequently the difference between what you want to protect against vs real threat landscape is what rules the expert community’s decision.

I feel your pain (I work at company which improves data security of distributed systems in a number of ways, and get into similar disputes all the time), but the fact that you’re mitigating some of the risks really well does not mean that other security properties will not be scrutinized against commonly recognized threat models.

Not too rewarding, yet the whole security engineering is a Sysiphus’ labor fron day 0. Not having enough of in-community pressure (even when sometimes you’re criticized for a wrong cause, which is 50/50 here) would lead to much worse consequences than a few uncomfortable questions asked.



This response does not directly address Kobeissi's points.

It rephrases and generalizes his points rather than tackling them head-on.

Kobeissi's main point is that ProtonMail could serve up any javascript they want to the client, including javascript that compromises the encryption or which hands over the encryption keys to ProtonMail.

Nowhere in ProtonMail's response is this point ever directly addressed or even acknowledged.


Not only do they not address the technical aspects of the paper, their response starts with a direct personal attack:

"It seems Nadim (the author of this paper) took it really badly when we called him out for intentionally spreading fake news this weekend." [1]

That's really low. The beautiful thing about computers is that we can prove each others right or wrong with technical arguments. If ProtonMail thinks Nadim has a personal grudge against them, wouldn't it be beautiful for them to disprove him with another professionally written paper as Nadim did? They can't.

Also, I think Nadim knows more than anyone the dangers of pushing weak products and marketing them as secure. It happened to him with Cryptocat. It's a thing that can harm reputation and also harm users, Nadim went through that and I believe he has good intentions by presenting this paper.

---

[1] https://www.reddit.com/r/ProtonMail/comments/9yqxkh/an_analy...


This point has been acknowledged since day one though, and it is not a point specific to ProtonMail. Any E2EE service that has a webapp is susceptible to this, and that's essentially all E2EE services out there.

The only way to address this point, with current technology and current standards, is to discontinue the webapp and force everybody to the native apps on desktop and mobile. It is the opinion of almost everybody in the industry that webapps are necessary, and that's why we, WhatsApp, etc, all provide webapps.

So the point is acknowledged (and has always been acknowledged), but the opinion being expressed (remove the webapp) is not something that we agree with.


If you acknowledge that you can serve up javascript which either compromises the encryption or gets the user's keys, then how can you claim that "we cannot decrypt and read your emails"?

It sounds like you just admitted you could.


>The only way to address this point, with current technology and current standards, is to discontinue the webapp and force everybody to the native apps on desktop and mobile

Browser extensions.


> Any E2EE service that has a webapp is susceptible to this

But I don't think everybody are making webapps to service data of their E2EE product, isn't it?

The key point is, if the webapp can be compromised by anybody who are in control of the front-end assets, then what's the point of the entire ProtonMail E2EE thing? Especially when you have other solutions like GPG which also is an open protocol?


ProtonMail is based on GPG actually, and we also have native desktop and mobile apps. The webapp is just one platform that we support, out of many. E2EE services providing webapps is actually not uncommon, e.g. WhatsApp, Wire, etc.


Is it possible to have a noscript version of the webapp?


This is such a valid and even-keeled compromise. I'm sure you'll get absolutely no traction lol


Hi,

I am new to these things.

(This is a little off topic but I figured I'd ask.) I took a look at my key (you can see it on my profile) and noticed it is 2048. Is there a reason to go with 2048 as opposed to 4096?

Sincerely,


The End-to-End-Encrypted Web is a myth!


End-to-End-* is typically just a buzzword. Interpretation is different, depending on who you ask and what is the subject.

Regarding end-to-end encryption, back in 1984, Saltzer et al. [1] argued that "functions placed at low levels of a system may be redundant or of little value". So, proper email encryption is best achieved at the client application level. If we had got that right, ProtonMail would probably be irrelevant.

[1] https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...


Probably not a myth, just not happy-clicky (low-friction).

I have found the bar to entry is "how many clicks or steps" is the receiver willing to perform. Even the least technical of my friends can decrypt a PGP or 7-zip file I send them, but I have to put something they really want inside it.


The analysis by Kobeissi is correct, and the claims by ProtonMail are a stretch, and sometimes they don't mean anything.

For example, from their security details page [1]:

"This means we don't have the technical ability to decrypt your messages, and as a result, we are unable to hand your data over to third parties."

This is not true for the web client, as shown by the paper and because of the inherent nature of web applications and the (incomplete) verification mechanisms we have today.

In the same page, they claim:

"As ProtonMail is outside of US and EU jurisdiction, only a court order from the Cantonal Court of Geneva or the Swiss Federal Supreme Court can compel us to release the extremely limited user information we have."

I'm not a lawyer and I don't care about the details. But they are saying that there is a way for a court to get their information. If that court cannot be used as a proxy for the US or other country I don't know, and normal users can't easily verify that claim. Only a lawyer could. But I admit, it sounds great!

The hardware security section is complete nonsense:

"Our primary datacenter is located under 1000 meters of granite rock in a heavily guarded bunker which can survive a nuclear attack. This provides an extra layer of protection by ensuring your encrypted emails are not easily accessible to any third parties. On a system level, our servers utilize fully encrypted hard disks with multiple password layers so data security is preserved even if our hardware is seized."

The nuclear bunker thing is really awesome, sounds like a lot of fun. But how does this offer extra guarantees to privacy? Does it have any windows? how secure are the doors? Also, the "multiple password layers" is nonsense, what does that even mean? Are you encrypting the same thing multiple times?

The main problem with ProtonMail and services similar to it is that they keep the concept of e-mail as we know it alive, when it should be disappearing.

ProtonMail's native mobile apps can be somewhat secure yes, but at that point, conceptually, they are the same as any other secure messaging app. But instead they are using an inferior protocol than the one being used by Signal, Wire or WhatsApp.

The claim that WhatsApp and Wire both have webapps I think is valid, every messaging service should do a better work warning users about the dangers of desktop/web-based applications. But if this is their only defense, then I think they should really need to worry about their own service and stop diverting attention.

---

[1] https://protonmail.com/security-details




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: