Switch iOS's CertVerifyProc to use SecTrustEvaluate rather than CertVerifyProcNSS |
|||
Issue descriptionCurrently, CertVerifyProc on iOS uses an NSS-based core (CertVerifyProcNSS), so that it can return robust error information. However, this adds complexity, particularly because it can lead to inconsistent results with WKWebView. We should look to switch the CertVerifier/CertVerifyProc for iOS to use SecTrustEvalaute (or SecTrustEvaluateAsync). This will cause a loss of fidelity for error explanations, since iOS presently only provides an opaque string 'description' of the error ( SecTrustCopyProperties ). For Cronet, our minimum desired fidelity is pass/fail. For Chrome, the ideal desired fidelity is to distinguish between expired/not-yet-valid certificates, those with hostname mismatches, and those that aren't trusted. For Chrome, we can infer some aspects of the certificate error based on the leaf cert, which is the only cert guaranteed to be present from iOS.
,
Mar 16 2016
Sure! Right now, all crypto on the iOS port is being provided by NSS. This means that we end up having to do two implementations - NSS and BoringSSL - for a variety of services. It also means that TLS stack work, even if it doesn't affect Chrome-on-iOS-web's loading, still has to be duplicated as well. Concrete examples include the work for TLS1.3 and QUIC (in //net land), but also extend to the efforts to improve the testing story via the EmbeddedTestServer (which we can reasonably support with BoringSSL, but NSS's TLS server stack is... one of the god-awful worst) Unlike Chrome for Linux/ChromeOS, it's much harder to have our cake and eat it too - that is, the Chimera build of both NSS+BoringSSL - due to static linking and how that's done. While there's a possible path forward on that, it's brittle, gross, and complex - thus still adding to maintenance costs. Further, we've got a product excellence issue, which is things that load in Chrome (via WKWebView) don't necessarily load in Chrome (via URLRequest), due to things like MDM certs. So we end up in a world where, in an MDM case (EDU & Enterprise especially), things only half-work. By transitioning iOS fully to BoringSSL, we: - Improve the user experience by harmonizing on the SecTrust behaviours used for normal web content loading - Can simplify and clean up interfaces in //net and //crypto that are today weird or inconsistent, due to NSS and OpenSSL having different primitives (e.g. our weird pseudo-encrypted EC keys to work around NSS 'design' bugs) - Can reduce the maintenance costs by no longer needing to double the work - Can improve our testing and implementation story, by making wider use of EmbeddedTestServer Sorry for not capturing more of this discussion on the bug, and thanks for the push to do so.
,
Mar 16 2016
,
Apr 14 2016
svaldez@ fixed this in https://chromium.googlesource.com/chromium/src/+/b7f886b3d364497ff0422e9808d8ad04ffcb5c4d
,
Apr 14 2016
Ryan, does this change mean that Chrome for iOS should not use CertVerifier for getting the reason of failure, but rather incorporate code from CL: https://codereview.chromium.org/1871043003/ ? Seems like after this change we make 2 certs verifications using SecTrust API.
,
Apr 14 2016
eugenebut: Good catch. We should file a follow-up bug for that. The second validation *does* give more detailed information, so there is value right now in doing it. But we can be more efficient about that.
,
Apr 14 2016
Filed: crbug.com/603634 |
|||
►
Sign in to add a comment |
|||
Comment 1 by f...@chromium.org
, Mar 16 2016