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

[bugzilla-daemon at webkit.org]

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





--- Comment #14 from Alexey Proskuryakov (on vacation until 7/18) <ap at webkit.org>  2012-07-05 03:52:11 PST ---
(From update of attachment 150136)
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.

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.

> 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.

> 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.

> 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.

> 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.

> 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?

> 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.