Andy Yen, the CEO of Proton (Mail, Drive, VPN, Pass…) answered a lot of the questions you, the community, asked, in an interview that covers basically everything!
He discusses security, privacy, the origins of Proton, how they operate, Linux support, future projects, products and features, quantum computing, passkeys, and more!
Proton Mail: https://proton.me/mail/TheLinuxEXP Proton VPN: https://protonvpn.com/TheLinuxEXP
👏 SUPPORT THE CHANNEL: Get access to a weekly podcast, vote on the next topics I cover, and get your name in the credits:
YouTube: https://www.youtube.com/@thelinuxexp/join Patreon: https://www.patreon.com/thelinuxexperiment Liberapay: https://liberapay.com/TheLinuxExperiment/
Or, you can donate whatever you want: https://paypal.me/thelinuxexp
👕 GET TLE MERCH Support the channel AND get cool new gear: https://the-linux-experiment.creator-spring.com/
🎙️ LINUX AND OPEN SOURCE NEWS PODCAST: Listen to the latest Linux and open source news, with more in depth coverage, and ad-free! https://podcast.thelinuxexp.com
🏆 FOLLOW ME ELSEWHERE: Website: https://thelinuxexp.com Mastodon: https://mastodon.social/web/@thelinuxEXP Pixelfed: https://pixelfed.social/TLENick PeerTube: https://tilvids.com/c/thelinuxexperiment_channel/videos Discord: https://discord.gg/mdnHftjkja
#vpn #privacy #proton #onlinesecurity #protonmail
Timecodes:
00:00 Intro 01:16 How did Proton start? 03:24 Why start with email? 06:03 What is Proton’s business model? 08:34 Why set up in Switzerland? 11:33 What data do you have on customers? 14:39 How is encryption important? 18:20 Do you always need to use a VPN? 20:47 Why focus on building an ecosystem? 24:55 Is an Office Suite planned? 26:29 What differentiates Proton from competitors? 30:26 Is Proton a viable alternative to big tech services? 33:31 Why expand to more products instead of finishing existing ones? 37:19 Does the general public care about privacy? 38:45 What’s next for Proton services? 40:08 What are the plans for native Linux clients? 46:03 Will ProtonVPN offer dedicated IPs to everyone? 47:46 What’s the environmental impact of Proton? 49:27 Proton on F-Droid, without Google Play notifications? 52:03 Why are code repos all separated and hard to find? 53:12 Why are addresses ending in “.me” ? 54:57 When will all apps reach feature parity? 56:24 Will SMTP relay be supported? 57:47 Will Proton focus more on businesses in the future? 59:50 Why put all your eggs in one basket with just Proton services? 01:01:00 Will Proton support passkeys? 01:03:21 Does E2E matter is the recipient isn’t using it? 01:04:49 Will Proton disable port forwarding in VPN? 01:06:41 Is encryption enough to make email private? 01:09:06 What protects users from a change in Proton’s code licensing? 01:11:14 How does Proton protect its infrastructure? 01:13:14 Impacts of Quantum Computing on privacy and security? 01:14:24 What’s the future of Proton Bridge? 01:16:25 When will Proton photos be a thing? 01:17:17 Plans for Proton Notes? 01:18:20 Will VPN support the Apple TV? 01:21:12 Support the channel
I said “i think” because, unlike many of the other things I’m saying here which are statements of fact, my suggestion that ProtonMail specifically is designed for this attack to be possible is merely well-informed speculation.
See the links in my earlier comments for evidence of this kind of attack happening against all three of the other largest email providers with similar architectures as ProtonMail (Tuta, Hushmail, and Lavabit).
If both users are using the bridge (assuming it is designed how I think it is), they would certainly be better off than if one or both of them is using the webmail e2ee. However, I would never use or recommend using protonmail, even with the bridge, because it is very likely that the people I’m writing to would often not be using the bridge. Also, because ProtonMail e2ee doesn’t interoperate with anything else, and by using it I’d be endorsing it and encouraging others to use it (“it” being ProtonMail, which for most users is this webmail snakeoil).
Also, I don’t know in detail how the bridge actually works, and, like most of the people I know who sometimes audit things like this… the open source bits from Proton like their bridge aren’t interesting enough to be worth auditing for free (except perhaps by a security company, for their own marketing purposes) because, even if it turns out to be soundly implemented itself, it is a component of a non-interoperable proprietary snakeoil platform.
From your earlier comments I think you’re working from a mental model where an individual employee performing the attack would need to check something in to git or something like that, but, don’t you think anyone with root on, say, one of the caching frontend webservers do this? I suggest that you try to think about how you would design their system to prevent a single person from unilaterally doing it, and then figure out how you can break your design.
Yes, I get that you are saying that, but it’s because you have not been hearing me saying that HTTPS has been circumvented numerous ways over the years and will continue to be. Do you think we’ve seen the last rogue certificate authority? Or the last HSM where (oops!) they key can actually be extracted?
Don’t you think there is a reason why most modern software update mechanisms don’t rely solely on HTTPS for authenticity of their updates?
🤔 I actually wonder why ProtonMail lists Digicert and Comodo alongside LetsEncrypt in their CAA DNS records. (Fwiw, they currently have a cert from LetsEncrypt, from my network perspective at least). Doesn’t that mean that, against a browser supporting DNSSEC and CAA records, a rogue employee at any of those 3 companies can issue a cert that would allow this attack to be performed? (Of course, against a browser that isn’t validating CAA with DNSSEC, anybody at any one of thousands of sub-CAs can also do it…)
As someone who has been one of those technical consultants, let me tell you, arguing with at-risk people about the veracity of posts on privacy forums singing the praises of things like protonmail is part of the job. 😭
This is a false equivalence in several ways:
Again, these software distribution channels (eg, Linux distros, etc) have many of their own problems, but they are in a different league than javascript in a browser. Ways they’re better include:
Isn’t that because their web page says something to the contrary?
Really? Scenario 1 is possible? You think a privacy-touting email service with 100M users might have never had a request to circumvent their encryption, despite being able to?
Again, I’m not just talking about 3 letter agencies, but anyone who wants to read someone’s mail. And often there is a point where the email address is all that is known about the target.
I use some mitigations I won’t go into, but, yeah, on the system I’m typing this on I do sadly use a distribution which relies on a single archive signing key, so, if you compromise that key (or the people with access to it), and obtain a valid HTTPS certificate for the particular mirror I use, and you know the IP address I’m using at the moment I’m doing an OS update, you can serve me a targeted (by IP) malicious software update. 😢
I think the vast majority of Mutt users don’t get their Mutt binaries from Kevin McCarthy, and having him put a targeted backdoor in the source code would be foolish as it would be likely to be noticed by one of the mutt distributors who builds it before it gets distributed. Since reproducible builds still aren’t ubiquitous, the best place to insert a widely-distributed-but-targeted-in-code backdoor would be at the victim’s distributor’s buildserver.
Yes, but unlike the ProtonMail case there is a chance of being caught so it is a much higher risk for the attacker.
There are a wide variety of software distribution paradigms, on a spectrum of difficulty to attack. At one end of the spectrum you have things like Bitcoin Core, where binaries are deterministically built and signed by multiple people, and many users actually verify the signatures to confirm that multiple builders (with strong reputations) have independently built an identical binary artifact. At the other end of the spectrum you have things like ProtonMail with zero auditability, users identifying themselves and re-downloading the software at each use, and numerous single points of failure that can be exploited to attack a specific user. Things like mainstream free software operating system distributions, macOS, Windows Update, etc sit somewhere in the middle of that spectrum.
No. See previous answers for the massive differences.
I will skip some parts because I think it’s not worth repeating.
This was clearly just an example. Any distributor is the single of point of failure. You can coerce or compromise it, and you will serve compromised software.
No there isn’t. There is nothing that prevents Github to serve you a different file when you query the same URL than what regular users will (for example by IP). It’s trivial to do this with any reverse proxy. And the same applies for a signature file, which means you can only notice if you manage to get the file and the signature from someone else and compare the signature/hashes for the same release. Which is basically the same as saying “I will compare my JS blob de-minified with the one in the OSS repo”, nobody does this either, I agree. This can totally happen every time you download something from any website, technically, provided that the server is coerced or compromised.
Not really. The spectrum is much narrower than how you present it. I bet 99% of users install software in one of these ways:
Almost all the package managers AFAIK work under the same model (package, signed with the distributor’s key, served via web), which is susceptible to coercion and compromise. All the webservers and platforms can be coerced/compromised to serve different files (installers) to different clients.
Am I missing something? Is there another way to serve software that I am missing?
There is one, so far. The provider being compromised. The rest is your speculation such as
Which is like saying, there are vulnerabilities. Yes, there will be vulnerabilities, but this applies to any software too. And if HTTPs is broken to allow MiTM then this is a risk for any software you download via web, starting from the linux ISO, so it’s far from a webmail-specific problem.
You list:
Nothing, absolutely nothing, tells you that it’s enough to compromise one Proton employee to gain access to production and replace the code. Also, you have absolutely no idea of the security practice of the couple of people who handle those keys, they are not accountable in any way, they don’t need to be compliant with any standard (for what is worth), etc. I would say it’s much more likely for any of the mirrors/repositories to get compromised compared to Proton.
In fact, you say:
I do this for a living. One way to do this is to close off production environments, assign temporary permissions that require multiple people to sign-in at the same time and spectate when production is accessed. Teleport allows to do this, for example, nothing I am conjuring out of thin air. Similarly, the CI can implement a million check to verify the provenance of the software and require multiple sign-off before things are actually deployed. Breakglass procedure exist (usually for a handful of individuals), but they generate alert and are audited post-factum, so that such attack would be detected.
True, but for me being attacked this changes very little. Attackers can just establish a C2, check if the target is right and do not do anything else on other devices. I grant you, this is a difference, but the control here is the fact that more people will possibly spot the issue and I will get to know it before getting compromised. It’s possible, but it’s a very weak control.
True, bigger attack surface, but each individual mirror can be compromised via the same vector (and of course the source can). Also Proton does not have a machine that serves everyone. Might have multiple regions, multiple clusters, separate by accounts, departments etc. In addition, you are talking about a highly targeted attack. Relying on the obscurity of which mirror someone uses is really not something I would consider applicable here.
The biggest difference is the automation with which JS code is “updated”. This is what makes the attack potentially slower via regular supply chain. Nothing I would consider massive for sophisticated attackers like the ones able to exploit this vector. So the massive difference in your opinion is that:
On the other hand:
If for you these are massive differences, OK. For me they are not.
Finally:
How it is relevant what both users are using the bridge? The bridge is literally doing the same that -say-
muttdoes. This has nothing with the bridge, what you are saying (I think) is that you wouldn’t send an email to someone if you don’t trust the software they use, but this is independent from you using the bridge. You can add other people (non-Proton users) keys to be used, so Bridge -> Mutt is exactly the same as Bridge -> Bridge or Mutt -> Mutt.In this case there is no tool that you can use that will “protect” you, if you don’t trust the other side.
Which is not a security consideration.
The security model of the bridge is the same as the security model of
mutt, or other CLI tools or anything you might use for PGP. It seems you have absolutely no security consideration why this would be worse.So, in short: