And to preempt the ProtonMail rep who is probably going to respond to this comment, I know that you can run the web app on localhost. But that doesn't mean that users who don't are any more secure.
https://codegolf.stackexchange.com/questions/18217/javascrip...
https://bitbucket.org/geraintluff/caution.js/
The idea is that a long data-uri containing hashes and a small loader function are bookmarked. The loader won't load the corresponding javascript unless the hashes match. The user only needs to verify the javascript once, then they can rely on their bookmark containing the hashes. If the server were to swap out the javascript, the bookmark would fail to load it.
data:text/html,<script crossorigin="anonymous" integrity="..." src="...">
There’s a range of assurances you could try to provide, e.x. signatures from the author (or even 3rd parties), prompting for updates, etc. It would likely require support from browsers.
At one point I investigated using service workers to intercept subsequent app updates to check signatures but there was no way to prevent the service worker itself from being replaced (probably because it would be easy for a site to permanently “brick” itself in users browssr).
If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.
The bootstrap JavaScript file could contain the code needed to download more files, and to download a digitally signed list of file hashes, which it could check against a hardcoded public key. Also the browser would have to remember a flag for that domain to require this same bootstrapping process every time, to stop downgrade attacks.
Unfortunately can't remember the name of the website nor exactly what it did...
https://news.ycombinator.com/item?id=15572888
As far as I'm aware that means their approach no longer works (across browsers), and, though it was a fantastic idea, it did require you to trust that they really were throwing their keys away (a trust model slightly weaker than TOFU).
Paraphrasing, but IIRC the reasoning pretty much boiled down to "it's a pain to maintain and Expect-CT is kind of similar anyway" — which I think is a really weak justification for harming end user security and breaking established APIs that people depend on in production. Fingers crossed that Firefox keeps it alive!
That said, it doesn't entirely break WebSign in Chrome, just weakens a bit further below strict TOFU. https://www.cyph.com/websign goes into detail, but WebSign has some client-side logic to validate its own hash against a signed whitelist. The major downsides to relying on this are:
1. It depends on a caching layer, not a security feature. This means that any guarantees are potentially out the window if a browser vendor decides to do something crazy for performance reasons or whatever.
2. It opens up an attack vector where it can be forcibly unpinned by filling up the user's disk and making the browser evict the cached WebSign instance.
All in all I think it's still basically fine, but shipping an optional browser extension for hardening WebSign is now a higher priority because of this.
Cyph nailed this back with appcaches, later migrating to service workers (and ultimately got a patent for the solution), but the implementation of the solution itself got an entire protocol canned by one browser (HPKP).
Source: did the talk on it.
1. Most platforms these days require a signature with a key issued by the platform. In the browser you have HTTPS but that doesn’t help if the server is compromised.
2. It’s easier to target individuals (thus evading detection) if you’re serving the code to users directly (which I think is also the case with Chrome, but not Mac App Store, Linux package managers, etc)
3. Some platforms even do some amount of auditing before including software in their repositories.
- Hack Google
- Hack the servers hosting OpenPGPjs
- Hack the browser to inject or replace content across domains, sandboxes, other security barriers
Another way to think of it is if your entire Linux OS were actually just web apps with GUIs. Every time you run 'bash', it was actually downloaded from a remote server. And every time you used bash, and it used some plug-in which was hosted on some other site, that plug-in could be compromised, and could be trying to attack your OS, which if successful, would compromise your entire host.
That doesn't happen right now because all the apps sit on your host, aren't constantly re-acquired, aren't constantly subject to potential 3rd party attacks over a wide surface area. Though this does sort-of happen with programming language package managers like npm, pip and so on. But you can pin those versions and hashes if you're paranoid, which I don't think you can do with a browser.
It would actually be much easier to just find a vuln in Chrome that can break out of sandbox and get root.
> - Hack Google
- NSL Google
If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.
You could however probably provide a signed entry point via a webextension or so and a an audit trail via a trusted distribution plattform, like addons.mozilla.org. Are there apps which use a mechanism like this?
It's not clear to me that the Cache API offers the same level of security guarantee.
Last I checked it seemed there wasn’t any way to prevent the service worker itself from being updated.
Can you not trust the originating site to serve non-compromised HTML if using HSTS and a trusted local certificate store (eliminating MITM as an attack vector)?
(They are both protocols for distributed web apps based on immutable content.)
And also how the same application you are using to encrypt your mail is also running javascript from random sources when you browse websites.
https://github.com/openpgpjs/openpgpjs/blob/master/README.md