Bug 196182 – Using Application Cache on HTTPS websites breaks browser security indicators (e.g. webkit_web_view_get_tls_info()); CertificateInfo not properly cached

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebCore Misc.

[Malcolm Lalkaka]

Hello, it seems that when a web page specifies an Application Cache (using the manifest attribute on its html tag), WebKit-based browsers do not consistently display the web page's HTTPS certificate. 

I first found this bug while using Epiphany (you can see the original bug report and investigation at https://gitlab.gnome.org/GNOME/epiphany/issues/604). With Michael Catanzaro's help, I was able to narrow down the issue to websites using Application Cache and HTTPS, viewed on WebKit-based browsers.

To make reproducing this bug much easier, I created a simple website that consistently demonstrates the issue: https://mlalkaka.github.io/https-app-cache-bug.html. 

Steps to Reproduce:

1. Navigate to https://mlalkaka.github.io/https-app-cache-bug.html.
2. Verify that the lock icon appears, and that you can actually view the web page's HTTPS 3. certificate.
4. Close the web browser.
5. Open the web browser again.
6. Navigate to https://mlalkaka.github.io/https-app-cache-bug.html again.

Actual Result:

In Epiphany (on Linux), the HTTPS lock icon displays a warning claiming the site is insecure, and you cannot see the HTTPS certificate.

In Safari (on MacOS), the HTTPS lock icon displays as normal, but clicking the icon does not display the HTTPS certificate.

In Google Chrome (on Linux and MacOS, but not on Windows), the HTTPS lock icon converts to the 'info' icon, claims the site is not secure, but it does not explain why, and you cannot see the certificate anymore. I know that Google Chrome technically does not use WebKit anymore, but I thought it was a useful comparison.

Expected Result:

The HTTPS lock icon appears again, and you can still view the HTTPS certificate.

---

This bug may exist when using Service Workers as well; I haven't had a chance to test that yet.

Also, it looks like a similar bug was reported (but only for Safari) back in 2013: https://bugs.webkit.org/show_bug.cgi?id=120513. It looks like that one was more specific to Safari only, and hasn't been touched in six years, so I thought it best to create a more detailed bug report, and one that covers multiple platforms.

[Michael Catanzaro]

*** Bug 120513 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

I'm no expert on ApplicationCache, but I bet the CertificateInfo is not being saved in the cache (required to do caching properly).

Fun fact: our favicon cache has the same bug, bug #142340.

[Michael Catanzaro]

There's also bug #142340, which I'd forgotten about. That seems the most serious of all.

All these caches are completely different, so they do require three different bugs.

[Alexey Proskuryakov]

This is sort of correct behavior. Local cache cannot be trusted in the same ways as the origin server, and EV requirements in particular make online verification a must IIRC.

The exposure is not universal - mostly limited to revoked certificates I think - but real.

[Michael Catanzaro]

(In reply to Alexey Proskuryakov from comment #4)
> Local cache cannot be trusted in the same
> ways as the origin server

Why not? If WebKit caches aren't trusted, then we have a big problem!

I don't think we need to store trust decisions in the cache, anyway. If we just encode the CertificateInfo into the cache using the existing WTF::Persistence coders, then the certificate's trust can be evaluated at runtime.

[Alexey Proskuryakov]

> Why not? If WebKit caches aren't trusted, then we have a big problem!

Locally running malware can modify appcache, but it can't change the content of webpages.

So yes, the user has a big problem in this scenario, but we shouldn't make it bigger by letting the attacker poison the cache for https pages, and especially EV.

> I don't think we need to store trust decisions in the cache, anyway. If we
> just encode the CertificateInfo into the cache using the existing
> WTF::Persistence coders, then the certificate's trust can be evaluated at
> runtime.

With network access, which is not OK for appcache served pages.

I do agree that there is a problem here, but I think that the solution to it is not using appcache.

[Michael Catanzaro]

(In reply to Alexey Proskuryakov from comment #6)
> > Why not? If WebKit caches aren't trusted, then we have a big problem!
> 
> Locally running malware can modify appcache, but it can't change the content
> of webpages.

Sure it can... with an unprivileged user account compromise, it could replace resources in disk cache, or install a malicious desktop file to launch a malicious copy of the browser that can do whatever evil things it wants. Or with a privileged account compromise, it could modify /etc/hosts to ensure trusted names resolve to malicious servers, or outright replace the WebKit library on disk with a malicious one.

So I think the cache must be trusted, at least to the same degree as the website (security origin) that stored content there.

> > I don't think we need to store trust decisions in the cache, anyway. If we
> > just encode the CertificateInfo into the cache using the existing
> > WTF::Persistence coders, then the certificate's trust can be evaluated at
> > runtime.
> 
> With network access, which is not OK for appcache served pages.

To download a CRL, or do an OCSP lookup, or if a server is misconfigured and an intermediate cert is missing and needs to be downloaded via AuthorityInformationAccess, then yes network access is needed in those cases. But in general, certificate verification is usually done offline.

It's a good point, though. I wonder if anyone has actually thought through how the browser security indicator is actually supposed to work with appcache. Maybe not, if Chrome, Safari, and Epiphany all have similar problems here.

> I do agree that there is a problem here, but I think that the solution to it
> is not using appcache.

Well think of the user-visible bug here. User visits website and sees a secure lock icon that pops up an icon indicating "Your connection seems to be secure." The user refreshes the page and it changes to a broken lock "This website has no security." That's no good... right?

appcache is deprecated, so perhaps we can tell browser developers it's a misfeature and they should not use it unless they want to trigger browser security warnings. Still, not great.

How do service workers handle this?

[Radar WebKit Bug Importer]

<rdar://problem/58642560>

[Michael Catanzaro]

If anyone wants to test service workers to see what the behavior is there, that would be interesting.

(In reply to Michael Catanzaro from comment #3)
> There's also bug #142340, which I'd forgotten about. That seems the most
> serious of all.

That's the same bug as in my previous comment. I think I meant bug #138127.

(In reply to Alexey Proskuryakov from comment #6)
> > Why not? If WebKit caches aren't trusted, then we have a big problem!
> 
> Locally running malware can modify appcache, but it can't change the content
> of webpages.
> 
> So yes, the user has a big problem in this scenario, but we shouldn't make
> it bigger by letting the attacker poison the cache for https pages, and
> especially EV.

EV certificates are a failed experiment and honestly they don't matter anymore in 2020. Epiphany has never supported EV certificates, and Firefox and Chrome no longer distinguish between EV and normal certificates at all unless you know where to look: https://www.bleepingcomputer.com/news/software/chrome-and-firefox-changes-spark-the-end-of-ev-certificates/. If Safari still displays EV certificates specially, it's the final major browser to do so, and it's probably time to stop doing so.

Anyway, Safari currently defaults to displaying the page as secure, even if it's not really, because it just assumes the content in the cache is secure. IMO Epiphany's behavior -- displaying the page as insecure when we don't have any way to know whether the cached page is secure or not -- is safer until this bug can be fixed. I've argued above that the cache itself must be trusted, but the web content in the cache could have been loaded without HTTPS, so its *content* is not necessarily trusted, not unless we encode CertificateInfo into the cache to allow making that decision.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #9)
> If anyone wants to test service workers to see what the behavior is there,
> that would be interesting.

Looks like it was fixed for Apple in bug #206403, but not fixed for soup ports because CertificateInfo::isolatedCopy is not implemented. Reported bug #216038.

[Anne van Kesteren]

AppCache is now disabled and will be removed in bug 219391.