Tuesday, November 30, 2021

Hidden Certificate Authorities

The security of encrypted Web traffic depends upon a set of Certificate Authorities (CAs). Browsers and operating systems are configured with a list of CAs that they trust. The system is brittle, in the sense that if any of the multitude of CAs that your browser trusts is incompetent or malign, the security of all your traffic is imperiled. I've written several times on the topic of misbehaving CAs; there is a list of links at the end of the post.

In Web trust dies in darkness: Hidden Certificate Authorities undermine public crypto infrastructure, Thomas Claiburn reports on an important paper, Rusted Anchors: A National Client-Side View of Hidden Root CAs in the Web PKI Ecosystem by Yiming Zhang et al. This paper looks at what happens when, by fair means or foul, unofficial entries are added to or replace the CAs in the official list that your browser trusts. Below the fold I discuss their findings.

The paper's abstract reads:
Web clients rely on public root stores maintained by operating systems or browsers, with hundreds of audited CAs as trust anchors. However, as reported by security incidents, hidden root CAs beyond the public root programs have been imported into local root stores, which allows adversaries to gain trust from web clients.

In this paper, we provide the first client-side, nation-wide view of hidden root CAs in the Web PKI ecosystem. Through cooperation with a leading browser vendor, we analyze certificate chains in web visits, together with their verification statuses, from volunteer users in 5 months. In total, over 1.17 million hidden root certificates are captured and they cause a profound impact from the angle of web clients and traffic. Further, we identify around 5 thousand organizations that hold hidden root certificates, including fake root CAs that impersonate large trusted ones. Finally, we highlight that the implementation of hidden root CAs and certificates is highly flawed, and issues such as weak keys and signature algorithms are prevalent.
Why are hidden root CAs a problem?
However, recent security incidents and studies show that the management of local root stores can be the "Achilles’ heel" of Web PKI security. By injecting self-built root certificates into local root stores, local software such as anti-virus and parent-control applications creates a man-in-the-middle proxy to filter SSL/TLS-encrypted traffic. This approach can also be used by government agencies or malware, in order to monitor web users’ online behaviors. For instance, reports in 2019 show that citizens in Kazakhstan were forced to import government-built CAs on their devices.
The authors instrumented a widely-used browser, tracking the certificates used to secure traffic with Web sites, and verifying them thus:
we use the Certificate Transparency (CT) database to verify if they are truly beyond public root stores. To monitor the certificate issuance procedure, since June 2016 all CAs in public root stores are required to submit all certificates that they sign to CT for future queries. As a result, hidden root certificates should not appear in CT databases.
I discuss the details of the Certificate Transparency system (RFC 6962) in this post. Briefly, an important property of the CA system is that all CAs are equally trusted, and can issue certificates on behalf of any Web site. But Web sites authorize only a single CA to issue their certificates. A rogue CA can allow impersonation of any Web site by issuing unauthorized certificates. The CT system consists of a set of public logs containing signed attestations that the certificate in question was issued by the CA that the Web site authorized to do so. Wikipedia notes that:
As of 2021, Certificate Transparency is mandatory for all publicly trusted TLS certificates
So the certificate of a hidden root CA is one that appears in the local list of trusted CAs but isn't in the CT databases. Because these hidden root CAs are in the list, they are trusted equally with the official CAs, and can sign certificates for any Web site they choose. thus opening the user to impersonation and interception of their traffic.

The authors make four major observations. First, hidden root certificates are a pervasive problem:
We identify 1.17 million hidden root certificates that have been imported into local root stores of web clients. Based on their subject information, we identify 5,005 certificate groups, and certificates in each group come from the same organization. The impact of hidden root CAs can be profound, as they are witnessed in 0.54% of all web connections, affecting 5.07 million web clients and putting security connections at risk of interception.
Second, although there can be authorized uses for hidden root certificates, many are clearly malign:
Besides self-built root CAs of enterprises and local software, we also uncover a large number of fake root CAs that impersonate trusted ones to evade detection. For example, they use homoglyphs to replace characters in authentic names (e.g., Verislgn with an “l” and NetWork with an upper-case “W”). While not discovered by previous works at scale, we show that fake root CAs are highly trusted by web clients and pose security threats to up to 2.7 million web clients.
Third, in addition to the fundamental insecurity imposed by hidden root certificates, the overwhelming majority of them are so carelessly constructed that they insert additional vulnerabilities:
As for operational flaws, we find that the security status of hidden root CAs and certificates are worrisome: public key sharing, abuse of wildcards and long validity period are prevalent. More than 87.3% of hidden root certificates and 99.9% of leaf certificates that they sign violate at least one X.509 standard requirements. In particular, 97% of leaf certificates issued by hidden CAs use weak keys, increasing their chances of being compromised.
Fourth, they find that the distribution of hidden root certificates is heavily skewed. In particular, malign roots are targeted:
Although on average 0.54% of daily web traffic is covered by hidden roots, the proportion per individual client varies widely. For more than 95% of clients, the percentage is less than 0.01%, while 0.28% of clients have more than 90% of their web visits impacted. To figure out why certain clients were impacted so heavily, We sampled 104 cases who had more than 500 web visiting records and an affected rate of over 99% for further analysis. One may attribute this high percentage to interceptions from Local Software like proxies and packet filters, but we find this situation appeared on only 10.58% clients (11 of 104). On the contrary, hidden roots from Fake Authentication (64 clients, 61.54% of 104) lead the pack.
Victims of malign roots are actively monitored:
By examining the traffic timestamps of those clients, we also find that, hidden roots from Fake Authentication would be constantly updated on the client-side, possibly to avoid detection. Specifically, 3 of the 104 cases had successively installed more than 20 hidden root certificates from the same issuer, and the average lifetime (the period they appeared in traffic logs, rather than the validity period) of each root did not exceed 1 day.
What can clients do to detect hidden root certificates? Clearly, if browsers require CT for certificates they trust, even if by some means a hidden root CA is added to their trust list, it will not be able to falsely indicate that a site is trusted or intercept its traffic. Doing so will prevent some authorized applications, such as corporate employee monitoring and parental controls, working without explicit action by the user to allow them.

The authors detect characteristics of hidden root certificates and the certificates they sign. For example:
As for public keys, 0.59% hidden root certificates (20.73% of self-built CAs) use weak keys, while up to 97% leaf certificates signed by them use weak public keys. Comparing to leaf certificates signed by public trusted CAs, a study in 2013 find that nearly 90% already had a key strength of 2048-bit RSA or above.
Making browsers warn users when they detect suspicious certificates of these kinds would be beneficial, as encouraging authorized interception applications not to introduce significant new vulnerabilities by careless implementation.

Previous Posts

No comments: