This! I didn't even have thr chance to read the full article. I am never solving a google captcha again on my non-work devices. It's a lost cause, I can't pass.
"Aside from this, I also write daily at neo-network, which is a Telegram content channel I created to spread awareness of issues on technology, privacy and security. More importantly, it shares new revolutionary technologies, and educates readers on using them to break out of the web of control, creating a neo-network in its place."
Well the author of this has a Telegram content channel.
Anything in this article that applies to ProtonMail applies to any encrypted web based email service. There's a limit in how much you can trust ProtonMail.
If there's a website where you login and you see your email, there's always a way for that website to get access to the content of their own website.
>...if you’ve used the Webmail client, ProtonMail has always had the ability to grab your password and private encryption key without you knowing, giving them backdated access to your emails.
If the keys are stored on the same server as your encrypted data, your data might as well be unencrypted.
> If PM decides to act maliciously, they can do so undetected. Unlike the mobile application who’s binaries get cryptographically signed to match the official codebase, there is no method to verify a web application.
Because everyone uses reproducible builds and verifies them for every automatic app update, right?
> Although they do use the same client side OpenPGP library maintained by ProtonMail (its likely the only one in the world that works in browsers), they have accounted for the concern and developed a system that allows you to compare the code in your browser with the code that they’ve published
Their implementation for the checksum is actually cool, I like it.
However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe.
If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway.
Having user auditable source code and verifiable builds is pretty much the gold standard approach. Yes, the vast majority won't check the checksum and even less well check the source, but it only takes one critical person to get the ball rolling upon compromise.
Of course not, but it is possible to do so. It can also be verified by trusted third parties, etc.
> However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway.
This is a non-sequitur. If you're starting to talk about average Joes with an unspecified threat model, surely GMail will be fine too, for some very low bar of "crooks can't hack my facebook". But there's obviously a big span inbetween that and "specifically targeted by intelligence agencies".
More to the point, no matter your threat model, you should try not to do business with scammers. Firstly, out of moral imperative, and secondly, because your threat model might change.
> Their implementation for the checksum is actually cool, I like it.
For those interested, I think the checksum trick referred to above (in the context of the service offered by CTemplar) is described at [0] and there is a step-by-step how-to guide at [1].
Basically the top level index.html contains integrity hashes for the JavaScript it fetches, and you're expected to copy-paste the source of the page you're viewing into an editor, save the file, and run a local checksum on it.
That is clever, but it seems like a more convenient design would be to use a "bootstrap" page which only has the minimal set of tags on it needed to run a single <script src=bootstrap.js integrity=sha384-whatever>. Then the user can do a quick visual inspection that there's nothing suspicious in the DOM and confirm that the integrity hash matches the value in an append-only log somewhere.
Mozilla actually had a clever idea for building binary transparency using the existing certificate transparency infrastructure for domains[2], by registering something like $version_number-$hash as a sub-domain of the domain where the app is hosted, e.g. v14-abc123.ctemplar.com which the user could search for using one or more certificate transparency logs.
Anyway, this manual checking process can be avoided entirely if the site is made available as a SecureBookmark[3], although that has the disadvantage that the browser would show a Data URI as the page address rather than a standard URL/domain which users are more familiar and comfortable with.
"And the flaw is that it is relatively simple for ProtonMail to serve you a modified version of their web application or the underlying PGP implementation. There is no way to cryptographically verify that you are getting the official version of the web client as stored in their repository.
If PM decides to act maliciously, they can do so undetected. Unlike the mobile application who’s binaries get cryptographically signed to match the official codebase, there is no method to verify a web application."
If the web client is open-source (as at seems), can't anyone build it locally and compare the built files to what they were served?
"If the web client is open-source (as at seems), can't anyone build it locally and compare the built files to what they were served?"
Yes, but the results of such an inspection would only apply to that particular web request at that particular time.
At another time, or to some other person, a different app could be served up by ProtonMail if they so chose.
That's not to mention that the vast majority of ProtonMail users probably don't (and wouldn't have the skills to) evaluate the code they receive from ProtonMail, so even if they were being served up something suspicious, they'd never know.
Something like a browser extension could make that kind of check repeatable, automatic, and unobtrusive unless there's a discrepancy. Assuming builds don't happen too too often.
Yes, either you'd have to verify the build yourself or trust someone else to do it and independently publish something for the extension to compare to the client it's served.
The title is super clickbaity, emails are likely compromised?? Uh no. Every single closed source client for end to end encrypted messaging has this problem.
What happens if whatsapp decides to exfiltrate your end to end encrypted messages from the client side app?? There is nothing you can do to stop them. They can even attach it to an analytics event to be discrete.
Protonmail is unable to view your emails without your password and that claim is true regardless of whether they hold your encrypted private key server side.
Not sure what to make of the source, a random writer on a new age hippy website?
Seems that the primary claim is that ProtonMail is potentially compromised by Intelligence agencies and can nefariously show users fake pages to steal credentials and decrypt messages?
Overall the article seems light on evidence.
Edit: Found a response from ProtonMail to the Researcher quoted in OP's article.
I don't think the headline matches the post. Usually when we refer to systems being "insecure" and "compromised", we mean so with respect to a third party.
A better headline might be: ProtonMail supports full E2EE, provided you trust them with your keys (if not, why are you paying for their service?).
If you trust them with your keys, why not trust them with your plaintext? At which point, why bother with E2EE at all?
The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".
What that looks like in practice is probably some mixture of the following projects:
> In addition to this, ProtonMail has no password requirements, and the Professor has tested it with passwords like ‘1’, ‘iloveyou’, and ‘password’, which are all trivial to crack in dictionary attacks. Once these can be confirmed, an attacker has your entire email history.
Surely, they could enforce password requirements, but for me every user is responsible of having a secure password. If your account gets compromised despite the service hashing password correctly and having brute-force prevention mechanisms in place, it's on you for not having a strong enough password (or reusing it).
> And the flaw is that it is relatively simple for ProtonMail to serve you a modified version of their web application or the underlying PGP implementation. There is no way to cryptographically verify that you are getting the official version of the web client as stored in their repository.
Yes, this is true. But for anyone requiring absolute state-of-the-art privacy, you could simply use your own pair of keys without ever sending it to ProtonMail (i.e. you would use ProtonMail to send and not to encrypt, even though you would still benefit from their encryption as an additional layer). All open-source web-based services have this kind of flaw.
> PM can once again replace the web application or PGP software to recover the original message and passcode.
(This is in reference to the "Encrypt-To-Outside feature".) Yes, this is true as well, but look at the alternative: I send an email to your Gmail account. Google can read it. Then, you reply to my email, and ProtonMail could catch it in transit while it's not encrypted. I mean, they don't need you to use that feature to be able to catch your communications. So, we're back to the fact that they could serve a different version of the source code than they advertise.
I really fail to see the point of this article. I'm sure most of the users use it to stay away from Google tracking, and even the author agrees that if you need total privacy you should use your own keys.
I use ProtonMail because I want to use an email address at my own domain. It's actually an inconvenience though, because their IOS app does not let me compose a message with VoiceOver, and when I reached out to them, they basically told me that they're not implementing features until they do their UI redesign. Most of the time, I compose messages in a desktop browser, but the few times I've needed to do so from my phone has required me to open Safari and do it from there, which was a pain.
I'm not looking for military grade encryption in a subterrainian mountain; I just want email at my domain from a service that doesn't read all of my emails and profile me based on their contents. I've looked into hosting my own email from a VPS, but it's not a trivial project, and I'm most worried about being blacklisted before I even start, since it seems most VPS providers are.
Might want to try Tutanota or Fastmail. I've heard good things about them but never tried either.
I'm currently on protonmail and I am also getting frustrated by their glacial rate of change for reported bugs and quality of life improvements. Also their calendar is one of the worst calendars I have ever used so need to use another service for that anyway.
The article appears to be an obvious attack on ProtonMail.
It’s clear that private keys are held client-side-encrypted on servers. You need that to read your emails in new devices. It’s standard and doesn’t lower security.
It’s also obvious that any website could serve you with bad Java script code.
40 comments
[ 0.19 ms ] story [ 135 ms ] threadWell the author of this has a Telegram content channel.
If there's a website where you login and you see your email, there's always a way for that website to get access to the content of their own website.
Try running Thunderbird or a similar client locally, and use PGP (ugh) or something similar to encrypt messages.
(Theoretically, you can also use PGP with webmail, and it's secure, but extremely unpleasant.)
>...if you’ve used the Webmail client, ProtonMail has always had the ability to grab your password and private encryption key without you knowing, giving them backdated access to your emails.
If the keys are stored on the same server as your encrypted data, your data might as well be unencrypted.
Because everyone uses reproducible builds and verifies them for every automatic app update, right?
> Although they do use the same client side OpenPGP library maintained by ProtonMail (its likely the only one in the world that works in browsers), they have accounted for the concern and developed a system that allows you to compare the code in your browser with the code that they’ve published Their implementation for the checksum is actually cool, I like it.
However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway.
The difference between convenient and inconvenient doesn't really matter at all.
Visibility is the difference between possible and not-possible.
That is all the difference in the world, and matters no matter how few people ever actually do something.
Of course not, but it is possible to do so. It can also be verified by trusted third parties, etc.
> However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway.
This is a non-sequitur. If you're starting to talk about average Joes with an unspecified threat model, surely GMail will be fine too, for some very low bar of "crooks can't hack my facebook". But there's obviously a big span inbetween that and "specifically targeted by intelligence agencies".
More to the point, no matter your threat model, you should try not to do business with scammers. Firstly, out of moral imperative, and secondly, because your threat model might change.
For those interested, I think the checksum trick referred to above (in the context of the service offered by CTemplar) is described at [0] and there is a step-by-step how-to guide at [1].
Basically the top level index.html contains integrity hashes for the JavaScript it fetches, and you're expected to copy-paste the source of the page you're viewing into an editor, save the file, and run a local checksum on it.
That is clever, but it seems like a more convenient design would be to use a "bootstrap" page which only has the minimal set of tags on it needed to run a single <script src=bootstrap.js integrity=sha384-whatever>. Then the user can do a quick visual inspection that there's nothing suspicious in the DOM and confirm that the integrity hash matches the value in an append-only log somewhere.
Mozilla actually had a clever idea for building binary transparency using the existing certificate transparency infrastructure for domains[2], by registering something like $version_number-$hash as a sub-domain of the domain where the app is hosted, e.g. v14-abc123.ctemplar.com which the user could search for using one or more certificate transparency logs.
Anyway, this manual checking process can be avoided entirely if the site is made available as a SecureBookmark[3], although that has the disadvantage that the browser would show a Data URI as the page address rather than a standard URL/domain which users are more familiar and comfortable with.
[0] https://ctemplar.com/ctemplar-checksum-implementation/
[1] https://github.com/CTemplar/webclient/tree/gh-pages
[2] https://wiki.mozilla.org/Security/Binary_Transparency
[3] https://coins.github.io/secure-bookmark/
Yes, but the results of such an inspection would only apply to that particular web request at that particular time.
At another time, or to some other person, a different app could be served up by ProtonMail if they so chose.
That's not to mention that the vast majority of ProtonMail users probably don't (and wouldn't have the skills to) evaluate the code they receive from ProtonMail, so even if they were being served up something suspicious, they'd never know.
Yes, either you'd have to verify the build yourself or trust someone else to do it and independently publish something for the extension to compare to the client it's served.
https://github.com/tasn/webext-signed-pages
What happens if whatsapp decides to exfiltrate your end to end encrypted messages from the client side app?? There is nothing you can do to stop them. They can even attach it to an analytics event to be discrete.
Protonmail is unable to view your emails without your password and that claim is true regardless of whether they hold your encrypted private key server side.
Total garbage
Seems that the primary claim is that ProtonMail is potentially compromised by Intelligence agencies and can nefariously show users fake pages to steal credentials and decrypt messages?
Overall the article seems light on evidence.
Edit: Found a response from ProtonMail to the Researcher quoted in OP's article.
https://protonmail.com/blog/cryptographic-architecture-respo...
A better headline might be: ProtonMail supports full E2EE, provided you trust them with your keys (if not, why are you paying for their service?).
The answer should be "because one day web browsers will be able to pin specific versions of specific web apps, with specific hashes, corresponding to specific releases tagged in their repo, which have been audited by a certain threshold of auditors that I trust".
What that looks like in practice is probably some mixture of the following projects:
https://github.com/kpcyrd/pacman-bintrans
https://users.rust-lang.org/t/rust-code-reviews-web-site-for...
https://paragonie.com/blog/2022/01/solving-open-source-suppl...
Surely, they could enforce password requirements, but for me every user is responsible of having a secure password. If your account gets compromised despite the service hashing password correctly and having brute-force prevention mechanisms in place, it's on you for not having a strong enough password (or reusing it).
> And the flaw is that it is relatively simple for ProtonMail to serve you a modified version of their web application or the underlying PGP implementation. There is no way to cryptographically verify that you are getting the official version of the web client as stored in their repository.
Yes, this is true. But for anyone requiring absolute state-of-the-art privacy, you could simply use your own pair of keys without ever sending it to ProtonMail (i.e. you would use ProtonMail to send and not to encrypt, even though you would still benefit from their encryption as an additional layer). All open-source web-based services have this kind of flaw.
> PM can once again replace the web application or PGP software to recover the original message and passcode.
(This is in reference to the "Encrypt-To-Outside feature".) Yes, this is true as well, but look at the alternative: I send an email to your Gmail account. Google can read it. Then, you reply to my email, and ProtonMail could catch it in transit while it's not encrypted. I mean, they don't need you to use that feature to be able to catch your communications. So, we're back to the fact that they could serve a different version of the source code than they advertise.
I really fail to see the point of this article. I'm sure most of the users use it to stay away from Google tracking, and even the author agrees that if you need total privacy you should use your own keys.
How else are you going to do it ?
Balance between security and usability, as usual. If you want more, use pgp, but loose most users.
I mean, yes, that's true, but it's still a bad idea.
> Balance between security and usability, as usual. If you want more, use pgp, but loose most users.
They could just have a local client. Thunderbird/Outlook/whatever isn't exactly difficult to use, even for non-technical people.
They do. This is what ProtonMail Bridge is.
I'm not looking for military grade encryption in a subterrainian mountain; I just want email at my domain from a service that doesn't read all of my emails and profile me based on their contents. I've looked into hosting my own email from a VPS, but it's not a trivial project, and I'm most worried about being blacklisted before I even start, since it seems most VPS providers are.
Any recommendations?
It’s clear that private keys are held client-side-encrypted on servers. You need that to read your emails in new devices. It’s standard and doesn’t lower security.
It’s also obvious that any website could serve you with bad Java script code.
Waste of time.