[Webkit-unassigned] [Bug 204736] [GTK] Allows visiting webpages that use HSTS despite certificate verification failure?

[bugzilla-daemon at webkit.org]

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

--- Comment #11 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Claudio Saavedra from comment #10)
> (In reply to Michael Catanzaro from comment #9)
> > (In reply to Claudio Saavedra from comment #7) 
> > > I wonder if you could use WebKitWebsiteDataManager to fetch the HSTS data
> > > for the site in question. If there is HSTS data you probably want to
> > > disallow continuing. This implies checking for every site that fails to load
> > > with a SSL error, I guess, so it might not be ideal.
> > 
> > Hm, maybe a good idea... that might even be the ideal solution.
> > 
> > Let's do the check at the WebKit level, though. Can't expect dozens of
> > different applications to do such a check.
> 
> Sure, makes sense. What would the API look like though?
>  
> > (In reply to Carlos Garcia Campos from comment #1)
> > > hsts-enforced signal is not emitted for that url. Both ff and chromium allow
> > > to accept the risk and continue.
> > 
> > Huh. So Claudio tested Chrome and found you can't continue. I just tested
> > Firefox, and was also unable to continue. Could you have typed the URL
> > wrong? It is: http://suddomain.preloaded-hsts.badssl.com/
> > 
> > I checked Epiphany again just now and found the continue button is actually
> > broken. It tries to *download* the page as a resource and fails with "Error
> > downloading: Misdirected Request" which sounds like an artifact of using a
> > redirect to switch from http:// -> https://. I'm not sure if I tried this
> > before, or perhaps I just saw the button and assumed it worked.
> 
> Here the button was not doing anything. Then I restarted ephy and now the
> page is actually loaded as if there was no HSTS in place at all. Not sure
> why this inconsistent behavior, but in this bug I would focus on the API for
> the above.

Disk cache?

-- 
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/20191217/b425e620/attachment.htm>