💬 Discussion | ProtonMail Cryptographic Architecture #670
Comments
|
Relevant video: End-to-End Encryption in the Browser Impossible? - ProtonMail(YouTube link: https://www.youtube.com/watch?v=DM1tPmxGY7Y) The issue is that PM's backend can be secure, but they can still steal your private key if they send your browser malicious JS. This is the issue with web apps - they are downloaded from the server. It would be cool if PM had a desktop app without auto updates -- users would use a trusted release. The server wouldn't be able to send you malicious JS that way. Though I wonder, can't you self host the ProtonMail frontend? Because you can do that with Tuta. PM's frontend src: https://github.com/ProtonMail/WebClient @beardog108 thoughts? I think it depends on the architecture of the frontend. If it fetches any JS from the server, that's a problem. If it doesn't accept any JS from the server, this attack is not possible. |
@Shifterovich, they offer Protonmail Bridge. |
|
I know about that, I meant if their main platform was a desktop application like Outlook. |
|
tl;dr no such thing as safe end to end website encryption, except in cases of Electron/similar apps, and extensions. ProtonMail is only safe if used in the downloaded apps. This information has been long known, the paper released by Nadim is just an academic summary and criticizes Proton for making questionable claims regarding safety in their advertising/website. This is of course not limited to proton, but any website that uses "end to end" encryption. |
If you want to security, you need to pay. What happened to Open-Source Love? |
Turns out running a free email service costs money. Also, the bridge =/= a desktop email client. It's just a way to receive your emails in, say, Thunderbird. |
|
I got it but i don't think like this: "All Proton products should be free". For example you can't "Send encrypted messages to external recipients". At least Proton should make this to free users. I don't want to much more things. |
Sorry, but this is wrong. ProtonMail 3.14 (released in July 2018) added the ability to import GPG keys of external recipients. Even before 3.14, it was possible to send password-protected e-mails that are accessible in the web browser. Moreover, you can always (recommended for the paranoid) use gpg in your terminal to encrypt your e-mails BEFORE you copy them in your e-mail client. This is also true for decryption and it is supported by any client since they simply take the already encrypted message. |
I own a free Protonmail backup account and I'm able to send GPG-encrypted messages to external e-mail addresses. All other points mentioned above by me also apply. You can always encrypt/decrypt as well as sign/verify your e-mail locally. |
That time Proton should change their chart. You said all other points also apply. Do you have 5GB account? Can you send up to 1000 messages per day? Can you use your own domain? Can you use 5 e-mail aliases? |
|
Anything that promises end-to-end encryption in the browser, without the usage of extensions is prone the private key exfiltration AFAIK. We should recommend on-device email applications, not services. |
Considering that most web browsers automatically update their installed extensions, we wouldn't recommend using extensions for end-to-end encryption, too. That's basically the same problem as server-provided JavaScript. There is one GPG extension called "Mailvelope" that already demonstrated several security issues. The easiest but not-so-user-friendly way is to use raw "gpg" in the terminal to encrypt/decrypt and sign/verify e-mails. Moreover, this is more secure since security vulnerabilities in e-mail clients like Thunderbird don't directly affect GPG. |
|
@infosec-handbook Is the bridge for premium users only? |
Yes, it is a paid feature. |
The use of extensions like Mailvelope would make this not that non-user-friendly for the user |
|
Isn't Mailvelope subject to updates as well? I guess locally loaded mailvelope would work. |
The original issue has actually been addressed by https://github.com/vladimiry/email-securely-app desktop app which goes with prepackaged/built-in web clients for both ProtonMail / Tutanota email providers. Related issues: |
|
Protonmail made a blog post about this too https://protonmail.com/blog/cryptographic-architecture-response/ |
gratis service is not about the money, it's about privacy
Funding a project by charging fees has a privacy downside: it's hard to pay anonymously. Even with cryptocurrency, it can be sufficiently anonymous given a huge effort but that's not realistic. Most exchangers are privacy abusers and even cryptocurrency ATMs often scan IDs. So it's difficult to pay anonymously. Targeted advertising is an even bigger privacy abuse than tracing money IMO. But donations and/or untargeted ads are the more privacy-respecting ways to fund a project. Incidentally that kind of funding is also more inclusive (poor people are not excluded). using an MUA
It's unclear exactly what your issue is @Shifterovich. The bridge facilitates running an MUA of your choice. Both have limitations as I understand it:
I suspect the Protonmail bridge is also needlessly proprietary and redundant. IIRC there is free software middleware that can do the encryption/decryption outside the MUA. Would be better if PM supported that tool and offered imap, pop3, smtp. Protonmail needlessly imposes both motivation and expertise on novices
What @hasanalizxc should have said is that novice users cannot send encrypted messages to external recipients without an unusual degree of motivation. PM added that capability in a manner that requires users to be advanced enough to handle key management. It's a non-starter for a large portion PM's users. Motivation is a big factor. Many novice users could handle the key management if they had a tolerance for learning it. Even when a novice has the benefit of a hand-holding walk-through, they tend to resist. Hushmail already solved this problem decades past. Hushmail has a public key server whereby expert users can do all the key management so the novice users need not know the details beyond their interest. For me it was critical. It was a great benefit to tell my novice correspondents (e.g. accountants and lawyers) "get a gratis hushmail account and i'll take care of the rest". Then I can use my own MUA and key pair and both obtain the pubkey of the other party and push my key to the server, all with no effort on their part. So only one person needs care about privacy and be motivated, not two. It's possible to use e2e crypto this way with unmotivated novices. So now HM charges a premium which has driven users to PM. But PM is a non-starter in many delicate situations where one party to the conversation is repulsed by what they perceive as paranoid Cloak-And-Dagger antics. It's already difficult enough to get novice users to open a HM or PM account, now to ask them to follow steps to send me their pubkey and the follow more steps to accept mine is a show-stopper. Because that hurdle is blocking in many situations, I'm forced into the walled-garden of Protonmail in order to correspond in these fragile-motivation cases. It's not a particularly evil walled-garden but being forced to use another dedicated GUI app or web UI for something as regular as email tests my own motivation.
That introduces a key exchange problem that public key crypto solves. It trades one problem for another. what PTIO should endorse (ElectronMail)
That's true, but it doesn't defeat @kewde's ultimate (neglected) conclusion which is still a good point:
This is aligned with Nadim Kobeissi's stance and it makes perfect sense. Any app where the user is in control of the updates is on the relatively safer side of the mass surveillance likeliness line. They can still be targeted but the PTIO mission is mass surveillance and endorsing javascript that implements crypto is a bad idea. In principle it would make sense to note something like "e2e crypto reasonably safe with their app". But in this case it's a bit disgusting to see that PMs app is exclusively distributed in the privacy-abusing walled-garden of Google Playstore (the abuses of which are outlined in part 2 of this post). I therefore propose something like: "e2e crypto reasonably safe with the unofficial ElectronMail app". Note I've not looked closely at the app but superficially it's likely more secure than the web or playstore app. The fact that it also integrates with tutanota is big convenience gain as well. PM is non-free s/w masquerading as free softwareIt seems Protonmail is using a swindle from the DuckDuckGo playbook: they claim to be "transparent" and "open" by releasing something as free software or open source, but the more important code remains closed-source. This marketing fools the majority. Sure, the openpgpjs is useful for auditors to see the web UI may be safe, assuming the open source version is what the user receives every time they visit the site, but the app (which puts the user in control of updates) is apparently unavailable for review. So users must choose between trusting something that is closed and tied to known privacy abuses, or something that can change at any moment without review. |
It would be best to avoid conspiracy theories while discussing here. |
|
If it is easy to verify the 'fact' that PM is cooperating with the authorities of a country (assuming you meant in a way that undermines security or privacy), then you should be easily able to provide evidence. |
I deleted my messages so you wouldn't be upset. After all, I don't care if people don't want to get to the bottom of the problem and want to explain all the conspiracy theories. |
Key expiration mistreated by ProtonmailI should mention that there is a key expiration policy at Protonmail that is detrimental to security. It's not a major problem but I'll mention it here for the record. When a key expires Protonmail outright blocks users from using it without question or override. This policy demonstrates that the designers of Protonmail do not thoroughly grasp the purpose of key expiry. When a key is compromised or lost, key holders are responsible for updating their key immediately and revoking the original key (when possible), regardless of expiry. At that point the expiration serves to limit the duration of the compromise, as some correspondents will continue to use the bad key because they won't know until expiry to get a replacement key. In the absence of a lost or compromised key (i.e. the key is usable), keys often expire without the key holder noticing. These keys are still perfectly valid and fit for purpose to the extent that the key size and algorithm are still suitable for the payload. Senders have a duty to verify whether there is a better replacement key available. But when the answer is /no/, then the key they hold is still the best and most recent key. Protonmail's policy is to block the use of the best key available in that circumstance, which needlessly compels Protonmail users to send messages in the clear. It's brain dead policy. What PM should be doingWhen a user attempts to use an expired key, PM should intervene with warning dialog instructing users to verify whether a replacement key is available. If yes, PM should import the key. If no, PM should use the expired key for that message and every msg thereafter until the key isn't expired. |
|
If you ask me, what proton mail does is still end to end encryption. |
Using Tor doesn't really help with this, they can still see that its you/your account logged in. |
|
Even then, as stated above e2ee with larger attack surface is still e2ee. |
Recently, a paper was published regarding "the first independent analysis of ProtonMail's cryptographic architecture". The author's finding acknowledges certain problems that may break end-to-end encryption.
Link to the paper
Protonmail's response can also be found here.
The text was updated successfully, but these errors were encountered: