Re: [chromium-security] Differential Analysis of Certificate Validation in Desktop Chrome, Mobile Chrome, and Android WebView

2 views
Skip to first unread message

Ryan Dickson

unread,
Sep 18, 2024, 10:08:28 AM9/18/24
to Woonghee Lee, 권현수, chrome-secur...@chromium.org
Hi Woonghee Lee,

Responses inline, below.

While I understand that WebView doesn't rely on the Chrome Certificate Verifier and thus the outcomes may differ, I'm curious whether there are any plans to have Chrome's verification system replace Android's certificate verifier for WebView in the future. Given that WebView is widely used in major applications like Facebook, it seems important to ensure a robust and consistent certificate validation system. I also noticed that on the Android issue tracker, most WebView and browser-related issues are referred to Chromium, which is why I wanted to raise this point with you.

To my knowledge, there are no plans at this time to change WebView certificate verifier to instead rely on the Chrome Certificate Verifier.

Additionally, regarding Test 103, I can confirm that on desktop, the test triggered an error page with the error code ERR_CERT_AUTHORITY_INVALID alongside the warning interstitial. We also assumed that the must-staple extension was not being processed based on the observed behavior, but since a warning appeared in this case, we are making efforts to interpret this. In case it helps, when we ran the same experiment in Firefox, we encountered the error message 'MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING,' which indicates an issue related to OCSP stapling.

Thanks for the additional information.

Lastly, I have attached the full certificate chain for Test 55. For this test, we generated the certificate by including a valid OID followed by an arbitrary OID like 1.2.3.4.5.6.7.8.9. It passed validation without triggering any warnings.

Thank you for sharing.

Studying the example further:
  • The leaf asserts the Certificate Policies extension (critical) with two policy OIDs (2.23.140.1.2.1 and 1.2.3.4.5.6.7.8.9).
  • The intermediate does not assert the Certificate Policies extension.
  • The root does not assert the Certificate Policies extension.
  • None of the certs assert the Policy Constraints extension.

RFC 5280 states:
  • “A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process.” [1]
  • “In an end entity certificate, these policy information terms indicate the policy under which the certificate has been issued and the purposes for which the certificate may be used.  In a CA certificate, these policy information terms limit the set of policies for certification paths that include this certificate.”  [2]
  • "explicit_policy:  an integer that indicates if a non-NULL valid_policy_tree is required … If initial-explicit-policy is set, then the initial value is 0, otherwise the initial value is n+1." [3]
  • After path validation completes: "If either (1) the value of explicit_policy variable is greater than zero or (2) the valid_policy_tree is not NULL, then path processing has succeeded." [4] 

Discussion:
  • Chrome does process the policies extension.
  • Chrome does not set initial-explicit-policy and does not require the certificate to satisfy any policy except in EV verification mode.
  • Given the above, the certificate successfully verifies and has a NULL valid_policy_tree, which is allowed since no policy was required.
  • You could test policy verification by also asserting the Policy Constraints extension with requireExplicitPolicy.

Thanks again!

- Ryan


On Wed, Sep 11, 2024 at 4:39 AM Woonghee Lee <wh...@isslab.korea.ac.kr> wrote:

Dear Ryan and Chromium Security Team,

Thank you for your quick and detailed response. I appreciate the insight regarding Chrome's Certificate Verifier and the differences in certificate handling between Chrome and WebView. I have a few follow-up questions.

While I understand that WebView doesn't rely on the Chrome Certificate Verifier and thus the outcomes may differ, I'm curious whether there are any plans to have Chrome's verification system replace Android's certificate verifier for WebView in the future. Given that WebView is widely used in major applications like Facebook, it seems important to ensure a robust and consistent certificate validation system. I also noticed that on the Android issue tracker, most WebView and browser-related issues are referred to Chromium, which is why I wanted to raise this point with you.

Additionally, regarding Test 103, I can confirm that on desktop, the test triggered an error page with the error code ERR_CERT_AUTHORITY_INVALID alongside the warning interstitial. We also assumed that the must-staple extension was not being processed based on the observed behavior, but since a warning appeared in this case, we are making efforts to interpret this. In case it helps, when we ran the same experiment in Firefox, we encountered the error message 'MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING,' which indicates an issue related to OCSP stapling.

Lastly, I have attached the full certificate chain for Test 55. For this test, we generated the certificate by including a valid OID followed by an arbitrary OID like 1.2.3.4.5.6.7.8.9. It passed validation without triggering any warnings.

Please let me know if further details are required. Lastly, I would like to inform you that this email is also being sent with Prof. Hyunsoo Kwon from Inha University (khs9...@gmail.com), who is collaborating with me on this research.

Thank you again for your attention to these matters.

Best regards,
Woonghee Lee
Ph.D. Candidate, Information System Security Lab (ISSLAB)
Korea University


2024년 9월 11일 (수) 오전 8:01, Ryan Dickson <ryand...@google.com>님이 작성:
[Moving Chrome Security to BCC. This response is on behalf of the Chrome Secure Web and Network Team, part of Chrome Security.] 

Hello Woonghee Lee, 

Thank you for sharing your research. 

Chrome's Certificate Verifier is intended to ensure secure TLS connections across a wide range of environments and use cases, spanning both public and private PKIs. During path building, all certificates are evaluated against a common set of expected properties described in RFC 5280. 

In the case of publicly-trusted TLS certificates, such as those validating to roots included in the Chrome Root Store, we ensure compliance with industry standards like the CA/Browser Forum's TLS Baseline Requirements ("BRs") through additional layers of control via the Chrome Root Program (CRP). The CRP manages the contents of the Chrome Root Store by continuously evaluating CAs against the expectations described in the BRs, a CA Owner's own policies, and the Chrome Root Program Policy. In the case of many issues presented through your research, linting tools like Zlint or pkilint would have detected (and possibly prevented) certificate profile non-conformance. The BRs, and by extension, the Chrome Root Program Policy, set the expectation that mis-issued certificates are revoked according to the timelines in the TLS BRs. 

Overall, the above approach ensures public CAs meet industry expectations while allowing flexibility for private PKIs that have valid use cases outside the scope of the BRs. 

Some initial observations below:
  • Webview does not rely on the Chrome Certificate Verifier (it relies on Android's), so we would not expect those outcomes to always match Chrome's.
  • There may be an issue with the relied upon test methodology contributing to unexpected results. For example, we interpret Row 103 as intended to test a non-critical 'must-staple' extension and reports an interstitial on Desktop but not on Mobile, however, Chrome's verifier doesn't process the extension.
Request for information:
  • Can you please share the full chain of certificates considered by Test Number 55?

Please feel free to share any specific concerns related to certificate validation in Chrome that you feel impacts the security or reliability of TLS connections, or any further insights or questions you may have. 

Thanks again, 
Ryan

On Mon, Sep 9, 2024 at 7:32 PM Woonghee Lee <wh...@isslab.korea.ac.kr> wrote:

Dear Chromium Security Team,

I am Woonghee Lee, a Ph.D. candidate in the Information System Security Lab (ISSLAB) at Korea University in Seoul, Korea. My advisor is Professor Junbeom Hur at Korea University, and I also collaborate with Professor Hyunsoo Kwon from Inha University in Incheon, Korea.

We have conducted a differential analysis of certificate validation between desktop Chrome, mobile Chrome, and Android WebView. In this analysis, we generated non-compliant certificates based on three criteria, as outlined by various RFC standards:

  1. Discrepancies in Core Certificate Fields, such as requiring a CountryName field or avoiding duplicate entries in the extension fields.
    Example: Leaf certificates were incorrectly validated, even when the BasicConstraints field had cA set to true, which should only apply to CA certificates.

  2. Flaws in Certificate Chain Validation, including signature verification, field dependency checks, and name validation.
    Example: Certificates where the KeyUsage field included keyCertSign or cRLSign—intended for CA certificates—were erroneously accepted in leaf certificates.

  3. Gaps in Certificate Extension Practices, focusing on revocation and Certificate Transparency.
    Example: Precertificates, which include the poison extension indicating the certificate is not yet valid for use, were incorrectly accepted without triggering errors.

To conduct this differential analysis, we tested the certificates on desktop Chrome 128.0.6613.119, mobile Chrome 128.0.6613.99, and the Android WebView within the Facebook app (version 479.0.0.48.89). Our testing environment involved adding our custom CA certificate to Android's trusted certificate list and configuring a DNS resolver using Dnsmasq, allowing access to test domains specified in the certificates. Additionally, we verified that Facebook WebView accepts user certificates before proceeding with the experiment.

Attached is a link to the test results ( https://docs.google.com/spreadsheets/d/1Qk8wj8SZdneeSuvf0ss0SzFTWHXVhrklPTQ6Bq-iUcE/edit?usp=sharing  ). The "name" column describes the RFC criteria that each certificate violates, while the "class" column categorizes the specific type of error. The responses are recorded in three categories: No Warning (accessing the website without any warnings), Warning (a certificate warning is displayed but allows the user to proceed), and Reject (access to the site is blocked entirely).

During our tests, we ensured that the web server provided not only the leaf certificate but also the intermediate CA certificate to verify chain validation. We found a total of 51 cases where warnings appeared in desktop Chrome, mobile Chrome, and the Facebook WebView. Out of these, WebView failed to display a warning in 49 cases (see the "Differential Result" tab).

Notably, there were 46 instances where an intermediate certificate triggered a warning in desktop Chrome but no warning in WebView (see the "IntermediateCA" tab). Of these, 36 intermediate certificates had errors related to extensions, highlighting a significant vulnerability in WebView's intermediate certificate validation, particularly in extension handling.

Overall, across the 106 certificates tested (including both leaf and intermediate certificates, see the "Total" tab), WebView failed to validate 78 certificates, compared to 40 failures in mobile Chrome and 31 in desktop Chrome. The 9 cases where mobile and desktop Chrome produced different results were all related to intermediate certificate validation.

Additionally, while we observed this behavior in the Facebook WebView, identical results were obtained when testing with a self-made WebView app that handled certificate validation using only the onReceivedSslError method.

Summary:

  • Inconsistent Validation Across Platforms: Desktop and mobile Chrome browsers behave differently in certain cases, with mobile Chrome failing to validate more certificates than its desktop counterpart.
  • WebView's IntermediateCA Certificate Vulnerability: WebView demonstrated significant weaknesses in intermediate certificate validation, especially in handling certificate extensions, resulting in a failure to display warnings in most tests.
  • Severe Validation Failures in WebView: Across the tests, WebView failed to validate 78 certificates, raising concerns about its security compared to mobile Chrome and desktop Chrome.

We hope this information is helpful, and we are available for further discussion or clarification regarding these findings.

Kind regards,
Woonghee Lee

--
--
-----
secu...@chromium.org is for discussing vulnerabilities and fixes in Chromium code.
Please protect Chromium users: DO NOT FORWARD this email or disclose its contents to third parties.
 
http://groups.google.com/a/chromium.org/group/security

To unsubscribe from this group and stop receiving emails from it, send an email to security+u...@chromium.org.
Reply all
Reply to author
Forward
0 new messages