New issue
Advanced search Search tips

Issue 787635 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Dec 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Record metrics for trust anchor utilization

Project Member Reported by rsleevi@chromium.org, Nov 21 2017

Issue description

In order to determine the trusted status of a connection, Chrom[e/ium] needs to build a path from the server's certificate to a trust anchor. A trust anchor is sometimes called a root certificate, but that's a slight confusion - root certs generally imply a self-signed certificate, while a trust anchor is meant to express the tuple of public key and subject name.

In order to measure the impact of various cryptographic policies, including policies on which trust anchors are trusted (for example, removing trust after a security incident) or limitations imposed on trust anchors, it's important to have a way to assess the user impact.

While public information about the issued certificates exists via Certificate Transparency logs, this provides information about the certificate issuance practices, but not about the actual user impact. That is, a policy that only affected one certificate out of a million may seem inconsequential, but if that policy affected the top site a million users visit every day, that would be a significant disruption.

To better inform the policies around both certificate path building and trust, it's important to be able to assess user impact. This involves determining which trust anchor was involved in certificate path validation and recording it for users who have opted in to help improve Chrome.

This is, however, complicated by the fact that the set of trust anchors supported in Chrom[e/ium] varies with the platform it's being run on, and the versions of the library, OS, or trust store being used. Further, a given certificate chain may have multiple conceptual trust anchors involved, even though there is only one logical trust anchor (the last certificate in the path). Measuring purely by the last certificate, or measuring based upon the coarse OS data (such as Windows v Mac) thus presents incomplete information.

That is, it's possible to have a server certificate that results in the following paths:
On Windows: (Server Cert) -> (Intermediate) -> (Root 1)
On Mac: (Server Cert) -> (Intermediate) -> (Root 1 signed by Root 2) -> (Root 2)
On Android: (Server Cert) -> (Intermediate) -> (Root 1 signed by Root 3) -> (Root 3)
On Linux: (Server Cert) -> (Intermediate') -> (Root 4) -> (Enterprise Root)

To measure user-impact, metrics will be collected both per certificate verification and per-URLRequest. The latter will only measure connections to 'endpoints' - that is, if a URLRequest traverses a proxy to talk to 'example.com', and the proxy uses TLS with a known trust anchor, only the 'example.com' usage will be recorded in the per-Request statistics.

To provide a consistent evaluation regarding "What happens if Root 1 is explicitly distrusted" (or what happens if all of the trust anchors for a given organization are distrusted), the most specific trust anchor will be recorded. That is, in the above example, Windows, Mac, and Android would record "Root 1" while Linux would record "Root 4".

This will ensure that situations where "Root 1" is operated by a different organization than Roots 2 or Roots 3 (commonly known as "cross-signing") will be appropriately bucketed as "trust that is rooted in Root 1", rather than these other organizations (for example, removing trust in Root 2 or Root 3, but adding trust in Root 1, means that there would be no negative user impact)
 
One important dimension of this: Because of variance of trust stores across platforms, and because of the cross-certification, it's necessary to recognize the union of 'publicly trusted' trust anchors for this metric.

That is, if the goal is to assess what sites work in Windows but fail in macOS (due to a missing trust anchor) and which load due to a cross-certificate on Android, then it's necessary to include all platforms trust anchors to reliably ensure the most specific trust anchor is selected.

Across all supported Chrome platforms (that is, all supported versions of Windows, macOS, Linux, Android, ChromeOS - places we can measure such usage), the total number of trust anchors is 488. At 32 bytes per hash of the SPKI, this will lead to an expected 15K binary size bump.

Limiting by platform limits the actionable data and may not substantially save - there are more than 400 trust anchors on supported Windows versions, for example.
Project Member

Comment 2 by bugdroid1@chromium.org, Nov 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/19a7bde4ee6a1345827aa0ca46219cde7e264d0e

commit 19a7bde4ee6a1345827aa0ca46219cde7e264d0e
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Wed Nov 22 06:51:39 2017

Record per-verification and per-request histograms on trust anchor usage.

To better assess compatibility risks of Web Platform changes around
trusted CAs, and to asses the interoperability pains due to differences
in per-platform trust behaviours, collect metrics around various trust
anchors usage.

Because of how the Web PKI works, in which an existing trust anchor (CA)
may sign a new trust anchor, and a given platform may support old,
old+new, or new, the full union of all platforms is considered in
histogramming. This allows for effective distinction between
certificates that 'old' may have issued from those 'new' have issued,
whether it is a single organization with multiple certificates or
distinct organizations with distinct roots.

As this list does not change frequently, and is used for histogram
purposes, a static list of the root store is checked in, along with a
static copy of a generated file based on that. Scripts are included for
updating and maintaining the generated files and histograms.

Measurements are done per-URLRequest and per-CertVerifyProc::Verify()
call. If only per-verification metrics were measured, it would
undercount the user impact due to a popular CA having their trust status
changed. If only per-request metrics were measured, usage counts would
be strongly biased towards popular CAs and not be useful in assessing
performance impact on users for per-CA policies.

BUG= 787635 

Cq-Include-Trybots: master.tryserver.chromium.android:android_cronet_tester;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: I5c34abc9b7aaef446d767fbe355d4dc29e07c6a7
Reviewed-on: https://chromium-review.googlesource.com/774913
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Reviewed-by: Marc-Antoine Ruel <maruel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#518555}
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/BUILD.gn
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/cert_verify_proc.cc
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/cert_verify_proc_unittest.cc
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/known_roots.cc
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/known_roots.h
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/known_roots_unittest.cc
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/cert/root_cert_list_generated.h
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/data/ssl/root_stores/README.md
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/data/ssl/root_stores/root_stores.json
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/data/ssl/root_stores/update_root_stores.py
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/net/url_request/url_request_http_job_unittest.cc
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/tools/metrics/histograms/histograms.xml
[add] https://crrev.com/19a7bde4ee6a1345827aa0ca46219cde7e264d0e/tools/metrics/histograms/update_net_trust_anchors.py

Labels: M-64
Project Member

Comment 4 by bugdroid1@chromium.org, Dec 1 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d756c2dfa56141b3970cd836fb0a39d6872ca0e6

commit d756c2dfa56141b3970cd836fb0a39d6872ca0e6
Author: Ryan Sleevi <rsleevi@chromium.org>
Date: Fri Dec 01 02:07:48 2017

Update the root store histograms for Windows 2017-11-21 update

Also distinguish between no hashes available (e.g. loaded from disk
cache) and no publicly trusted hashes (e.g. private CA) in the
.Request metric. Given that this only affected Canary metrics for
a week, the metric is intentionally not renamed.

BUG= 787635 , 788563 

Change-Id: I7ff97cd3ecd20b308e6cc85df5c549608251dcbe
Reviewed-on: https://chromium-review.googlesource.com/802214
Reviewed-by: Ryan Sleevi <rsleevi@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Commit-Queue: Ryan Sleevi <rsleevi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520788}
[modify] https://crrev.com/d756c2dfa56141b3970cd836fb0a39d6872ca0e6/net/cert/root_cert_list_generated.h
[modify] https://crrev.com/d756c2dfa56141b3970cd836fb0a39d6872ca0e6/net/data/ssl/root_stores/root_stores.json
[modify] https://crrev.com/d756c2dfa56141b3970cd836fb0a39d6872ca0e6/net/url_request/url_request_http_job.cc
[modify] https://crrev.com/d756c2dfa56141b3970cd836fb0a39d6872ca0e6/net/url_request/url_request_http_job_unittest.cc
[modify] https://crrev.com/d756c2dfa56141b3970cd836fb0a39d6872ca0e6/tools/metrics/histograms/enums.xml

Status: Verified (was: Started)

Sign in to add a comment