Summary: | WKWebView needs API to accept invalid SSL certificates | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eugene But <eugenebut> | ||||||
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | VERIFIED DUPLICATE | ||||||||
Severity: | Critical | CC: | ap, mitz, stuartmorgan | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | iPhone / iPad | ||||||||
OS: | All | ||||||||
Attachments: |
|
Radar ID: 18494626 *** This bug has been marked as a duplicate of bug 135327 *** Created attachment 244298 [details]
Test app #2
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 *** 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! 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]); } 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. (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. |
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.