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

Eric Kuhnke eric.kuhnke at gmail.com
Fri Mar 11 18:34:08 UTC 2022


Considering that 99% of non-technical end users of windows, macos, android,
ios client devices *have no idea what a root CA is,* if an authoritarian
regime can mandate the installation of a government-run root CA in the
operating system CA trust store of all new devices sold at retail, as
equipment is discarded/upgraded/replaced incrementally over a period of
years, they could eventually have the capability of MITM of a significant
portion of traffic.

Presumably with Apple ending shipment of new MacOS devices to Russia and
retail sales of new devices, this wouldn't be so much of an issue with
MacOS.  The process of re-imaging a modified MacOS install .DMG onto a
"blank" macbook air or similar with a new root CA included would be non
trivial, and hopefully might be impossible due to crypto signature required
for a legit MacOS bootable install image.

Mozilla is the only browser vendor these days that maintains its own
independen root CA storage for the browser. Chrome, Chromium, Safari, Edge,
IE etc all use whatever root CAs are trusted by the operating system. If
they can get Windows 10 client PCs pushed to retail with an image that
includes their CA...






On Thu, 10 Mar 2022 at 18:27, Dario Ciccarone (dciccaro) via NANOG <
nanog at nanog.org> 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.
>
> GIVEN: savvy users might know how to delete the certificate, or others may
> teach them how, and how to download other CA's certificates (if the
> government was to ship only this certificate with the browser). Cat and
> mouse game. The North Korean and Chinese governments have been doing these
> kind of shenanigans for a long time - I am sure Russia could copy their
> model. And considering the tight media control they’re already exercising,
> I don't think it is crazy or paranoid to think Internet will be next. They
> seem to be already going down that path.
>
> PS: opinions and statements, like the above, are my very own personal take
> or opinion. Nothing I say should be interpreted to be my employer's
> position, nor be supported by my employer.
>
> On 3/10/22, 7:38 PM, "NANOG on behalf of Sean Donelan"
> <nanog-bounces+dciccaro=cisco.com at nanog.org on behalf of sean at donelan.com>
> wrote:
>
>     On Thu, 10 Mar 2022, Eric Kuhnke wrote:
>     > I think we'll see a lot more of this from authoritarian regimes in
> the
>     > future. For anyone unfamiliar with their existing distributed DPI
>     > architecture, google "Russia SORM".
>
>     Many nation's have a government CA.
>
>     The United States Government has its Federal Public Key
> Infrastructure,
>     and Federal Bridge CA.
>
>     https://playbooks.idmanagement.gov/fpki/ca/
>
>     If you use DOD CAC ID's or FCEB PIV cards or other federal programs,
> your
>     computer needs to have the FPKI CA's.  You don't need the FPKI CA's
> for
>     other purposes.
>
>     Some countries CA's issue for citizen and business certificates.
>
>
>     While X509 allows you to specify different CA's for different
> purposes,
>     since the days of Netscape, browsers trust hundreds of root or bridged
> CA
>     in its trust repository for anything.
>
>     Neither commercial or government CA's are inherently more (or less)
>     trustworthy.  There have been trouble with CA's of all types.
>
>     A X509 certificate is a big integer number, in a fancy wrapper.  Its
> not a
>     magical object.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220311/da41f750/attachment.html>


More information about the NANOG mailing list