[Webkit-unassigned] [Bug 90267] Handle SSL errors for SOUP

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jul 11 02:49:14 PDT 2012


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





--- Comment #26 from Carlos Garcia Campos <cgarcia at igalia.com>  2012-07-11 02:49:12 PST ---
(In reply to comment #18)
> (From update of attachment 151088 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=151088&action=review
> 
> > Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:431
> > +        if (d->m_response.soupMessageTLSErrors() && !ignoreSSLErrors && !allowsAnyHTTPSCertificateHosts().contains(handle->firstRequest().url().host().lower())) {
> 
> Does host() also include the port number? If I'm not mistaken you want something like the security domain (scheme-host-scheme). The scheme may not be important here, but perhaps it would be better to make this conditional on protocolHostAndPortAreEqual.
> 
> I also wonder what happens when you make a request to http://foo.com and then http://foo.com:80.

allowsAnyHTTPSCertificateHosts() won't be exposed in the API, it's mainly used for testing. Mac and win ports use it in DRT and WTR to allow any certificates in localhost and 127.0.0.1. That's what we'll do for WTR too. 

When an invalid certificate will be accepted by the wk layer, setClientCertificate() will be used. In this case, the certificate is stored per host, and it's always checked. So, if https://foo.com is loaded and the certificate is accepted, when loading https://foo.com:80, the certificate will be checked for foo.com. If the certificate is the same, then it will be loaded, otherwise (no certificate or it's invalid and different) the load will finish with an error. Then, again, it's up to the app to handle the error and accept/reject the certificate.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list