Linux Certificate Authority root stores have a too simple view of 'trust'

December 1, 2022

Let's start with the background. Pretty much every Linux system (really, every Unix system) has a 'system CA root store', by which we mean 'the list of all CA root certificates that are trusted by default by most TLS-using software'. For various sensible reasons, many Linux distributions reuse Mozilla's CA root store for their system root store, possibly with some tweaks.

The recent TLS news is that Mozilla (and Microsoft) are distrusting the TrustCor CA certificates (see this entry for more on TrustCor). Over on the Fediverse, Filippo Valsorda reported the news and said:

Mozilla is distrusting TrustCor.

Certificates issued from December 1st onward won't be trusted, roots will be removed once current certificates expire.

Note that this probably means systems like Linux distros that just consider the Mozilla root store a bag of certificates will fully trust TrustCor for at least another year, likely longer due to release lag.

<mozilla mailing list link>

You might reasonably be confused about why Linux systems would trust TrustCor certificates for so long. The lesser reason is delays in updating their packaged copies of the Mozilla root store (and then getting you to apply the updates). But the major reason is that on Unix, the traditional 'CA root store' model is too limited.

Mozilla is not removing TrustCor's root certificates from their root store, not yet. Instead, in their root store there will be 'Distrust for <X> After Date' markers for these certificates, dated December 1st. Certificates signed by TrustCor that were issued before December 1st will still be trusted (for now); certificates issued on December 1st or later will not be. This is fine and reasonable for Mozilla and for browser vendors (Microsoft has already done something similar, although their trust cutoff date was November 1st).

The problem for Linux distros is that most code that uses a 'CA root store' doesn't support this sort of nuanced trust decision. Instead, it expects a 'root store' that contains a bunch of fully trusted CA certificates. If a certificate chains up to a TLS certificate in the root store, it's trusted; if a certificate doesn't, it's not trusted. To use Valsorda's words, this is the 'bag of certificates' model. As long as the TrustCor root certificates are in the root store bag, all of TrustCor's TLS certificates are trusted, regardless of when they were issued; if TrustCor's root certificates aren't in the bag, none of those certificates will be trusted. There's no support for trusting only some of those certificates, or indicating this to programs.

(Some Linux distributions may choose to drop TrustCor entirely from their CA bundle, which is a reasonable decision. But they'd have to know about this issue and make a decision; if they just extract all of the CA root certificates in Mozilla's store that are 'trusted' to at least some degree, they will get the TrustCor certificates too.)

In theory, Linux distributions could collect this sort of additional trust information from the Mozilla root store and include it in their packages of root certificates (in both Ubuntu and Fedora, this package is called 'ca-certificates' and already contains a variety of things other than just the certificates). In practice, there's no standard for the format of this additional information and no code that would consume it and do the right thing. Perhaps as a result, I don't think anyone actually tries to capture this additional information anywhere in their CA certificates package.

(Arguably this is a real flaw in modern TLS packages and libraries. Browsers have been selectively distrusting CAs for years now, but I think most TLS packages still have no support for this sort of thing, not even loading distrust information into them by hand.)

(This elaborates on something I said on the Fediverse.)

PS: As mentioned, Mozilla will remove the TrustCor roots once they can't verify anything, ie once all TrustCor certificates issued before December 1st have expired. That will probably take about a year, assuming TrustCor doesn't do something before then. Once the TrustCor certificates aren't in the Mozilla root store at all, this will propagate to Linux distros.


Comments on this page:

From 193.219.181.219 at 2022-12-02 00:00:48:

Some software (so far mostly just GnuTLS and glib-networking, I think?) has actually moved from the "CA cert bundle" model to using p11-kit's PKCS#11 module to retrieve CA certificate information. This is the exact same method as Mozilla's NSS uses to store the built-in CA certs (indeed some distros even replace the NSS "Built-in object token" with p11-kit's one, to make Firefox natively load system CAs instead of using the hardcoded list), meaning that programs would be able to get "Distrusted By" dates as PKCS#11 attributes. Unfortunately, adoption of this mechanism is low.

(Though for Fedora in particular, who insists on having consistent system-wide cryptography policies to the point that they used to port various software to NSS, it is possible that they've also made their OpenSSL builds use p11-kit as well? – I haven't looked into it recently.)

Only a damned fool trusts any Certificate Authority. All of this TLS nonsense is snake oil. Which is it: TLS protects people from the government and corporations snooping, or any Certificate Authority owned by a government or corporation can trivially break the entire system and all software is conveniently designed to obscure this when it happens?

Written on 01 December 2022.
« Using Dovecot 2.3's 'events' system to generate log messages
Apache 2.4's event MPM and oddities with ServerLimit »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Thu Dec 1 23:41:03 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.