1386358 - A site served from a service worker cache doesn't revalidate its TLS certificate validity

Status: RESOLVED INVALID

(Core :: DOM: Service Workers, enhancement, P3)

Description

[(no longer active)]

Today the cert for https://perf-html.io/ expired, which resulted in an interesting situation which I don't know exactly how we are supposed to handle.  Here is the scenario:

1. User goes to https://perf-html.io/ on July 25.
2. Site serves them a SW which caches the site with a TLS cert valid until Aug 1.
3. User visits the site on Aug 1.

If the site is served from the SW cache, we get no cert expiry page.  If the site is served from the network (for example by pressing Ctrl+Shift+R to bypass the SW) you'll get a cert expired error.

What is the right behavior here?

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

I asked about this when our security_info stuff was added to Cache API and service worker.  The answer I got then was the cert validation was part of the TLS handshake and its not appropriate to perform it again at higher layers in the stack.  If we don't trigger a network connection then there is no TLS handshake and therefore no cert validation.

I believe I was also told we don't revalidate certs coming out of http cache either.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

And the fetch spec only mentions validating certs when you obtain the TLS connection:

  Step 2: https://fetch.spec.whatwg.org/#http-network-fetch
  Step 2: https://fetch.spec.whatwg.org/#concept-connection-obtain
  https://tools.ietf.org/html/rfc5246

If you think we should be revalidating you need to open a spec issue, because I'm fairly certain chrome does not revalidate either.

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

This also presents a UI issue. Currently if I inspect the certificate from https://perf-html.io with the "More Information" dialog it will show "Expires: August 1, 2017" but still shows a green lock.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #3)
> This also presents a UI issue. Currently if I inspect the certificate from
> https://perf-html.io with the "More Information" dialog it will show
> "Expires: August 1, 2017" but still shows a green lock.

I think this is even correct to a degree.  The cert passed when we talked to the server, so we show the green lock.  If we make a change there I would do something like add a "last validated on: July 24, 2017" entry or something.

Also, I think this is the same behavior we have if you use "offline mode" to read sites out of http cache without revalidating against the server.

Comment 5

[(no longer active)]

One thing that I forgot to mention was that I *did* test Chrome and it indeed also doesn't revalidate the certificate.  So perhaps this is WFM?

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

I'm going to mark as invalid since we are doing what the fetch and SW specs require today.  If anyone wants to change this please open a spec issue.