[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 #15 from Michael Catanzaro <mcatanzaro at gnome.org> ---
(In reply to Claudio Saavedra from comment #14)
> How would that implementation work?
> 
> I'm assuming that what we're doing is that, regardless of the TLS failure,
> we check whether there's a HSTS policy, in which case we would emit
> ::load-failed-with-hsts-error. Then if
> webkit_web_context_allow_tls_certificate_for_host() gets called, we have to
> check again if there's a HSTS policy and fail/warn/etc about it.

Maybe my proposal is too aggressive in including a behavior change for webkit_web_context_allow_tls_certificate_for_host(). We can leave this unchanged and just document that the browser probably shouldn't call it inside ::load-failed-with-hsts-error because that would violate the spec. I don't think we need to go out of our way to entirely prevent browsers from doing what they want. It should suffice to make it easy to do the right thing by default.

E.g. we don't want to entirely block use of self-signed certificates with HSTS; those are still fine as long as the use is known in advance.

> If that's the case this could work.. the key is that we need to check for
> every TLS failure regardless of what caused it.

Well every TLS failure on a site with HSTS policy would result in the new signal, yes.

-- 
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/20191218/31e8b14f/attachment.htm>