E2EE on the web: is the web that bad?
emilymstark.com
emilymstark.com
I would trust an audited, Chrome-or-Firefox-store distributed browser extension to implement end-to-end encryption. I don't think that extends to UI elements injected into the page itself though—the UI elements where you're typing your messages have to be separate from the rest of the page to prevent malicious web apps from overwriting them and capturing your input before sending it on to the extension themselves.
Except for the desktop applications that simply pop up a web view to load the web site from the internet.
(Looks at Discord, Slack, Zoom)
Not all Electron apps are this way, for example LM Studio stores its interface locally and therefore doesn't rely on loading it from a remote server at application start time. But a surprising number of them are.
It would also be difficult for said professionals to detect IP-(range)-specific backdoors (with as much obfuscation as you like; only send on Tuesdays; encrypted using a string constant elsewhere in the binary), in App Store delivered binaries that are harder to vary per downloader.
Some web apps - [Cryptee](https://crypt.ee/threat-model) is a notable example - address this with a "trust on first use" approach, that makes any change to the (web) code require approval, but that's in the same realm as a desktop app, where you've trusted it on the first download, and trust it to have actually followed through on that promise.
It’s not as reasonable for the layman to do this on the web, since it’s par for the course for a single visit to a big commercial website to kick off connections to dozens of unintelligible domains, and to sometimes break if these connections aren’t allowed. OS-level tools like LuLu aren’t of much help here because significant limitations on the servers a browser can connect to essentially break the browser, which leaves you with extensions like NoScript and uMatrix which for the explained reasons aren’t as straightforward to operate.
[0]: https://objective-see.org/products/lulu.html [1]: https://github.com/evilsocket/opensnitch
If that's genuinely part of your threat model, then you simply must run on-premises code only, backed up by robust network controls that allowlist very specific parts of the Internet.
Any platform where the security model is two steps:
1. Check if the message contains any code. If so, reject it. 2. Scan the message for code and eval() it.
is extremely susceptible to code execution bugs.
That said, this project could be extended with something like a public certificate transparency log showing which versions of the code have been signed and making the code associated with each signed version available for third-party inspection, which would help plug this loophole. I haven't seen any proposals for how to do that with web standards yet, but I expect that some people have thought of a few of them. While it would be very different from the web we have today (no dynamic server-side templates, only APIs!), I think it would be a welcome innovation for web security
This feels like the wrong argument. I don't think this has anything to do with suitability of end to end encryption. It is easily worked around with e.g. subresource integrity, or rolling your own signing scheme.
The real problem with end to end security on the web is you don't have a trusted base. You have to bootstrap your application with some sort of trusted base. On a website you are redownloading the website everytime.
The entire point of end to end encryption is that the service provider should not be able to intercept messages. The service provider is the attacker. This is impossible to prevent if you redownload the app everytime you open the page†. You have to build trust from some starting point. If you have some trusted bootstrap code you can build from there with signatures, but you can't build trust out of thin air running code directly supplied by the party you are trying to protect against.
The problem isn't the zillion TLS servers. The problem is the first TLS server, which in the e2ee threat model we have to assume is evil.
† i guess service workers can extend that to once every 24 hours. Still not super compelling.
You can have a personal startpage saved on your device's local storage, with an SRI link to a webapp, but that takes a bit of fiddling.
E2EE: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
I dont think that is true. Its called subresource integrity not resource integrity. I don't think pinning a specific top level resource was ever part of the goal.
> but the W3C managed to not let SRI work on bookmarks. If you could bookmark a specific version of a url with SRI, that would make so many problems go away.
I don't really think this makes sense in the context of how web browsers currently work. Are you proposing that users just unilateraly pin versions of websites?
It won't work "unilaterally" for obvious reasons but there are lots of p2p, e2e, security and crypto type apps where creators would love to be able to reduce the degree to which infra like CDNs and hosting need to be trusted.
The "page level SRI" mechanism wouldn't even need to work that well (eg limited support for web features). If you could get a trusted "bootstrapper" to work with no software installation then you could do the rest of the trust chain in js "userland".
If we are moving out of the http/web space into some sort of distributed protocol, just use magnet links, problem solved. Or some equivalant hash based content-addresable scheme. (How applicable depends on what space we are talking about)
What many people want is the convenience of http/web with the immutability of content addressing and the frustration of OP at the start of our thread is that SRI feels so close to being able to provide that but stops short.
This has been a really interesting discussion for me because I think you understand the use cases and alternatives but it seems like you don't agree that hash pinned / immutable web sites natively in the browser would enable many interesting use cases.
[just unilateraly pin versions of websites?] - If the other website is advertising itself as 'not supposed to change', then yes, this is a way of confirming that it has not changed.
Or even simpler, use the data: URI for the initial page as a bookmark.
Of course then you are starting from a null origin, which makes certain traditional web architecture things hard. Maybe that doesn't matter if you design for it from the get-go. Too bad <iframe> doesn't support integrity. I guess you also sacrafice features that require a secure origin with this method.
Or, you know, not loading resources from third parties in your secure web application.
" Why Bloat Is Still Software’s Biggest Vulnerability > A 2024 plea for lean software "
The problem involves so many dependencies that it is impossible for an individual and maybe even megacorporations to fully audit the code base and prove the software behaves as intended. Everything these days is best effort.
We _need_ a native interface that portable software can target, to at LEAST get to the level where 'If you trust the OS, then the rest of the software is known to behave as expected' is a statement that can be made to have a plausibly secure environment for End to End Encryption on anything.
This __has__ to ship, in a DEFAULT install of Windows AND OSX AND mobile computing devices (so iOS and Android too). It absolutely has to be a baseline target, otherwise we'll never get past shipping the browser, again, out of band as yet another thing that must have it's entire monstrosity of libraries updated for every security patch.
Libtorrent is a shining example of this architecture. It runs everywhere, even on mobile platforms. Rust being more popular with makes this even more accessible than it used to be. There's even libraries like PyO3 to make writing bindings to other languages easier.
Everything has always been best effort, there was no point in time that formally verified software was mainstream. Even attempts at that have turned out broken later on (e.g. KRACK attack on wpa2) so its not a pancea.
> We _need_ a native interface that portable software can target, to at LEAST get to the level where 'If you trust the OS, then the rest of the software is known to behave as expected' is a statement that can be made to have a plausibly secure environment for End to End Encryption on anything.
This doesn't really make sense unless this portable interface contains the entire App. Like how do you imagine such a system would work? What would such an interface do or contain that would bring this dream even remotely close to reality?
In what ways was wpa2 an attempt at formally verified software? The KRACK attack exploited an issue in the standard itself. Were notable implementations of it formally verified? Was the spec itself verified in some flawed ways? I read the Wikipedia page and couldn't find anything relevant.
Essentially the spec was formally verified, but it turned out that the formal definition of "secure" they used wasn't sufficient. Formal verification only works if you properly define all the security relavent properties that need to be proven, and the process of defining them can have errors itself.
1. You need to securely get the code and resources to the browser. A state level attacker can make this very hard.
2. You need to securely run the code on the client which may or may not include code from n-third parties.
3. You need to securely handle data and logic from the client which may or may not involve n-third parties.
Phew. That's a heck of a challenge.
Even worse, you need to securely get code to the browser without trusting yourself. The E2EE model assumes that you (the service provider/app maker) will turn evil at some future point.
Code distribution is hard enough if you can trust yourself. Its basically impossible if the threat you are protecting against is your future self.
Incidentally, I've actually just recently developed a solution to this exact problem: https://www.websign.app.
WebSign started a while back as an internal framework used by the Cyph E2EE messenger (https://www.cyph.com), and @eganist and I gave a talk that covered part of the TOFU architecture at Black Hat and DEF CON. Now there's a static web hosting service built around it for others to use, which takes care of bundling and code signing during deployment.
If anyone here has a use case for it, we're looking for pilot customers now. Just shoot me an email at ryan@cyph.com.
To be clear, what you quoted is an idea that has been requested by some potential customers — essentially decentralized and distributed code review/signing. It's not a feature of the current product, and likely won't be until someone pays for it, although I do think it would be cool.
Either way, it's not something that would detract from the fundamental value proposition. It would be an optional add-on.
Although it's all open source, if you install the published version of their extension, iiuc, it will only work with certain facebook sites out of the box. There should be an easier way to enroll new sites - I'm thinking TOFU with fingerprinting.
https://www.computerworld.com/article/3712380/russia-hacks-m...
After all, they could easily serve up slightly different js when you log into their website; for all practical purposes it would be undetectable.
Being reasonably confident that you're running the same code as everyone else seems pretty important to me - and that's not how the web works.
Which is why people say E2EE is unsuitable to the browser.
Sure there exists other threats and other security issues in the browser, many of which can be addressed by various means, but that is a different thing than E2EE.
I guess the separation into CDN and non-CDN stuff could still make sense since you can serve static resources from even closer to the user than you serve your dynamic stuff while avoiding having the CDN proxy traffic to the website backend.
- Extensions are signed with a developer key
- You can be pretty sure any code changes pushed out to one user are pushed out to everyone
- You benefit from the Chrome Web Store review process (or whatever equivalent Apple and Mozilla do)
- Extensions are permissioned and sandboxed
I like that idea.
As if browsers (arguably the most attacked desktop applications) are not wriiten in C++.
kinda starts to point towards a move from traditional www domain/location security semantics to abstract identity based approaches.