[Webkit-unassigned] [Bug 90267] Handle SSL errors for SOUP
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Jul 5 04:26:02 PDT 2012
--- Comment #16 from Carlos Garcia Campos <cgarcia at igalia.com> 2012-07-05 04:26:01 PST ---
(In reply to comment #14)
> (From update of attachment 150136 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=150136&action=review
> > Looking at the code, it seems to me that mac and win ports don't support this use case in WebKit2.
> This cannot be true - Safari can deal with untrusted certificates. I don't know all the details, but in the UI, there are options to just continue, or to mark the certificate as trusted for the site permanently. I think that the latter would store the decision in Keychain, and the former calls an NSURLRequest SPI similar to +allowsAnyHTTPSCertificateForHost: to remember the decision in a CFNetwork session, and then the request is retried.
Ok, I didn't find code for that in WebKit, I guess they use injected bundle in the app side. I don't have a mac to check what safari does either.
> Other ports likely have their solutions too. It might be possible to create a cross-platform abstraction, but I doubt that making an additional client call on every failure would be the right one.
So, instead of stopping the load until a decision has been made by the WebKit layer, we could use a solution similar to what mac and win seem to do. In case of SSL errors, if the host is not in the list of hosts which any HTTPS certificate should be allowed, we simply finish the load with an error. The error sent to the UI process contains the certificate. The app can handle this error differently and ask the user to decide what to do. If the user decide to ignore SSL errors an continue with the load, the hostname is sent to the web process to be included in the list of hosts that should allow any certificate and a new request is made.
If I'm not wrong again, Qt port sends a sync message to the UI process to decide whether to ignore SSL errors or not. That would block the whole web process until the decision is made by the user, so I prefer to avoid any soluttion that is not asynchronous.
> > Source/WebCore/ChangeLog:3
> > + [SOUP] Handle SSL errors
> A patch that touches cross-platform code should not have  prefixes. Especially now that you say that WebKit2 ports need this.
Ok, I thought this solution might not be valid for other ports.
> > Source/WebCore/ChangeLog:8
> > + No new tests, this is covered by existing tests.
> This explanation doesn't ring true. If this change is covered by existing skipped tests, they should be unskilled in the same patch.
No, this should not affect skipped tests.
> > Source/WebCore/ChangeLog:12
> > + Handle SSL errors in the soup backend adding a way to allow the
> > + WebKit layer decide on what to do. This will allow us to expose an
> > + API to handles SSL errors from the UI process in WebKit2.
> Can other network back-ends cannot recover from an SSL failure on a specific connection? If not, exposing this functionality in WebKit API would be undesirable, even for a single port.
> There is also the question of how request oriented APIs deal with connection level settings. In my experience, this adds a serious amount of trouble. It's sometimes unavoidable, e.g. for NTLM authentication or keep-alive, but should be minimized when possible.
I don't know.
> > Source/WebCore/ChangeLog:20
> > + - When the main resource receives the response with SSL errors,
> > + it asynchronously asks the WebKit layer to check the
> > + certificate in a way similar to the policy checker.
> Do you envision a need for UI process to make complicated decisions? If not, a setting should be just sent to WebProcess in advance to minimize complexity and XPC traffic.
No, just allow or reject the certificate for the given website. But this can't be a global setting, because teh decission might depend on the concrete error or the site the user is trying to access.
> > Source/WebCore/ChangeLog:31
> > + - When a subresource receives the response with SSL errors, the
> > + certificate is compared to the saved certificate in
> > + DocumentLoader, which is considered the trusted
> > + certificate. It will be accepted or denied depending on the
> > + trusted certificate without asking the WebKit layer.
> While this logic makes sense on the surface, I think that it's without precedent in browsers. Do any other browsers behave like this?
Yes, at least chromium and firefox do that, I don't know how it's done in the code, but they only ask the user to accept/reject the certificate for the main resource. When the user decides to continue, all other subresources are loaded without asking the user. When a subresource has an invalid certificate rom another website it's not loaded without asking the user either.
> > Source/WebCore/ChangeLog:51
> > + * loader/FrameLoaderClient.h:
> > + (FrameLoaderClient): Add dispatchCheckTlsCertificate().
> Style nit: TLS should be capitalized everywhere.
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