[Webkit-unassigned] [Bug 196182] Using Application Cache on HTTPS websites breaks browser security indicators (e.g. webkit_web_view_get_tls_info()); CertificateInfo not properly cached

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=196182

--- Comment #7 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190325/a419c68a/attachment.html>