Russia attempts mandating installation of root CA on clients for TLS MITM

Sean Donelan sean at
Sun Mar 13 00:33:13 UTC 2022

Likewise, my statements and opinions also do not represent any past, 
current or future employer.

While I understand the engineering and business reasons (fewer customer 
complaints and lawsuits), the underlying risk is due to the combined 
'universial trust root CA' store in most TLS/SSL software and vendors.

About 10 years ago, while working on federal network security I tried to a 
trust list for USG agency use on USG I.T. equipment. Commercial vendors 
have different business reasons than governments for including or not 
including particular CA's.  It was a deep rabbit hole, and I understand 
the details are much more complicated than this email can cover.

You'll notice there still isn't a CA trust list for use in the USG :-)

About 95% of the TLS certificates globally are ultimately signed by about
six CA organizations depending how you track ownership. (I know, multiple 
"abouts" in that sentence).  The long tail of global business, means most 
operating systems ship (or after the installation autoupdate) with 100+ 
trusted certificate authorities by default.

According to Wikipedia:
   "As of 24 August 2020, 147 root certificates, representing 52
   organizations, are trusted in the Mozilla Firefox web browser,[9] 168
   root certificates, representing 60 organizations, are trusted by
   macOS,[10] and 255 root certificates, representing 101 organizations,
   are trusted by Microsoft Windows.[11] As of Android 4.2 (Jelly Bean),
   Android currently contains over 100 CAs that are updated with each

Besides popular off-the-shelf systems, the rabbit hole goes even deeper 
with a dozen other CA trust lists needed for things like ePassports, 
trade and customs exchanges, pharma and medical, etc. And some widely 
used business software like Adobe and Oracle have their own trust lists.

If you are worried about a jump/skip/hop about authoritarian regimes 
gaining a foothold in TLS trust stores.  That horse left the barn a long 
time ago.  Have you looked at the list of CA's included by default in 
major open source and commercial vendor's TLS trust stores. Now 
re-consider those 'universal' trust lists from the point of view of 194 
different countries around the world. Open source and commercial 
companies have been vulnerable to compromise too.

Its not a question of whether you trust one CA (e.g. the Russian Ministry 
of Digital Development CA), but whether everyone trusts all 100+ CA's in 
universal trust stores to sign everything/anything.

Again, I understand why companies and open source projects don't want to 
maintain different trust lists for different jurisdictions around the 
world.  Like other localization requirements (currency, date & time 
formats, languages) maybe its time has come for localization requirements 
for TLS/SSL trust lists?

On Fri, 11 Mar 2022, Dario Ciccarone (dciccaro) wrote:
> I think the point Eric was trying to make is that while, indeed, the 
> initial, stated goal might be to be able to issue certificates to 
> replace those expired or expiring, there's just a jump/skip/hop to 
> force installation of this root CA certificate in all browsers, or for 
> Russia to block downloads of Firefox/Chrome from outside the Federation, 
> and instead distribute versions which would already include this CA's 
> certificate. And then MITM the whole population without their knowledge 
> or approval.

More information about the NANOG mailing list