Bug 140197 – WKWebView needs API to accept invalid SSL certificates

• Component: WebKit2
• Status: VERIFIED DUPLICATE

[Eugene But]

Created attachment 244184 [details]
Test app

Summary:
WKWebView fails to load a web page with invalid SSL certificate and does not provide any public API to proceed

Steps to Reproduce:
1. Download, build and run SSLCertTest project
2. Observe the log

Expected Results:
WKWebView must provide API to accept invalid certificate and proceed. Safari supports this functionality.

Actual Results:
webView:didFailProvisionalNavigation:withError: provides private WKReloadFrameErrorRecoveryAttempter object

This functionality is very important for Web Browsers.

[Eugene But]

Radar ID: 18494626

*** This bug has been marked as a duplicate of bug 135327 ***

[Eugene But]

Created attachment 244298 [details]
Test app #2

[Eugene But]

The bug was closed as a duplicate of a fixed bug 135327.

But this bug (140197) is still reproducible on iOS 8.2.

WKWebView does not call webView:didReceiveAuthenticationChallenge:completionHandler: (as explained in bug 135327) if asked to load a site with bad SSL cert (f.e. https://ssl-cert.org).

Attached Test app #2 to reproduce the problem. Steps to reproduce:

1. Build and run WKWebView app on simulator or device

Actual Result:
The page is blank. 
webView:didReceiveAuthenticationChallenge:completionHandler: not called
webView:didFailProvisionalNavigation:withError: called with error -1202

Expected result:
There should be an API to accept bad SSL cert.

(In reply to comment #4)
> The bug was closed as a duplicate of a fixed bug 135327.
> 
> But this bug (140197) is still reproducible on iOS 8.2.

This is not an appropriate forum for discussing unreleased Apple software.

> 
> WKWebView does not call
> webView:didReceiveAuthenticationChallenge:completionHandler: (as explained
> in bug 135327) if asked to load a site with bad SSL cert (f.e.
> https://ssl-cert.org).
> 
> Attached Test app #2 to reproduce the problem. Steps to reproduce:
> 
> 1. Build and run WKWebView app on simulator or device
> 
> Actual Result:
> The page is blank. 
> webView:didReceiveAuthenticationChallenge:completionHandler: not called

That’s exactly what bug 135327 is about. It’s fixed in TOT.

*** This bug has been marked as a duplicate of bug 135327 ***

[Eugene But]

But this bug (140197) is still reproducible on iOS 8.2.
My apologies I meant 8.1.2.

The fix for bug 135327 is not included in shipping iOS.

You should be able to use a recent WebKit nightly build (or your own build of TOT) on OS X to verify that the delegate method is called and you can decide whether to accept the certificate or not. If it’s not working as expected, please report a new bug. Thanks!

[Eugene But]

Thank you! The following code allows to accept an invalid cert in nightly WebKit build:

- (void)webView:(WKWebView *)webView
    didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge
                    completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler {
  SecTrustRef serverTrust = challenge.protectionSpace.serverTrust;
  CFDataRef exceptions = SecTrustCopyExceptions(serverTrust);
  SecTrustSetExceptions(serverTrust, exceptions);
  CFRelease(exceptions);

  completionHandler(NSURLSessionAuthChallengeUseCredential,
                    [NSURLCredential credentialForTrust:serverTrust]);
}

[Eugene But]

I would appreciate if you could answer a quick question regarding  -webView:didReceiveAuthenticationChallenge:completionHandler:.

Is this delegate method called before any cookies are sent to the server?

Thanks!

(In reply to comment #9)
> I would appreciate if you could answer a quick question regarding 
> -webView:didReceiveAuthenticationChallenge:completionHandler:.
> 
> Is this delegate method called before any cookies are sent to the server?

I am not an expert, but I believe that is not the case, at least for some authentication challenges. For example, for HTTP basic authentication, the user agent makes the request normally, with cookies, and only then receives the 401 status code, which creates the authentication challenge.

[Stuart Morgan]

(In reply to comment #10)
> I am not an expert, but I believe that is not the case, at least for some
> authentication challenges. For example, for HTTP basic authentication, the
> user agent makes the request normally, with cookies, and only then receives
> the 401 status code, which creates the authentication challenge.

We're wondering specifically for certs, now that this callback serves as a cert trust evaluation point in ToT; depending on when this is called the change may make it possible for us to implement things like blacklisting known bad certs (before cookie interception can occur), or we may need to file a separate request for that.