Re: [slightlyoff/ServiceWorker] Preventing server-forced updates (#822)

I resonate with this use-case (I worked on the Firefox OS mail app which similarly wanted what amounted to signed-offline app packages), but I think giving the service-worker the ability to defeat upgrades of itself is the wrong way to handle it.  (And I think this issue is roughly equivalent to 761, although this issue more concretely describes motivating use-cases.)

The security model of https is trust in an origin, authenticated by the certificate authority (CA) infrastructure, with compromises being handled via OCSP (stapling) and/or short-lived certificates.  Using a trust-on-first-use service worker that can deny upgrades is a clever way to attempt to embed an offline signature based security/trust model inside the existing online signature trust model.  Some people have even come up with an exceedingly clever approach also combining HPKP and AppCache, see https://www.reddit.com/r/encryption/comments/4027ci/how_2_spacex_alums_are_using_encryption_for_good/cyywmc8

The major risk of a prevent-update feature, as covered by Jake, in #761 is allowing an evil/attacker-controlled service worker to extend the duration of its nefarious residency, potentially permanently.  And also as Jake suggests, it seems better to make the validation part of a standard already concerned with validating contents, namely CSP which already has precedent with its SRI-like "valid hash" mechanism https://w3c.github.io/webappsec-csp/2/#source-list-valid-hashes.  This also allows the browser to alert the user, helping avoid spoofable UI and related confusion/fatigue.

Additionally:
* There are potential interactions such as shift+reload bypassing service-workers, among others.  It's a lot to ask a complex spec like service-workers to adopt a fundamentally divergent use-case that in many cases is indistinguishable from an attacker's dream and a developer-who-makes-typos' nightmare.
* Preventing updates is a shallow security model on its own.  The origin is being defended exclusively by the service worker intercepting all requests and maintaining itself intact.  If an attacker does gain control of the origin and can cause the service worker to fail to respondWith or is bypassed via some other bug or new feature (like a bypass header), they have access to all of your app's local storage at the origin.  What you really want is your own distinct origin with its own storage bucket that is affirmatively guarded by verifying a signature before letting any code/document run in the origin.  Gecko has internal support for such things hung off an existing origin using OriginAttributes, or just if a separate scheme and thereby origin is created like "signed-package://KEY", etc.  This would have been surfaced by the now-defunct Firefox OS "new security model" at https://wiki.mozilla.org/FirefoxOS/New_security_model#Verifying_signatures_-_bug_1153422 and is otherwise
  not som
 ething web content can currently avail itself of.

The big wrinkle is that what is really needed is a cross-browser effort with this specific use-case in mind because it really is its own big picture idea.  I believe there are many people who care about the use-case, but I suspect most browser engines are focusing their efforts just on getting service workers and progressive web apps going.  The best hope for this use-case right now are browser extensions/add-ons.  All browsers seem to be converging on WebExtensions and at least some browsers (ex: Firefox) allow easy disabling of extension auto-updates.  Which is important since the trust-model looks like it depends on the extensions marketplaces' authentication mechanisms and them not being compromised themselves, which is strictly weaker than an air-gapped private key.  (NB: Pre-WebExtensions Firefox extensions can, however, be cryptographically signed.)  This is clearly nowhere as good as a packaged apps model that does not require installation like Firefox OS was shooting
  for, bu
 t it seems to be the most realistic cross-browser solution.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/822#issuecomment-224373991