These concepts are interesting:

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.

Isn't that just SRI in a bookmarklet? With SRI you give the browser a hash and if the resource does not match it does not load.

Doesn't SRI require the hashes to be in the __loaded__ html? I believe parent is referring to a page which is the same, but has been compromised on the server side, meaning you can't trust the html, even if the server is who it says it is.

Right, but what I'm saying is that you don't need the loader. Just have a bookmarklet with html that contains script tags with SRI. The loader is just another step you need to trust.

That does indeed work. Pretty neat. For anyone trying, here is basically all you need:

  data:text/html,<script crossorigin="anonymous" integrity="..." src="...">

In total that should be a lot smaller than the linked codegolf answer.

Oooh, that's very cool. Thanks for the links.

You might also like substack’s work on hyperboot.

if you send the datauri by email (webmail) and use it from there someone with phisical access to the computer wont be able to change it easily.

This (rightfully) comes up every time some browser-based encryption tool is posted. It seems like the desire for such tools isn’t going to go away. Is anyone working on solutions for making distribution of JavaScript applications more secure?

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).

> 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).

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.

Have a look at https://w3c.github.io/webappsec-subresource-integrity/

That’s a start, but if the main resource (the HTML page) can be modified it doesn’t help.

If you could require the root page be cryptographically signed (but by who?) and optionally prompted for updates then we’re talking.

This was "solved" by a online crypto tool (can't remember which) that basically did HPKP suicide every 30 minutes and had a service worker that loaded cached assets on failure. So the browser would pin to a key that was deleted within minutes and then all subsequent requests would only go through the service worker until the pin expired.

cyph.com

Thanks!

It's worth noting that Cyph came up in an earlier discussion about HPKP being removed from Chrome:

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).

We (Cyph) have been pretty disappointed in the Chrome team's decision to kill HPKP.

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.

There was a site posted on HN a while back that had an interesting take on a solution to this: they had a service-worker that checked github.com for the latest version of the app code and itself (along with the standard subresource integrity of course). That description doesn't do the system justice, as to my memory it seemed like a pretty sound system as long as your public repo remains uncompromised.

Unfortunately can't remember the name of the website nor exactly what it did...

Was it this one? https://github.com/airbornio/signed-web-apps

Nope, it wasn't a library, this was a SaaS website running an open source codebase that was browsable on GitHub.

Well, it might have been Airborn.io, the Google Docs competitor that this library grew out of.

I was definitely asleep at the keyboard as it definitely was airborn.io. Thanks.

Don't shoot the messenger here, but isn't this a case for blockchain technology? You sign and make the JS public and it can't be changed?

I believe this sort of thing will be possible via the [Web Package Standard][1]

[1]: https://github.com/WICG/webpackage

A browser add-on that is manually installed (which I believe would stop any potential insecure/unintended automatic update) could check a digital signature embedded in a formatted comment inside the JS file. That is relatively easy to implement, but you will also want some sort of PKI for key distribution and revocation.

Let the uri be the signature?

The idea came to my mind that people could create websites on domains of the form [some SHA hash].example.com and reference from the root HTML page a file with the name [the same SHA hash].js and this could trigger a special mode in the browser where it checked that the JavaScript file hashed to the given value, and then refused to load any other scripts.

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.

The same can be said for any software that auto update (i.e. Chrome), no?

Attack vectors for replacing Chrome:

  - Hack Google

Attack vectors for replacing OpenPGPjs:

  - Hack the servers hosting OpenPGPjs
  - Hack the browser to inject or replace content across domains, sandboxes, other security barriers

It's a subtle difference, but delivering applications dynamically via web browsing is much more precarious than natively hosted applications.

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.

You don't have to hack google to replace chrome. You just have to hack a trusted cert provider and DNS and/or BGP. Those two things are not unheard of.

They're using key pinning, so you would have to use one of Google's keys and use one of Google's authorized CAs. But second, I imagine the auto-update process is using a non-TLS certificate to verify the signed binaries. Either way you have to hack Google.

It would actually be much easier to just find a vuln in Chrome that can break out of sandbox and get root.

Or hack the team who signs.

So Chrome doesn't use certificate pinning for distributing updates?

> Attack vectors for replacing Chrome:

> - Hack Google

  - NSL Google

(If you're a high-enough value target and your adversary is the US Government. But in _that_ case you've probably already lost - you might just not know it yet. I wonder if Snowden uses Chrome or lets it autoupdate?)

That's a good question. I don't think the government cares enough about snowden to do that. Snowden's damage has been done. It can't be reversed. Imo, they'd be much more interested to preemptively shutdown all future would-be Snowdens.

That depends.

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.

Yes.

No. The risk is much lower, especially if different entities (upstream, linux distributions, ...) review the same code.

Remember when Hushmail backdoored their client-side applet to capture unencrypted emails and passwords?

It appears they were actually just hosting a web app and users were sending their decryption password to Hushmail. I don't see a reference to backdooring the Java client, though obviously since they delivered it, they could do that too. https://www.wired.com/2007/11/encrypted-e-mai/

I remember when Lavabit didn't...

Back in the days when I was 15-16 I added a simple system() call in PGP to send the plaintext message out via sendmail before encrypting it as an experiment on my local system, and was surprised that a one line change would completely compromise the system. I remember telling Phil Zimmerman this at a conference I think he said something like "well, that is a real asshole move". There's nothing to prevent all of these "create secure password checkers" from sending out JSON requests your plaintext password as well. Furthermore, you can send fake "invalid password" messages and trick a user into typing all of his old passwords and permutations while he/she tries to "remember" the right password. One of my first root exploit for OpenBSD was taking over the console, killing login, and presenting a fake login prompt that pipe'd its output to a real one.

isn't this why https://developer.mozilla.org/en-US/docs/Web/Security/Subres... was invented?

No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes.

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?

> No, because the provider would be in the position to change the SRI hashes. Sub Resource Integrity protects you against malicious CDNs and so on, but needs a non-compromised HTML page to provide correct hashes.

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)?

Not if the originating site is the potential attacker, which was the initial scenario: Protonmail sending you page that leaks your decrypted mail to them.

There was a way to make a permanent site installation on most browsers using HTML5 appcache, which even the web host couldn't update, but that API is deprecated in favor of the service worker's Cache API.

It's not clear to me that the Cache API offers the same level of security guarantee.

> 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.

If you can change out the JS payload, you can probably also swap out the HTML which supposedly "secures" it.

If the users had the option of "locking" a JS version with the Subresource Integrity attribute that they are currently using, it might help.

Wouldn't you also need to lock down all the UI code and everything that interacts with the library?

This solves a different problem. Say actor A makes a website and uses CDNs provided by actor B. This protects users from actor B changing their scripts, but not from a malicious actor A. In this case I'm presuming ProtonMail is actor A.

I don't know if Protonmail do this or not, but presumably you could supply the javascript part of your web application as a browser plugin, which would render it immune to attacks on the server.

Hopefully web packages⁽¹⁾ can eventually solve this issue.

1. https://github.com/WICG/webpackage

Do either IPFS or DAT/BeakerBrowser solve this problem?

(They are both protocols for distributed web apps based on immutable content.)

A little, although it involves running your own ipfs node, something precisely 0% (rounded) of web users are going to do.

How would you implement a secure webmail such that it satisfies your complaint?

...not to mention the huge attack surface of browsers in general.

And also how the same application you are using to encrypt your mail is also running javascript from random sources when you browse websites.

...and why all the downvotes? Interestingly, if I write from other accounts I don't get all this downvoting.

The readme indicates that it can be installed via npm, so I'm not sure what your concern is.

https://github.com/openpgpjs/openpgpjs/blob/master/README.md

That doesn't have anything to do with what I said.

To be fair, what you said is only tangentially related to the posted article anyway. It is about a security audit of the OpenPGPjs library (what bastawhiz commented about), not how ProtonMail implements it (what you commented about).