New issue
Advanced search Search tips

Issue 737078 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Aug 6
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

net::IsKnownRoot function doesn't work on Red Hat Linux derivatives

Reported by p...@yandex-team.ru, Jun 27 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Example URL:

Steps to reproduce the problem:
1. build cert_verify_tool;
2. copy it to one of the Red Hat Linux derivatives (e.g. Fedora, CentOS, etc.);
3. verify certificate with a well-known root (e.g. `cert_verify_tool --hostname=yandex.ru yandex.cert');
4. note that there is no `is_issued_by_known_root' flag in tool's output.

What is the expected behavior?

What went wrong?
`net::IsKnownRoot' function implementation for NSS (net/cert/known_roots_nss.cc) is checking if certificate slot name is equal to a magic "NSS Builtin Objects" string. It seems to be working well on Debian derivatives. On RH derivatives slot name for known roots is "/usr/share/pki/ca-trust-source", so known roots (as verified on Ubuntu using the same tool) are not marked with `is_issued_by_known_root' flag in `CertVerifyProcNSS::VerifyInternalImpl'.

Did this work before? N/A 

Chrome version:   Channel: n/a
OS Version: 
Flash Version: Shockwave Flash 25.0 r0

If I am reading `man update-ca-trust' correctly, "/usr/share/pki/ca-trust-source" is a directory where `update-ca-trust' utility takes additional root CA certificates. Hence by using slot name comparison only you cannot distinguish well-known root certs from the added ones. 
I would suggest checking certificate against a sorted array of known roots' SHA256 sums (e.g. taken from Mozilla's CA bundle; see also https://curl.haxx.se/docs/mk-ca-bundle.html) as it is done on Windows.

Tested on CentOS 7, Fedora 22 & 25, Scientific Linux 7, Ubuntu 16.04.
 
yandex.cert
6.4 KB Download

Comment 1 by mmenke@chromium.org, Jun 27 2017

Components: -Internals>Network Internals>Network>Certificate
Status: ExternalDependency (was: Unconfirmed)
The Windows solution is suboptimal and not desirable to be used on other platforms.

The issue is that the current minimum NSS version across supported Linux platforms is NSS 3.26, and support for distinguishing this on Red Hat systems is not introduced until NSS 3.30 (with "CKA_NSS_MOZILLA_CA_POLICY" to handle the policies that Red Hat sets)

Comment 3 by p...@yandex-team.ru, Jun 28 2017

I've found `IsKnownRoot' function analogue in Mozilla Firefox source code (https://dxr.mozilla.org/mozilla-central/source/security/certverifier/CertVerifier.cpp#133). It looks reasonable and it works as expected in `cert_verify_tool' (at least on CentOS 7).

Is there any reason why `net::IsKnownRoot' doesn't use the same code?
Yes. Comment #2 explains why this is not suitable for Chrome use.

Comment 5 by p...@yandex-team.ru, Jun 28 2017

Sorry, didn't get it the first time =) I've used a code from the Firefox 53.0.3 which is not checking `CKA_NSS_MOZILLA_CA_POLICY' flag and mistaking additional roots for well-known on RH systems.

So, you'd like to wait till NSS >=3.30 is a mainstream release on RH distros and then switch `net::IsKnownRoot' to Firefox-like implementation? AFAIK `is_issued_by_known_root' affects such features as OCSP stapling, CT validation and reporting violations with pinned certificates.
We'd like to wait until NSS >=3.30 is mainstream on _all supported Linux distributions_. That's the distinction. We don't maintain per-distro support.

For example, NSS >=3.30 is mainstream on RHEL, which is fantastic. However, Chrome, and Chromium, run on more than RHEL, and rather than maintain multiple codepaths for multiple NSS versions and distributions, we work with the lowest common denominator.

Replacing the NSS built-in, as Red Hat does, is certainly within Red Hat's purview, but it's not supported by Chrome, is the simple answer.
Labels: M-66
Status: Fixed (was: ExternalDependency)
Fixed this back in 36f20e46515ab61df4ae4af9655b647bf9a0ea5a to use a dynamic lookup of the function.

Sign in to add a comment