Web-based cryptography is snake oil
devever.net
devever.net
Custom-engineering backdoored client software, and rolling it out to a subset of users in a targeted attack, is not comparable to storing everything in plaintext on the server and looking through it whenever the fancy strikes. Practicality matters a great deal in information security.
Yes, it is perfectly possible to do the former – just like it is possible to enter any home and simply bug all hardware inside. That doesn't mean this scenario should be part of a normal person's threat model.
The article is correct in the sense that technically, web-based cryptography requires a degree of trust in the server provider. But the article is utterly wrong in concluding that this makes it snake oil, because attacks are substantially more difficult and costly.
With an app from an App Store you are trusting at a minimum:
- the vendor
- the App Store
- the update system for your OS
For a web app (via SSL) you are trusting:
- the vendor
- the browser and it's update system
- the OS and its update system
There is barely a difference in a world of auto updating software.
Unfortunately, the vendors have little reason to facilitate that.
- You're also trusting a large population of Certificate Authorities (CAs), subject to the post-compromise implications of Certificate Transparency. Only one needs to be compromised.
- An app "update" occurs on every page load, giving attackers flexibility and more frequent opportunity to intercept app payloads - perhaps as users cross into networks the attackers control.
- There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.
These are all practical constraints we're grappling with while working on Backbone[1], and why deploying native apps is a top priority for us. Nevertheless, we need to reach users where they are, and that means we can't completely deprecate our web app.
I fail to see the difference between Web and Native in that regards, in both case the attacker need to both:
- a compromised certificate
- a way to redirect the user to their own server (be it DNS or IP spoofing, or something more fancy like bitsquatting).
With only one of those, both the Web and Native app are safe, and with the two of them, you're screwed in both cases.
> - There are currently no sufficient mechanisms to validate the integrity of web app packages end-to-end. Not even under a trust-on-first-use (TOFU) model.
Would you mind expanding your requirements here? (Especially, what's the threat model you have in mind for which subresource integrity isn't enough but your ideal solution would be).
A browser setting to only load subresources with integrity checks would also help
You can do pretty much all you want in a ServiceWorker today[1], but I'll advise against pinning certificates, because you'd just be re-marking HPKP again, with the same gigantic footgun.
> A browser setting to only load subresources with integrity checks would also help
A “browser setting”? What's the point if the user need to set it up themselves to be secure? Some kind of linting tool on CI in order to be sure you never include a resource without SRI would be nice though, but it's not really the responsibility of the browser here.
[1]: you can see an example of that here: https://arxiv.org/pdf/2105.05551.pdf (Note that I've just DuckduckGo-ed a quick example, I haven't read this particular paper and can't say if their scheme is particularly good, but that'd give you an idea).
Yes, the updates are automated on mobile devices, but not under total and full control of the app developer, unlike for websites.
And people do monitor what e.g. the Signal app is doing, or WhatsApp.
I don't agree though that all web-based cryptography is snake oil though. Targeted attacks from the site operator are not the only thing you want to defend from. Say the site operator is asked by authorities to hand over data they store of a specific user. Then the insecure web based cryptography is enough to protect the data: everything that's stored is encrypted.
These kinds of attacks can be made trivial with the engineering capability, capacity, and systems employed by large tech firms like Google, Apple, Facebook, et al. even in the context of these firms as third party platform providers, to say nothing of their own first-party software.
These systems can already classify your political views with a high degree of accuracy, and platforms like the iTunes / Apple App Store and Google Play are already designed with the capability to serve different versions of applications to different requestors (think beta programs), in addition to being the signing entity, for package formats that are entirely within their capability to supplement with additional code.
To be clear - it's entirely plausible that one day, the rogue, evil, mean government voted into power by the evil bad party of your choice could compel Apple, or Google, to backdoor all applications going to clients with the same known political views as yours.
You believe this to be too complex or unrealistic to be plausible (Occam's Razor, right?) but in doing so (and lowering your guard to such threat), YOU are the one that makes this go from impossible to possible.
Also, using normative adjectives like "'normal people' shouldn't worry about this in this in their threat model" implies that those who do have competent threat actors after them aren't "normal", but we know that to be untrue - competent threat actors are, to some degree or another, after everyone. There is no need to "otherize" people for simply being aware of this.
Instead of proscribing behavior, consider that maybe individuals are better equipped to understand their own threat models than you are, and explain the pros and cons of various courses of actions, rather than implying everyone who isn't a sheep isn't normal, and everyone who is a sheep doesn't have real threat actors interested in them.
Practicality is dynamic, TAs use the easiest method within the parameters of their objectives. It is reasonable to assume this attack would be the easiest given lack of other options.
By your logic,56 bit DES is fine because most people won't see attackers that spend >$20k to crack their keys. Just like they won't see robbers who spend that much to break into their homes.
Infosec is different than IRL because TAs can attack arbitrary targets easily with little personal risk. Also, hard attacks today can become common attacks a year from now and security for even the 99th percentile of users who get targeted attacks is important.
The lack of a distribution trust model for the web has long bummed me out, but even snake oil E2EE is a good thing because it makes an active (and potentially detectable) intervention necessary to exploit a client.
Supply chain attacks remain a huge mess. Unless you can validate the worthiness and authenticity of an update, or sandbox it sufficiently, most software can become a threat.
A more manual, opt-in update process for web apps (via service workers) would be a nice innovation, but I doubt it would provide much more safety to non technical end users, since the harder question is whether a particular update is harmful. Solving that verification problem is the crux of the issue regardless of how rapidly software updates.
That's the job of traditional Linux distros.
> or sandbox it sufficiently
That does nothing when it comes to E2EE.
I share this view, but I also think it's very difficult to verify such validation is happening. I don't think most end users would want a distro stable enough to meet a high review bar.
> That does nothing when it comes to E2EE
Not all components need access to the keys or user data. Reducing attack surface reduces the amount that needs to be validated.
And you need to trust the compiler.
Unless you build from the transistors up you have incoherent security theater.
https://news.ycombinator.com/item?id=33899478
If you want to be 'really' secure, you can trust noone. No silicon, no software, no compilers, no certificates, no power grids, no networks, no friends, no coworkers, no nothing.
But that is no life I'd want to live. So I pick my battles and make sure my SecOps is better than 99.9% of the people out there. For me that suffices. YMMV.
So update decisions could have a calculus like, "it's already working; I don't need any feature updates; I'll stick with the stable version" and then attempting to evaluate each CVE on its merits vs. the mitigations offered in each update. (Of course, the way developers like KeePassXC are fighting with the NVD shows that CVE descriptions can't even be trusted these days.)
I foolishly disabled automatic updates for my consumer-grade WiFi router, and I didn't have a plan for manual updates, so it got pwned. I read a few CVEs and I'm fairly sure I know how it was pwned remotely. Thankfully it didn't seem to be making lateral moves into my computing devices, or acting against me personally, and I was able to disinfect the router and put it back into service. The vulnerabilities that enabled the pwnage were fixed by an update which was released about a month before the pwnage, so if I'd been on automatic updates, I probably would've been safe. And that's what the hackers count on.
I would take an unaudited patched-for-known-cves over just not updating any day.
It does not seem to me that there is any middle ground, barring writing your own client, from scratch, against an open protocol.
EDIT: seems to me that web-based e2e encryption, as described here, still protects you from irresponsible employees of the service reading your messages. And database leaks etc. Getting an update that spies on customers shipped is not a trivial thing in most organisations.
How does running the latest updates protect against 0-days? Wouldn't the latest updates be bundling the latest 0-days? The latest updates mitigate known vulnerabilities, not 0-days.
The government using all its coercion forces WhatsApp to update everyone’s app with compromised code. If I simply refuse to download the update, it is impossible for the government to know what I sent?
Let us say I do download the update. I suppose something extremely crude like downloading all messages ever sent client side and just sending it to the server again needs to be done for the govt to access my message. Presumably you would know if such a breaking update was happening through the news and just refuse to update your software.
If the government forces WhatsApp to permanently use backdoored code in the future, then it’s no longer E2E encrypted.
Purportedly E2E provides some degree of protection against an authority of infinite coercion capability like the government. If we are talking about the government, they could just arrest you, torture you and get access to your messages client side if they want to. I think E2E encryption is even more helpful when it comes to protection against opportunistic actors like employees of the company offering the messaging service. I can be assured that no employee can ever sell my data, even if they were bribed, or any Man In The Middle attacks are also rendered pointless.
To make this more concrete: if Apple or Google has Australian citizens in positions with privileged access to software update infrastructure, the Australian government can issue a Technical Assistance Notice compelling them to cause a compromised variant of an app or OS component to be delivered to a targeted user, and binding them not to disclose the existence of the notice.
Given that Google currently leaks like a freaking sieve and has a monorepo where everybody has access to almost all of the code, it is difficult to believe that this plan would go off without a hitch.
I think there are more possibilities than you're considering. As far as I know, once a backdoored app is signed with the correct key, there's nothing stopping the partner CDN(s) from serving it to targeted users. In the simplest case, that's about 5 lines of nginx config.
Also, the ability to stratify OS updates already exists because there are many combinations of country + carrier + device model + user permissions (e.g. special rules allowing internal/external developers and carrier employees to install development builds).
This is true for native software distributed by various linux distro maintainers too.
This is false. Apple's OS-level software update tools have had the ability to target specific hardware items (ie serial numbers, ethernet MAC addresses, etc) for well over a decade.
In to order to do debugging or a slow rollout, I can see them implementing this in their backend. They’re can target updates at least by some combination of properties. Once that’s in place it might not be hard to throw a unique identifier in there as well.
But I also don’t think that this stuff would actually apply to Apple or Google. It’s part of the Telecommunications Act, for carriers and carriage service providers, which, while broad definitions, probably exclude them. Back when I worked at Fastmail (2017–2020), Fastmail as an email service provider was considered subject to that act for data request purposes, but the footnote at https://www.fastmail.com/blog/advocating-for-privacy-aabill-... indicates that in 2021 they were able to change to using the Crimes Act and such instead, so I’m not sure if they’re even subject to the Telecommunications Act in this way any more (not that the A&A Bill affected them anyway since they don’t do E2EE), and Apple and Google’s app stores feel like they would be even more out of scope. But I don’t know; there’s quite a bit of legislation I’ve paid close attention to, but the Telecommunications Act isn’t among that collection. And even if these app store companies aren’t covered by this stuff now, there are probably other governments out there that can already insist on this sort of thing, and plenty of future prospects, the A&A Bill showing how easily this sort of thing can be shoved through.
On whether the assistance measures apply: the Home Affairs FAQ you referenced says they apply to "companies, businesses, organisations or individuals who contribute to the communications supply chain in Australia... This definition captures telecommunications operators, providers of electronic services, developers of software and manufacturers of devices."
And a second-order negative consequence of the type of argument this author is pursuing is that it makes the normal privacy aware folk look completely delusional and paranoid about reality.
The vast majority of people relying on E2EE will not be affected by any of the scenarios he is laying out.
And if they will, it will be the headline of the week (at least on Twitter & Co.) and people will switch. Simple as that.
The authors definition would consider 1-password an incoherent system, yet it's exceptionally effective at mitigating a whole class of attacks. You could argue that any system where you don't control at least 1) the update mechanism, or 2 the keys isn't sufficiently secure. That's one valid approach, but I would recommend anyone who thinks this read Reflections on Trusting Trust: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref....
The more interesting and important problem isn't preventing all possible attacks. It's knowing what attack vectors are worth preventing, and what the consequences for a successful hack are. It's definitely not black and white
The hard divide comes from the truth of who controls your software.
> You could perhaps call this cryptography theatre. The purpose of cryptography theatre is not to deliver actual security from a cryptographic perspective but act as a kind of magic spell which (the user believes) gives them a magic opt out from the obligations conferred by warrants and subpoenas. Thus, cryptography theatre must fundamentally be understood not as a cryptographic technology but as a legal one.
dude drinks too much coffee. Of course I wouldn't trust WhatsApp to not give away my conversations to the NSA. But if I'm using WhatsApp in a Starbucks on their wifi, some script idiot next to me can't read my conversations. Not like I use WhatsApp (or talk to people, really) but the security here is on a spectrum.
The histrionic use of "snake oil" is silly. Only idiots think that secrets are safe under all conditions, viz, the above. The real world meaning of secure is to make it very (very, very) difficult for bad guys to get access to your stuff.
It is neither reasonable nor desirable to have some kind of perfect world where no mistakes can be made to help bad guys get caught. If this can be done with almost zero good guys being compromised, good enough.
Sanctimonious sneering about 'theater' when WhatsApp, Signal and iMessages make practical security available to the masses is, well, sanctimonious. Unpleasant, even.
2. The author's argument also applies to the App Store distribution model. Apple or Google may choose or be compelled to publish an app or OS update that is only visible to certain users. By default, iOS and Android install app updates without user approval. (You can and should, of course, disable that if you're concerned about such things.) The key difference is that app developers can't mount targeted attacks in this manner; only Apple and Google can.
3. Here's a simpler iteration on the author's idea for applying subresource integrity to service workers: an "immutable" variant of the https scheme that requires the lowest level of the domain to match a hash of all resources loaded on the page. JS is only enabled if the hash matches.
https+immutable://mhzwdnyyv5turofr8kkivabqyvamg7yteeitzwrg64o00taouw.signal.org
As far as I can tell, this mitigates the issues outlined by the author, and has the following nice properties:
- You can bookmark the URL and be certain that the code can't change in future.
- You can share the URL with someone else and be certain that they will be served the same code.
- Not affected by client-side state (e.g. cache) and thus can't be abused for fingerprinting.
- No risk of bricking the app in perpetuity.
- Thanks to Certificate Transparency, the existence of any published update is public knowledge.
This is explicitly called out.
Then how can you trust what the server sends you at all?! Infinitely worse than the situation described in the article!
My attacker must have been someone on the school network. They deleted a lot of things (it was purely destructive) but I saw in access logs that they were stumped by the admin panel which asked for the password again. I had entered my password of course, but the login form had client-side hashing. They can take my session token, but my password was safe. I used the password in other places as well, I think even for my email because I wanted both to be secure and it was a good password (my logic as a 16-year-old), but it was never compromised.
I did change it in case they could brute force the hash at some point (small chance), but client side hashing saved my ass from passive observers. Later, I was a passive observer myself with airmon-ng, exploring public WiFis (no malicious intent, though). Writing and injecting custom data into the traffic was beyond my skill level, as it seemed to have been for those schoolmates.
TLS makes a lot of things better, but on the need-to-know principle, I still feel like client-side password hashing has merit. The server never needs to know your password, it just needs to do a quick single round with secret pepper to disallow a pass the hash attack.
(I first used that specific phrasing a bit over a year ago, judging by HN search.)
A large part of why I call it snake oil is that it’s generally being sold as an inherent and unassailable virtue, when in actual fact it’s nowhere near as perfect as practitioners of it try to convince you (and most of their marketing claims are flat lies, though some do word things more precisely), and you make significant compromises in usability and functionality, which they don’t tell you about. From a convenience perspective, end-to-end encryption is simply dreadful and that’s all there is to it.
I wish we’d ended up with everyone hosting their own stuff instead, with completely decentralised infrastructure, which obviates extra end-to-end encryption (since transport plus storage encryption achieves just as much, and far more conveniently). But we haven’t, and there’s no realistic hope of ever ending up there with how we use tech now—it wouldn’t be particularly practical.
Yes, the first party can secretly undermine the end to end encryption for a single customer without alerting the customer. However, this would be exceedingly hard to do for an attacker (insider or outside) compared to there being no end to end encryption. You would need to have the first party on board with this which would be very illegal unless directed by a government. So you might still be vulnerable to state level attacks, but the company might be able to resist it by pointing to end to end security vs encrypting it self. It still strictly better than no end to end security where the government will request everything that was ever sent.
What is most odd is that you say that end to end encryption is not worth the convenience trade of but you think everyone hosting their own stuff would be better? This would be a disaster for both convenience and security. There zero chance that 99% of users would be able to securely self host their data. Even for the 1% that can and will secure their data, their data is likely also hosted in the other 99%. You just need to exploit the other side of the conversation and you are still screwed.
> It is worth noting that this law also applies to non-web applications where the service provider supposedly being secured against is also the client software distributor; thus, the “end-to-end encryption” offered by Whatsapp and Signal, amongst other proprietary services, is equally bogus.
On your web site, you could easily serve up different pages to different users. I think you'd have to distribute compromised copies of your app to everyone with an app store?
Or is there any evidence that app stores can deliver different versions for specific users?
(Unless there's a breaking change on the server side, but precisely because app updates are not guaranteed, app backends are much more conservative than web backends).
Controlling the updates for a web client might not be totally impossible but it's far, far more difficult and clumsy. Best case is it's a full SPA so you can just save the resources locally, but it's using classic server-side rendering with just a single chunk of client-side JS used for encryption... And of course there are no clearly announced and numbered releases, you need to keep refreshing the page to know when an update is deployed.
IOW, if you decide to stick w one version that is shown to be without a doubt E2EE then certainly you are better off than with just TLS.
Furthermore, this article only focusses on in-transit encryption (TLS). What about encryption at rest? It can perfectly be viable to have an E2EE service provider keep my data stored in zero-knowledge fashion.
Lastly, typically an E2EE service provider's reputation and business rests on keeping their word. There is not a whole lot of incentive to break it, given the jurisdiction they reside in allows them to refuse compliance w secret services.
IMO this is fear-mongering. At the very least equating even this supposed "snake oil" E2EE with mere TLS seems out of touch w reality.
I wonder if the auther himself personally too avoids E2EE messaging services.
- Customer-Managed Encryption Keys -- US cloud providers love to market this
- Confidential Commuting -- where the root of trust is either the same company (AWS) or a US processor manufacturer (Azure, Google).
If you need to manage the keys in to particular schedules or policies, it's obviously what you want. That might be more secure in some ways than leaving it to the cloud provider, depending on what you actually do with the capability. But many people just stop at CMEK Is More Secure...
1. All cryptographic keys controlled by the users.
2. Some way to confirm you are actually connected to who you think you are connected to.
3. A way to confirm that the code you are running is not leaking keys/content.
This rant covers a particular aspect of #3. E2EE is hard. It is too bad that the marketing is working overtime to convince us that it is not.
Even if the encryption itself is done using a 3rd party trusted library that is definitely kosher, the endpoint may have been compromised to leak whatever information to the public web.
Ergo there is no such thing as e2e encryption unless you have military level control over both ends of the pipe and the pipe itself.
Service providers are made up of employees, contractors, interns and temps. Given a pile of easily searchable user information one of these individuals working for the service provider is going to start poking around that pile of information for reasons not aligned with providing the service. (Boredom, compromise, love interests, personal activism, etc).
End to end encryption terminated on the client puts a powerful boundary between the individual user and the individuals working for the service provider. It makes your private data strictly safer.
The first was Hushmail.
The things is that “attackers gaining read access on a database” is (unfortunately) a much more common threat than “attacker can execute arbitrary code on the server instead of the application for a long time”.
Consider, for example, Signal's progenitor, TextSecure, or E2EE for RCS.
What's stopping a government from compelling these services to ship backdoored code and then compelling the telco to spill the now-vulnerable ciphertext — which doesn't also stop them from doing the same to modern Signal?
I would also argue that the FBI/Apple example is exactly that scenario — the code being distributed by a different entity (Apple) from which it purports to secure against (any party with physical access).
Once you have this, this means there now two nodes which need to be coerced to compromise the system - endpoint software provider and communications provider. Well, actually, just one - the endpoint software could just be changed to use a different, compromised communications provider (I think you were envisaging some more subtle compromise of ciphertext above).
This can be fixed, however. A lot of the work Linux distros have done around reproducible builds, and the new focus on release transparency, is informative here. You could absolutely have a FOSS project with a release process that requires multiparty signatures of releases with the release signers in different jurisdictions, and requiring proof of logging to a release transparency log, etc.
I suspect a lot of pushback on this is because the implications are significant, Emperor's New Clothes and all, but fixing this sort of thing is the first step to solving the problem. Pretty much the entire internet community was in a mindset of "but government wouldn't ever do..." complacency before Snowden, despite increasingly blatant warning signs, before people were forced to accept that reality. (The reason is simple; it's a funny thing about humans, when they realise some fact X being true would be very materially inconvenient to them, their first reaction is to argue that X isn't true, as though reality is negotiable...) Having an accurate view of just how impaired our security model is in this area is the first step to making things better IMO.
You're absolutely right that a lot of E2EE is fundamentally a "circle of protection against law", but that doesn't mean it isn't useful. The protection varies a lot depending on which law (jurisdiction) the threat has, after all.
Against a government entity, communications providers (telcos) can be considered already compromised, and represent approximately zero marginal resistance.
Even reproducible builds and audits only raise the bar, they can't solve the problem completely. I'm sure other comments are bringing up reflections on trusting trust, and the underhanded crypto contest has run a few times (I was a finalist).
I suppose my point is that security in real-world systems is never absolute, and always involves trade offs. Our goal should be to have better trade offs.
That's exactly what makes your entire argument silly: when you use a piece of software, you're trusting this piece of software, and there's no way around this, being web-based doesn't change a damn thing compared to any other software with automatic update.
Remember Crypto AG in Switzerland, owned by CIA. Chinese and Russians never bought Crypto AG secure phone systems.
I trust Metamask and 1Password and Meta with their claims of not sending my secret keys to their servers. Just take their word for it!
I trust Apple with their claims about the “secure enclave”
I trust Google with their claims about Chrome not “phoning home” all my keys
I trust Intel with their SGX extensions (and Signal does also)
I trust AWS with their KMS (“key management service”) and so does Magic crypto wallet etc. and even “the experts” like tptacek tell is “just use AWS”
If we ran the national elections electronically, then in theory, Google or Apple could defraud millions of voters into recording incorrect votes and help steal the election.
Our hardware is made by only a few companies. They could have put all kinds of backdoors.
I am not going to go so far as to say the NSA promoted weakened EC2 crypto curves, but I guess it’s possible
But in general, everyone has a Trusted Computing Base:
https://en.m.wikipedia.org/wiki/Trusted_computing_base
Which is why I don’t want to rely on individual devices for security. I prefer a blockchain and having multiple devices secure data.
In a previous life, the killer app for E2E was "encrypted email" where a lot of companies would claim they do email encryption by having outside recipients visit a website for which the recipient would get a password by SMS in order to read the email sent. And because the website was hosted by the sender on HTTPS... voila, encrypted email. And the sales people from this companies all kept a straight face when explaining how secure the encryption was.
To be E2E, the file should only be decryptable by the sender and receiver. The point in the middle should not be able to see it's plaintext or decrypt its ciphertext.
There is still tremendous value in being protected from absolutely everyone else.
What I am saying is that people tend to slap the E2E label on pretty much anything without understanding what it really means.