Serviceworker: What to do when an installed service worker's certificate changes/expires

[mfalken]

What happens when on an update check, the service worker's certificate has expired or changed?

Currently Chrome doesn't update the certificate, and the certificate is used to populate the certificate info in the omnibox. So when you visit the site and click the padlock, you see the old certificate.

Proposal:

• If the new certificate is invalid/expired, update aborts as if it got a network error. No uninstallation etc.
• If the byte-to-byte comparison is the same, update aborts. However, we'll replace the certificate info of the existing service worker with the new certificate info.
• If the byte-to-byte comparison is the different, the update check goes on normally. The new service worker will have the new certificate info. The incumbent service worker will go on using the old certificate until it is evicted. (Which means if the update fails due to syntax error etc, we continue using the old cert until update succeeds or byte-to-byte is the same.)

Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1103551

[jakearchibald]

I think there are two issues here that we should address separately:

Does cert expiry impact cached things?

Certificates are a connection-level thing, not a resource-level thing. If you received the resource securely, you still received that resource securely even once the certificate expires. Certificate 'revocation' could mean that resource was sent over a connection that wasn't 'correctly' secure, but at that point the 'bad' data may have influenced browser storage, so if something needs to happen, it probably involves clearing site storage. It's certainly bigger than a service worker issue.

How should the browser communicate security to the user?

https://static-misc-2.glitch.me/basic-sw/ - here's a page that serves content from a service worker, without needing a network connection.

Firefox & Chrome show a padlock and "The connection is secure", which is kinda misleading because there is no connection. (cc @asutherland)

Safari does not show a padlock, but it doesn't show "not secure". This might be risky if users associate the presence of the padlock as "this is secure", and the absence of it as a red flag (cc @youennf)

It feels like we should have a padlock for resources that we know were originally served securely (HTTP cache), or was generated by a resource that was originally served securely (service worker), but a connection wasn't needed in this particular instance. Clicking on the padlock could show "this resource was served without a connection".

But hey, I'm not a security expert. @sleevi @jyasskin does the above sound reasonable?

[youennf]

Safari recently changed its policy on that topic, this should go in STP soon:

• If the service worker is serving a resource that does not contain a certificate info, for navigation, we use the certificate info retrieved as part of the service worker script fetch.
• If the certificate info changes when soft-updating the service worker script, we treat it as if the service worker script changes.

[jakearchibald]

we treat it as if the service worker script changes.

As it, it becomes a new installing worker?

[youennf]

we treat it as if the service worker script changes.

As it, it becomes a new installing worker?

Right, we might change this to updating the certificate info of the running service worker (plus updating the persistent storage of the registration) but this is not implemented yet.

[jakearchibald]

we might change this to updating the certificate info of the running service worker

That's what Chrome does fwiw

[jakearchibald]

@youennf any idea what Safari does when it brings the page out of the HTTP cache?

[youennf]

For navigation loads, we require an HTTP cache entry with certificate info. If there is no certificate info, the cache entry is not used directly (unsure about revalidation).

[sleevi]

@estark37 would be better placed to talk about strings and “resource” vs “connection“
@davidben as FYI

[davidben]

Is "certificate info" actually a notion in the spec? As far as I'm aware, the only platform-visible aspect of server certificates is whether it was accepted or not.

Of course, most browsers have some kind of UI to show a tab's "certificate", which needs to return something for SWs, cached resources, and the like, so it is worth thinking about this anyway. But since web pages incorporate many resources, potentially fetched over different connections with layers and layers of caching, that UI was always more of an approximation anyway.

[jakearchibald]

Is "certificate info" actually a notion in the spec?

Nah. We'd only need to change the spec if it caused items to expire, but it seems like we don't want that behaviour. But it's fine to discuss the UI issues here too – it impacts all browsers.