[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 bugzilla-daemon at webkit.org
Tue Sep 1 08:41:52 PDT 2020


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

--- Comment #9 from Michael Catanzaro <mcatanzaro at gnome.org> ---
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.

-- 
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/20200901/30edbbb2/attachment-0001.htm>


More information about the webkit-unassigned mailing list