Bug 140197 - WKWebView needs API to accept invalid SSL certificates
Summary: WKWebView needs API to accept invalid SSL certificates
Status: VERIFIED DUPLICATE of bug 135327
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: iPhone / iPad All
: P2 Critical
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-01-07 13:17 PST by Eugene But
Modified: 2015-01-13 13:35 PST (History)
3 users (show)

See Also:


Attachments
Test app (25.94 KB, application/zip)
2015-01-07 13:17 PST, Eugene But
no flags Details
Test app #2 (24.95 KB, application/zip)
2015-01-08 15:12 PST, Eugene But
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eugene But 2015-01-07 13:17:33 PST
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.
Comment 1 Eugene But 2015-01-07 16:00:09 PST
Radar ID: 18494626
Comment 2 mitz@webkit.org 2015-01-08 13:00:13 PST

*** This bug has been marked as a duplicate of bug 135327 ***
Comment 3 Eugene But 2015-01-08 15:12:05 PST
Created attachment 244298 [details]
Test app #2
Comment 4 Eugene But 2015-01-08 15:20:39 PST
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.
Comment 5 mitz@webkit.org 2015-01-08 15:53:56 PST
(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 ***
Comment 6 Eugene But 2015-01-08 16:16:38 PST
But this bug (140197) is still reproducible on iOS 8.2.
My apologies I meant 8.1.2.
Comment 7 mitz@webkit.org 2015-01-08 16:22:11 PST
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!
Comment 8 Eugene But 2015-01-09 13:27:25 PST
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]);
}
Comment 9 Eugene But 2015-01-13 12:57:11 PST
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!
Comment 10 mitz@webkit.org 2015-01-13 13:30:31 PST
(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.
Comment 11 Stuart Morgan 2015-01-13 13:35:55 PST
(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.