End-to-End Encryption in the Browser Impossible? – ProtonMail

End-to-End Encryption in the Browser Impossible? – ProtonMail

Nadim Kobeissi has written a paper called
“An Analysis of the ProtonMail Cryptographic Architecture” where he says that “no end-to-end
encryption guarantees have ever been provided by the ProtonMail service”. This is quite a big and serious claim. End-To-End encryption is the first feature
they list in their security details, along Zero Access to User data, which 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. With ProtonMail, privacy isn’t just a promise,
it is mathematically ensured”. Protonmail has been around for quite some
time now, if something so fundamentally seems wrong, it must be some kind of crazy complicated
crypto attack, right? But if you read the paper, you will realise
it’s something fairly basic. So in this video I want to explore one specific
thing from this paper. This whole topic has caused quite some controversy
and before we head into this I think it’s just fair to disclose that I have worked,
with nadim, many times professionally. So you can accuse me of bias, but I don’t
think that this actually affects the content of this video. It was merely the reason why I paid attention
to this paper in the first place. But let’s not waste more time, let’s head
into the paper. Nadim first introduces some entities. We need to know about a ProtonMail user A
and a ProtonMail user B. We also consider a ProtonMail webmail server
P. So we have two protonmail users A and B, and
they want to send an email to each other by using protonmail webmail sever P. Because
Protonmail offers End-to-end encryption this email will actually be encrypted with PGP. And there is nothing wrong with PGP. The only challenge with PGP here is the secure
exchange of the public key. But we just assume keys were exchanged securely,
for example A and B met in person before. So if user A encrypts the mail with the public
key from user B, and uses Protonmail to transfer the mail to B, there is no security issue. End-to-end encryption is working fine. But then how can nadim claim that “no end-to-end
encryption guarantees have ever been provided by the ProtonMail service”. It looks all perfectly fine, right? Well, the devil is in the real-world implementation
details. You see this graph that describes the email
exchange assumes that User A and User B just have trusted implementations of PGP. The code that will do the encryption for them. However in the web, just as matter of fact
how the web works, the program, the code that implements the encryption, the webapp you
use, protonmail, is also delivered by the protonmail server P.
And this can be seen here in Figure 2.a. Before user A can PGP encrypt the email message
m, for the public key from user B, it has to receive the code to do that in the browser. This is indicated here by J. J refers to the
Javascript implementation of PGP that is served by Protonmail. And, we are done, that’s for me the important
part of the paper, so the conclusion is simple. When Protonmail says:
“[…] we don’t have the technical ability to decrypt your messages”. It’s kinda wrong, right? Technically they can just deliver a malicious
javascript J-evil, that will just steal your plaintext message before encryption, or just
straight up steal your private key… The technical ability is absolutely there. And so the claim that this “end-to-end encryption”
is not just a promise but “mathematically ensured”. seems objectively, false. No? So let’s have a look what Protonmail has
to say about that. The key question being debated is whether
or not web applications can constitute end to end encryption. Nadim’s opinion is that, as he writes, “no
webmail-style application could”. His viewpoint is that E2EE is not possible
with web clients, period, end of discussion. This is a rather extreme position to take
as it would also apply to the web versions of Whatsapp or Wire, for instance. Like Whatsapp and Wire, we also offer a web
app. The major opinion Nadim is expressing here
is that […], you can’t do end-to-end encryption in a webapp. Obviously Whatspp and Wire do not share this
opinion. Signal coincidentally does share this opinion. We do understand Nadim’s arguments, and agree
that web-apps are less secure than say a native iOS app. Okay… so they do somewhat agree, however
they think it’s not that significant. They use the fact that Whatsapp and Wire also
offer webapps, as an argument for their side – but of course these are also other commercial
applications, that like protonmail have a user demand and an economic incentive, to
offer web-app versions. But for a moment, let’s go back to this
figure. We say we have here a problem because Protonmail
Server P provides the javascript code, for the browser and could thus provide malicious
code as well. But then how is this different from a mobile
app. Protonmail also provides the mobile app and
the automatic updates for it. So protonmail could also just deliver an evil
app-update that steals the cleartext emails. And you can now actually continue with this
rabbithole. Apple offers iOS updates, which means they
push the code you run on your phone – they could create an operating-system update that
specifically extracts the decrypted emails from the protonmail app and sends it away. And wait, you run this all on hardware that
you bought from somewhere and the CPU could just once in a while jump to some secret malicious
code that could take the decrypted messages out of the memory and steal it. You see you can extend these circles quite
far. However at some point it gets silly. While technically your hardware could be backdoored,
that’s very unlikely. Like the recent bullshit bloomberg story. And yes, technically apple could push a malicious
operating system update, but that is also super unrealistic… But what about “protonmail creating a malicious
mobile-app update”? Here we start to get into a bit more realistic
realms. build servers or webservers that offer the
final softwares for download have been comproised before and replaced with a trojanized version. This is something we could be concerned about. However we also know these compromised versions
are caught fairly quickly, because this attack has quite some hurdles. And Nadim shares an example about the delivery
process of android apps. Simply speaking, in case of a mobile-app,
it’s not as simple as saying that Protonmail server P delivers it, there are developers,
signing keys, app-stores, and everybody gets the same new version. So overall this is very unlikely. So this leads us to typical web applications,
which are delivered from the server everytime when you access protonmail. We know for a fact that a lot of websites
get compromised and for example a cryptocurrency coinhive miners get included in the javascript. So we can already see that this is a more
realistic threat. And the big danger here is also, that you
could carefully control which user gets delivered which version. You could only target a specific IP, a region,
a user. And only deliver a malicious javascript J-evil
once. And after that, all future requests are safe
again. You see that is VERY different from a malicious
mobile app. And so protonmail questions if the line that
nadim draws here reasonable. Can we, for the current state of our technology
say, that webapps cannot implement End-To-End encryption because the code is also always
delivered with HTTP requests? Well, PotonMail’s argument against the paper
is saying, that this is just an opinion – saying that nadim draws the line here arbitrarily. Nadim’s opinion is that, as he writes, “no
webmail-style application could”. But this is a bit unfair. This quote is not the root of nadim’s argument
– it is quite an extreme positon to take. But he takes this position as a result of
his argument, this is nadim’s conclusion. And while I agree with conclusion, let’s
not get distracted by this. Conclusions are more likely subjective and
thus Protonmail uses it to discredit him. But nadim wrote a paper specifically about
Protonmail and we have to look at his actual arguments regarding protonmail. And more specifically the claims that protonmail
makes, and nadim uses to construct his argument. So Protonmail attacks nadim’s general conclusion
but seems to ignore, and sidestep, the claims that lead nadim there. But I know why, because ProtonMail is in a
predicament. They themselves acknowledge nadim’s threat
in their business paper “ProtonMail Security Features and Infrastructure”, they write: ProtonMail conservatively assumes that all
mail servers may eventually be compromised. And even further into the paper where they
talk about how they want to protect passwords (different story) they again refer to this
threat. “If the server is compromised, whether from
malicious code injected onto the server or due to a [blah blah unimportant]” you can see Protonmail themselves claim that
the Protonmail Server P is untrustworthy. And based on this claim nadim succesfully
makes the argument, well if Protonmail can be compromised (which they say shouldn’t
be a problem), the javascript code delivered is also compromised. Protonmail does not make such claims about
the mobile app. They don’t advertise a security model where
a compromised build queue including developer signing keys is not a problem. But they do say a compromised server P is
supposed to be safe. So as it stands, ProtonMail does not meet
its self-professed security goals. Which means, ProtonMail must overhaul its
existing specifications, documentation and product presentation materials. To reflect this matter of fact. So It doesn’t mean that Protonmail is less
secure than alternatives, it simply means Protonmail’s very high security-goals and
public marketing claims, specifically about a compromised server, have been refuted. Nothing more. Nothing less. And of course if for YOU personally a compromised
protonmail server is not in your threat model, because you trust them, then you are also
fine. So I hope that Protonmail can properly address
these very specific claims and admit that in this case their claims fall a bit short. It doesn’t have to be such a big deal. But I personally would like to move away from
Protonmail now and rather generally ask, what conclusion do you draw from this. Do you agree with nadim’s radical(?) or
reasonable(?) view that end-to-end encryption is simply not possible in this strong mathematical
sense as a web app?

100 thoughts to “End-to-End Encryption in the Browser Impossible? – ProtonMail”

  1. Wait, didn’t ProtonMail specifically claim protection if their mail servers are compromised? Surely their “mail servers” are separate from whatever CDN delivers the JavaScript code.

    I suppose it is splitting hairs, but assuming those are distinct entities, I don’t think they are falsely advertising anything

  2. I watched now till minute 5 and i totally agree with you. As a Protonmail user i asked myself the same questions and came to the same conclusion.

    A practical solution to solve this issue would be to opensource the pgp.js and make a fingerprint of the code for easy check. So the users "only" have to check the fingerprint of the code snippet and the right implementation. What i mean by this is simple: Just a simple proof that the program does what it does(open source) and the ability to check if my message was decrypted by the program immediately.

    Sounds ok?

  3. I think this comes back to the idea that data is as secure as clients and servers no matter the encryption if someone can intercept traffic on any end it's over.

  4. It´s possible for as long as you want that you can make it possible, all comes down to how the concept is implemented and what is the limiting factors which means theoretically yes you can, just do it right.

  5. I do agree with Nadim that the JS delivered to the web client may be insecure. However, I think he's stepping a little into that rabbit hole you mentioned. I think the thing that makes ProtonMail attractive to security conscious individuals is their location, and their small, but appreciated, amounts of transparency.

    The web client is open source (https://github.com/ProtonMail/WebClient), which is a small mercy, but the mobile apps aren't. The backend isn't either.

  6. And obviously, we can't trust software unless we wrote that. https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf

  7. It's actually possible to use HTML5 web workers to secure code delivery and required key signing, much like app store deliveries. Then you're only compromised on the first "install" of the web app.

    Also, it's far easier to get the user to install an extension that steals her data than it is to compromise the servers. Why are we assuming browsers are secure?

  8. If the decryption script was sourced from an untamperable source, for example a blockchain ledger, could this solve the problem and thus make E2EE on a web application possible?

    Although I suppose this would also rely on trusting the webapp code to direct you to the legitimate decryption script, so maybe not feasible.

  9. This seems to be more of an issue of ProtonMail's front page marketing, rather than the PM itself or their implementation of EE2E. And it highlights the true problem of E2EE in general but I'll get to that later. I remember that PM was not trying hide the fact that their service is not for someone like the next Edward Snowden from the very beginning of their service. It's simply for people who want to avoid manipulative advertising and bulk collection. If you are being attacked, someone with patience and resources will always get to you. They specified this in their article back in 2014 https://protonmail.com/blog/protonmail-threat-model/
    However, this speaks so much more about PGP on its own and this is where I believe in Signal developers' philosophy – if you have to explain people what a key is, your secure app failed. Emails are annoying, impractical, no one likes them. And that's why next to nobody is willing to go through the pain staking process of manually exchanging and maintaining updated database of PGP keys with your contacts. You have to pay too much attention, there are so many ways you can make opsec errors, you can't do it too tired after work or half-asleep before bed and you can't make anyone you care about switch because they'd rather lose you as a friend or a family member than learn how to encrypt their emails. ProtonMail should stick to what they were created for – to create a service that's more resistant to mass surveillance and is approachable by average non-tech-savvy users. And they are doing a great job at that. ProtonMail is not for illegal activities and it's not for you if you expect to be a target. Vulnerability with webmail E2EE doesn't just go for ProtonMail. It's true for other E2EE email providers like Tutanota and Posteo and it's ten times more true for Yahoo Mail, Gmail, or anything from Microsoft, where the employees of these companies or their 3rd party partners would read your emails share the contents with anyone they want.

  10. First: I didn't read both textes you showed. Second: I can't adhock evaluate if protonmails E2EE is done right. But I have to point out and clarify: The devil is in the detail. Protonmail mentions "mail-servers" and not "web-servers". It's a difference! It is another kind of service. Altough the same pyhiscal server can run a "mail-service" and a "web-service" side by side. This practice is not common for "bigger" companys. Except they are running these services as virtual machines on one Hypervisor. But I don't want to dive to deep into this.

    Regarding the securness:

    Assumption: The algorithm/protocol itself is secure and does not allow eavesdropping by "breaking" the encryption through different attacks. Like Alice sends Bob a message encrypted with a secret. Mallory is sitting on the path and can't decrypt the message without knowing the secret. This is E2EE.

    If protonmail (or an evil-one that compromised the supply chain) supplies compromised javascript to catch this secret at one "end" doesn't mean that the E2EE itself is broken! It just means the "end" or supply chain is compromised – which would be really bad!

    I don't want to claim whether or not an implementation of JavaScript based E2EE is possible.

  11. IMHO this paper did not look at all possibilities. You can create trusted-code in the web, thinking of sub-resources checksums (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity). For sure that is not easy from a user perspective (comparing hashes in the HTML-source) but security was never easy

  12. I kind of agree with him. BUT Whatsapp as example is a bad example. It's webapp is served by a Server but the sending of the Messages and the encryption is done on the Mobile Device! Also: That it's save can't be Mathematically if some options can't be proven like this. The encryption coudl, yes, but the infrastruktur? Also if it to be defined as insecure? than, it is, with a simple Boolean Operation not secure (Crypto AND Infrastructur = False)

  13. Good video :). I think that end to end encryption on this specific scenario is a way of saying: use my service because I promes that I will not read your messages. In order to guaranty end to end encryption you must guaranty a single property: the private key is SECRET, and on the actual implementation this is not guarantied.

  14. In the end it comes down to trust, would you trust protonmail's serverside security/integrity ? Personally the only servers i would trust with my personal data/messages would be mine, preferably those i could have physical access to when needed.

  15. Thanks for the great content learn something new every day and you have a really great way of presenting things to make it interesting. Could you perhaps look at doing a walkthrough of microcorruption.com to explain in detail the various techniques and thoughts behind each solution?

  16. You assume your viewers know what end to end encryption is. You did not explain that end to end encryption requires integrity which you absolutely cannot guarantee in a webapp. Many people are now thinking end to end encryption is some cryptographic cipher, just some function that if you execute it you can say you have end to end encryption.

  17. I think Nadim is right and protonmail protects it's business. To increase email security use your own local PGP. But it means you don't need the protonmail anymore)

  18. i don't think it's unlikely at all, that certain malicious updates only get pushed to certain app store accounts or email adresses.
    pushing updates to everyone will be discovered in no time.
    but only targeting single accounts is a different story.

    in this case, it is even safer to refer to apks/ipas from public places, than trusting the app store, that has your specific phone id, email, whatever linked to you.

    a public apk download link that offers malware can be exposed to public super easy. you as the only customer getting pushed a shady update is nearly impossible to discover, if it comes from your trusted app strore. it is just technically not likely to be discovered, unless you do forensic work! your device probably never even exposes the update file to you without digging deeper.

    who guarantees you, the app store is koscher? the app store would be a number 1 place for delivering malware.
    the app store has to be considered evil. just like any user input!
    as it is unlikely that it might distribute malware to the masses, it is super easy to distribute it to only single targets. especially as it is known, that app stores offer backdoors to several governmental agencies. all these intermediate languages like compiled objective c or dex files can be decrypted and rewritten and recompiled with ease…… as a developer: do some obfuscation of your code if you like. it might be hard to understand the underlying code, but you can always insert your own!!! the publisher of the app will never know if one single target is pushed one single version of the malware.

  19. In-browser security protocols might prevent this, but users could conceivably utilise a user style sheet to introduce information that the ProtonMail server doesn't have access to.

  20. The line he drew is arbitrary and you too agreed, saying android/iOS can't deliver evil code is also nonsense, if they did want to, they could simply deliver both evil and non evil on same app and compromise the mails in same way how web would.

    Yes, sure JS is always a problem, but so are iOS and Androids.

    I do have a bit of idea though, create a separate 3rd party fully free, fully open (source), fully transparent server, which hosts the code for encryption and decryption.

    Now instead of loading code directly from protonmail's server, just use that one, anything in that server should be verifiable, before every release, get a checksum, and make sure it hasn't been compromised, one team dedicated to check if there's a compromise will also be enough.

  21. Well, that's kinda obvious, the main reason I don't use Proton mail or Tutanota.
    Edit: It's kinda obvious but it's good if someone famous points it out, because people just tend to use things without really giving a deep thought about it.

  22. So a work around would be: store the E2E code in the browser & have the Web APP use that if present, so the point of trust is now with the browser.

  23. IMHO even if we will assume that ProtonMail always deliver a secure script, there are still cases that might affect on webapp behavior (especially
    JS environment) and cannot be handled by ProtonMail: browser plugins, web browser security issues and etc.

  24. E2EE as webapp is totally possible.
    You just need FOSS software and a secure hashing algorithm
    Just make sure the javascript served is FOSS unobfuscated javascript open to audit
    Have independent auditors (preferably multiple auditors) flag the code as uncompromised (or better yet, audit it yourself since it is FOSS).
    User whitelists the hash of the javascript served based on their personal audit, or the auditing of independent entities. Now compromised javascript is impossible to serve, since it would not be whitelisted by the user.

  25. well intel CPUs do have serious hardware bug which allows for absolutely invisible code execution
    this was in every x86/x86_64 intel CPU from introduction of first ever Pentium (1994?)
    this was patched in 8th or 9th Core iX generation
    we are talking about ALL Intel CPUs made in around 24 years! unlikely? not so much
    actually there is no possibility of checking every CPU for every possible combination of code and data, as this would literary take eternity
    even just trying to find all Instructions on recent CPU (better then 2nd gen Core) takes over 24h
    CPUs does have bugs
    CPUs have hidden intended inductions, which users will NOT ever be aware of and neither Intel nor AMD provides public documentation of those instructions (but they overlap in good 90%)
    Please do not say that hardware is unlikely to have backdoors
    CPUs do have backdoors
    every piece of hardware have some kind of CPU inside (even IEEE802.11 is not pure hardware and there is CPU inside and there is software – what is firmware? just a piece of extremely embedded software)

  26. So if I understood it right, the main problem is that the code the encrypts/decrypts the emails could be changed and not that the code itself is impossible to make.
    So if we can be sure that the code we received from the servers is uncompromised, and the browser/machine that we run it on is secure, then we can be sure that we have E2EE and our emails are fully secure and private?
    If so, then can't we use something like a checksum to make sure that it is safe?

  27. Well, I draw the conclusion that if you need security the you need to have open source software from the applications to the operating system and ideally "open hardware", too.

    Because if and only if everybody can check whats inside it can be trusted.

  28. One test you can do, then it can tell you everything.
    You know, you have two choices to choose from, either (.ch) or (.com), so explore a random word, make sure that it is available for both formats, make sure it's a complete rubbish that no one would want, something like (fwuczmloq).
    The moment you register (fwuczmloq.ch) go and try to register (fwuczmloq.com), they will tell you it's not available.
    I think that it's not only lying about it's peer-to-peer services, but also creating a mirror for each and every account, so they just copy all your information into that account (IMHO).
    TRY IT!!

  29. In the end you as a person have to trust a company/service. But despite all technical security measures it only takes one human to fuck it up big time.

  30. It is possible to make a key to which you have no way of using yourself once you delivered. That is not impossible.
    But the fundamental question is: "There is no insurance of your security if you cant trust the one issuing the security measure".
    That is something kinda forgotten, specially by the "blockchain folk".
    Nothing prevents protonmail to actually make a key they cant use to read your message once it is coded. It is actually something very easy I myself implemented in a system a developed for chat long ago when I was learning about encryption.

  31. I don't think the paper gives a reasonable assumption. If the protonmail server is hacked, the mail already on the server cannot be read because its encrypted. In order to decrypt it, the server has to ask the client for keys. So,
    1. Given no user interaction, past mails are secure.

    Which brings us to the second point. The server can send malicious code. For this step, there can be several types of attacks: a) Protonmail's original server is hijacked. b) Man in the middle c) Forged Server

    (b) and (c) can be safely eliminated because they wouldn't have the same certificate as Protonmail. This leaves only (a). This is a highly unlikely attack since we can assume protonmail team installs the latest security upgrades/firewall rules/intrusion detection and thus it has to be more secure than the client PC.If you consider this assumption a vulnerability then most other services which are considered very secure like all TOR websites are also vulnerable. Bank websites are vulnerable. Google websites are vulnerable.

    So good thing your friend got his paper published but I'd like to hear what your friend recommended as a solution to this problem. If he didn't, then its just like saying "I wish 1+1=3"

  32. I personally agree with the claim that E2EE is not possible. I even would claim that E2EE is not possible as long as you do not control the hardware that is running your code. In 5:17 you explain that the CPU might go into some secret mode and then, seconds later 5:30 you dismiss the idea as silly. Isn't that the reason we have companies like Purism that try to produce laptops with no proprietary code? Isn't this exact attack possibility via a malicious CPU the reason we have projects like RISC-V, where we try to create a CPU IP that we control, that is open so everyone can check if it is not doing weird stuff with our data?

  33. Problem is in HTTP protocol itself. Webapps can be 100% secure only when served via man-in-the middle resistant protocol like IPFS. That's why I think IPFS is the future of web.

  34. The only problem I see was singling out proton instead of all web based E2EE services. It actually is a problem, especially as businesses react to classified and gagged court orders from undemocratic national security services. That's not nothing, but it isn't just proton at risk. For all we know, proton might already be complying with court orders to send malicious encryption packages to specific end users, and they would have no way to tell us besides whistleblowing. That could be true of any of your favorite services, especially if they do business in the USA. And they do. All I'm trying to say is, protect whistle blowers and elect officials with a strong sense of civil liberties. And ones that know what the internet is.

  35. Well I mean, at least we can read the java script. I’m not saying I do that every time I visit a page, but at least it’s open source by design.

  36. Thanks LiveOverflow. I'm actually working on a project for which this is highly relevant, and so it has given me some points to additionally consider going forward, especially with respect to how I communicate expectations to users. It further reinforces my intent to have signed electron app versions available out the gate, with a web browser version available, but considered the less secure version.

  37. Haven't watched the video yet and will, but just want to preemptively say that when I think about my own cyber security I never think I will actually get myself to a place where it is impossible for someone else to spy on me. My goal with cyber security is to make it such a fucking hassle for anyone to try to spy on me that they give up cause I'm not worth it.

  38. The key, to whether you trust the proton mail web app is just how secure are their servers, and how good is their intrusion monitoring, how quickly they can respond to threats, etc.

    And what about mobile and mobile apps which are just thinly disguised web apps, e.g. Electron, or React Native?

  39. I received a response from ProtonMail Security stating: We have 10 million users and no other complaints of this nature, so perhaps you can fix the issue on your end…
    I share this example here for anyone who might happen upon it while researching and considering ProtonMail. I’m coming up on 48 hours of not being able to access their log in window which just keeps cycling, yet I do not experience the problem accessing my email accounts with multiple other email services. I’m tired of being asked to help troubleshoot, to use other browsers, to “recreate” issues, the other email services that I use never ask me to do these things. I am not computer tech savvy and just want to send and receive email. Truth is my PM account has probably been hacked. My mind is now set on leaving them and not even downgrading to their free subscription.

  40. TL;DR: make protonmail (or other PGP-based) exception and install it to your browser so that you don't have to download (possibly) malicious code every time you use protonmail.

  41. I agree with Nadim's conclusion, and has been my own conclusion prior to reading this. Since email is asynchronous, there must be a sort of man-in-the-middle to enable a web app to work. The one you must trust is Protonmail.

    You are always rolling the dice, but I don't know of any dice that are loaded more in your favor than Protonmail at the moment. (And I'm not a Protonmail user yet, and not sure I will be.) The common argument in their favor is they are based in Switzerland and they have laws… Reality check. Switzerland does what is in Switzerland's best interest. Fortunately, Switzerland's relevance in the world depends on being known for privacy and neutrality. However, it is also not in their best interest to be known for illicit activity, and the judge of that is Switzerland itself, and acquiring private information will not be cheap or easy, because it represents a risk their financial pillar. While the Swiss privacy protections are why we shop there, they are a PITA for Protonmail, as the Swiss are understandably not tolerant of "accidents". It is in Protonmail's best interest to not retain anything longer than necessary as a risk reduction for their business. The next question is, how would they know which accounts to monitor? To monitor all, and have that information used against the owner, even indirectly, would be a huge risk. Metadata is often used, but if the user uses VPN + TOR, and with Protonmail not maintaining anything longer than necessary, that kind of goes out the window without some type of legal Swiss intervention, or internal clandestine incentives and associated risk. The next thing we would be looking for is a profit model based on privacy that is sustainable. They claim to have that by limiting the capabilities of free accounts and requiring paid subscriptions for more or to host user-domain email. They risk their existence if their name gets sullied by privacy issues. Headlines such as in Forbes, "The Only Email System The NSA Can't Access" is what made them. If you wanted private information from Protonmail, why would you even bother Protonmail or the Swiss? The easiest way would be to analyze metadata from a client to determine who to target, which they can buy just like any other advertiser. With taxpayers funding the research, government agencies can pay to discover paths for secret exploits, or use their leverage against Microsoft, Apple, or Google, to deliver what they need. However, look at it from the spys' perspective. Would you want to spook Protonmail users who believe their email is private, if you have implemented a way around it on your targets?

    Contrast Protonmail with WhatsApp. The fact that Facebook, a public company, beholden to shareholders, whose profit model is based on selling information about you, and has a track record of being accident-prone with your private information, should tell you all you need to know. They start with the highly respected Signal Open Source secure protocol, add an unnecessary closed source man-in-the-middle for "scalability" reasons, promotes it as a "free" service, in the U.S., which should tell you it makes money somehow, even if only for cornering the metadata so those who want it, must buy it from them. WhatsApp is driven more by countries outside of the U.S. who attempt to hit their citizens with message-based fees. This makes it a requirement for International messaging for U.S. citizens. Hearing "private" makes people happy but they have a fox watching the hen house. Why people use WhatsApp far more than Signal (IMHO) is reliant on users' ignorance. Thus, WhatsApp is in a better position to acquire mindshare through advertising and name association with Facebook, and development funding, making it a smoother, more integrated (with your personal information there and elsewhere), experience. Facebook's unnecessary man-in-the-middle requires "scalability" Signal doesn't need. Signal's implementation is Open Source, establishes the session using their servers, and then is no longer in the middle. The connection information only exists while information is being exchanged. Signal's existence relies on privacy because it is what they sell.

    So while I agree with Nadim's conclusion from a technical perspective, there are nothing but counter-incentives to exploit Protonmail itself. From a user's privacy standpoint, VPN + TOR are not standard because they are not accepted by many common sites because those sites are tracking your and have implemented quasi-two-factor authentication for transactions. The part the spies don't want to hear is you using a VPN + TOR + plus an Open Source operating system, with a small attack surface, that is designed for privacy, and has an encrypted hard drive.

    I would be interested in the thoughts of others.

  42. Can you please make a video about that "recent bullshit bloomberg story"? I would really like to know why is it bullshit, to this day I thought it was truth.

  43. Could you (ab)use caching policies to make it so that the only way to deploy new code to the browser would require authorization from that code itself? I think App Cache is deprecated, but I believe it was possible to set the max-age header on the App Cache manifest to something in the far future, and basically get clients "stuck" on a particular version. This would basically turn it into "trust on first use". You might could even make a client hash a proposed update and refuse to accept it until it had been out for a number of days (hopefully giving proton mail time to fix the problem if the update contained malicious code). I realize it would require considerable examination to make sure there would be no way for a compromised web mail server to bust the cache. Also, you would have to train users about the dangers of trust on first use and possibly warn them against clearing their cache or trying another browser if the app isn't working.

  44. His claim is that E2EE is not possible. He only showed that browser and web app based E2EE can be compromised and that said compromise would be significantly easier to achieve then compromising an independent app provided to the end user via a more complex app store system or compromising an end users arbitrarily store bought hardware.

    Saying browser based "E2EE is not possible" is false, it is possible, it's not as secure as app based E2EE since it can be compromised far easier then the alternatives for delivering the same level of encryption. But, thing is, not as secure doesn't make it not possible, it just makes it less secure/easier to compromise.

    There are magnet based lock mechanism that are considered unpickable. Do you know what happens if one such mechanism is ever encountered? the lock isn't picked, it's circumvented entirely. I don't need to compromise either Protonmail or your browser if I compromised your OS. If I know everything you type I could care less what encryption you use to send your mail. What was the name of that major desktop OS that had an inbuilt keyloger and which sends your keystrokes to the cloud to help them improve their AI that is supposed to help you out in the end, I think it was Doors 10, or maybe Blinds 10? ah, yes Fenetres Dix.

  45. If multiple-party cooperation makes Android apps more trustworthy, then just use CORS to download the same PGP app from multiple 3rd party servers, and encrypt only if the downloads agree. Problem solved. Now JS is at least as trustworthy as the Android app.
    Can be implemented via an open-source browser extension without open-sourcing any of ProtonMail's code.

  46. Could protonmail deliver the PGP JavaScript code in a signed manner? Not signed by PGP as it would then have to be checked by a potentially malicious JavaScript PGP implementation, but rather signed with there SSL certificate? Something that could be checked by browser code. This way only the devs at protonmail could deliver a malicious code, and not the attacker compromising their servers? No idea if doable or not. On linux distribution, maybe the webapp could use the native PGP implementation as almost all Linux OS ship with it. On other systems, well… I wouldn't trust Microsoft anyways as they keylog in the OS.

  47. It would be nice if there was a feasible way to load local versions of well know js libraries for sites that need it. This pertains less to pgp and more to stuff like ajax that is used by a stupid number of sites and there's no reason for my browser to have to grab it each time from the specific site it's heading to.

    Instead of local copy's of the libraries it would be nice to see at least some form of verification like comparing hashes of well known libraries.

    I'm not a js developer so I'm not sure how fragmented the use of various versions is and whether storing local copies is worth it from a non security standpoint but it seems like a lot of unnecessary overhead.

  48. Remember how MEGA came up with all these alternatives to their web-based client-side encryption due to an identical conclusion? It was in ProtonMail's interest to deny such a possibility (because it's expensive to deal with), but both services are marketed to the cautious, paranoid, and cynical. With such a consumer base, can you expect to take half measures? Maybe that cynicism is more the case with MEGA than it is with ProtonMail, and ProtonMail will be successful without being open about its design flaws. I don't know; I don't use either… yet anyway.

  49. Overplaying the problem here. All WebApps that do end-to-end encryption have the same issue by design. Also, protonmail clearly states all that you are addressing in their documentation

    Not a bad video per-se, but Nadim is biased and attacked Protonmail for ideological reasons. WhatsApp is equally (if not more) vulnerable to this problem, and their documentation uses the same type of language while not even showing the warnings about end-to-end encryption on the WebApp.

  50. Why do you only talk about ProtonMail, AFAIK basically every encryption-software has this problem. Veracrypt, Truecrypt, every Browser performing HTTPS, etc…. All of this are as vulnerable as ProtonMail… (or am I wrong?!?)
    Checking Javascript Code is far easier (two clicks in the Browser) than checking an Apps SourceCode.

  51. Their claims aren't false, they can't decrypt your data from rest, what you're describing is that they could use their position as an authority over their CDNs to perform an attack to steal your key, and then they could decrypt it, which is fine, but it doesn't contradict their claims. Such an attack on ProtonMail's behalf would be utterly devastating to their business (so they won't), but is feasible for an attacker to implement potentially (collect thousands of keys + dump DBs = huge data breach). An easy solution is one which we've needed in the web for a while now. With CDNs being trusted more and more to deliver big JS payloads, everyone is becoming vulnerable to a CDN being hacked. The fix for this in other P2P or CDN distribution networks is adding trust, so the JS needs to be signed by the authors, in a way that can be verified by the browser downloading it. We also need this feature in package managers like npm to avoid similar attacks happening on servers. This change isn't that hard. Another that's trivially implementable today is to not rely on a CDN for sensitive resources, and instead set up client side caching through a service worker or something. This moves the responsibility back to you through a secure web server over SSL which can be protected by cert pinning, so it limits the scope of an attack to one place where you can lock things down.

    Alternatively, if you care about your own security, you can use an extension to load your own scripts on ProtonMail, ones you've verified aren't malicious, and you can even install your own service worker or extension hooks to prevent any unexpected API requests or network traffic from the page, as well as a CSP to prevent any further JS injection.

  52. If it was available and up to date on fdroid, then this kind of attack would be no concern. Because the code is compiled by fdroid and publicly audible.

  53. That's why my ISP uses Mailvelope for end-to-end-encryption. Keys and encryption code live in a browser extension, and the rest is still webmail. So not a 100% pure web-app, but a lot more secure (assuming I don't get a "trojanized" extension pushed). And maybe the keys and encryption code could become a web standard and implemented in browsers directly (yes I like dreaming sometimes).

  54. I have a question: why would A and B have to exchange PUBLIC keys in a secret way? All in all that's why they are public.

  55. If Protonmail generates the public and private keys sending them to sender and recepient – they can decrypt the messages easily on the server and read it, sending the encrypted version to the receipient as if nothing happened.
    I don't know a way how a browser can store the public and private key, without loosing it. In Thunderbird it works simple, you generate the keys and the receipient generates the keys. Receipient hands over his public key file when you meet in person e.g. Then you just enctypt the message with his public key. Then the recepient can decrypt it with his private key.
    So for me it does not seem reasonable to call it E2EE.

  56. Privacy concerns are now trending but still people want comfort more than privacy, E2EE message exchange has been done for decades now and is not rocket science, it's just inconvenient, not very practical. While people remain lazy and apathetic about the inner workings of the machines they spend most of their time on there will be an endless stream of "secure service providers" that will keep giving "convenient solutions" to these people to cope with their privacy concerns while not putting much effort into it while next gen big brothers collects money and data. Don't trust this provider, don't trust the next one, isn't really that hard.

  57. This is basically just a hype video that, although it does make an interesting point, unrealistically targets protonmail (more-or-less on claims of false advertising which can be much more easily explained as poor phrasing by their advertising division). This does bring up an interesting issue though: if a foreign agent (in this case the JS code) is allowed access to your private keys, then, theoretically, they could steal them.

    I'm not a cryptography specialist, but I would imagine that this could only be effectively mitigated if all encryption requests were handled by an internal browser mechanism that held keys in a cache somewhere and provided a JS API for encrypting a message, decrypting a message, spawning a key with a specific name, and destroying a key with a specific name (where spawn/destroy would be atomic so that no user's left with inaccessible data due to malformed keys). This wouldn't be an issue since, even if someone did have a compromised browser or a keylogger installed, that'd be outside of the scope of the E2EE issue stated in the video (and preventing that is as easy as not going to a bad webpage).

  58. Thanks a lot for your great videos.
    2 questions:
    1. Would it be sufficient for an attacker to get hold of an SSL-certificate to then impersonate server P?
    2. Would a web-app run the risk of some a malicious site compromising the current browser session and gaining hold of the private key that way? Is this a more plausible threat than a trojan for your phone etc.?

  59. Could we build crypto-algorithms into the browsers directly such that then at least the browser has to be compromised which one would expect is more difficult than compromising a web-app?

  60. There is no secure E2E binary encryption in the age when people are creating quantum computers. We need end user quantum encryption, but that's not gonna happen anytime soon.

  61. I don't agree that webapps are very different from google play store apps. An attacker can hack a google play store dev's machine to inject an infected aar or jar library in his workspace, which will be packaged into the apk, and sent to google play store. The injected malware can check if it's on the intended target's device before activating, so yes, you can focus the attack on specific individuals/regions/ips etc.

  62. I think it's fairly naive to think Apple would never push a bad software update, the NSA has already silently and secretly forced companies to do exactly that in programs like PRISM.

  63. Isn't it pretty easy to fix this though? Just deliver a browser extension that the website can request to run the encryption instead of a new javascript file each time. One installation means one-time verification of the code. Publish a hash of your extension that users can use to verify if they reeeally question the security of their installation. Then boom. You're almost as secure as the Android app.

  64. Anything a man can make, another man can break. It's the world we live in. Nothing is secure if you share it or it involves other people.

  65. Well its also possible to deliver a ios app with malicious code that targets only one user. I mean it would be only one if statement to test if a certain user is in a database of tagets or not. And if he is start bad app else start good app.

  66. It's semantics. There's an infinite amount of possibilities just like with irl security, just have to minimise those risks as much as possible and I think Proton are doing that.

  67. From what I got out of this is that, if someone can compromise the web server. Then we are compromised as well. We are only secure as the server is secure.

    Even like you said protonmail have access to inject java script code, but we trust them not to do that. The bottom line is to me is that if their network and servers are secure we good!

  68. 1. https://youtu.be/DM1tPmxGY7Y?t=119 This is not correct. Email data is not encrypted with public key as public key has an encrypted message length. Instead email is encrypted with shared private symmetric key.
    2. You assuming that Alice and Bob met and exchanged keys, but in real world key exchange is done via ProtonMail server.

Leave a Reply

Your email address will not be published. Required fields are marked *