From: "Peter Müller" <peter.mueller@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Handling of TrustCor Systems' root CAs
Date: Mon, 21 Nov 2022 14:30:12 +0000 [thread overview]
Message-ID: <a83171c9-5db1-0847-68db-1e43d457b2fd@ipfire.org> (raw)
In-Reply-To: <C67E1C62-03E7-44FF-A50C-FAFB3CCAF50E@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 3101 bytes --]
Hello Michael,
hello *,
> Hello Peter,
>
>> On 10 Nov 2022, at 10:39, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>
>> Hello development folks,
>>
>> well, I always hate it when the concerns expressed in blog posts of mine come true.
>> Alas, in case of the last one on DANE (https://blog.ipfire.org/post/global-pki-considered-harmful-a-plaidoyer-for-using-dane),
>> we now seem to have another textbook incident of a trusted, but rogue CA operator
>> likely providing TLS surveillance capabilities to government entities:
>> https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/
>>
>> Mozilla stated that it is currently investigating into TrustCor Systems' nature, and
>> would remove its root certificates from its trust store if questions sent to TrustCore
>> are not answered in a satisfying manner by November 22.
meanwhile, a TrustCor Systems representative provided some answers to the questions
raised (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4).
>From what I gathered, the common sentiment on the dev-security-policy mailing list is
that these answers were not satisfying - a sentiment to which I concur.
>>
>> We are probably not going to have a Core Update released before this date. Also, as
>> much as I would like to remove TrustCor Systems' certificates from the trust store
>> we ship, this would be a slippery slope: First, we would have _another_ thing we have
>> to maintain our own, and second, there are plenty of other dubious root CAs out there -
>> where do we draw the line?
>>
>> (To be honest, I am a bit surprised to see such TLS surveillance activity being
>> carried out through dedicated root CAs - to the best of my understanding, procuring
>> a trusted intermediate CA would have been a more stealthy approach.)
>>
>> I guess this leaves us with watching Mozilla's trust store closely, and adapt their
>> changes before releasing the next Core Update.
>
> Yes, I would say so.
>
> You mentioned the obvious reason before. Another one would be that it is not a good idea if some browser can open a TLS connection to some website, but IPFire cannot. That is unintuitive and difficult to debug behaviour.
Just for the records, mobile operating system GrapheneOS announced to unilaterally
remove TrustCor Systems' root CAs: https://twitter.com/GrapheneOS/status/1590621986044383232
Regarding intuitiveness, I would argue that IPFire machines establish a very limited
number of HTTPS connections to an (usually) relatively small amount of target FQDNs,
so the removal of a root CA used as little as TrustCor Systems apparently is is unlikely
to induce major side-effects. Given that HTTPS fetching tools are usually quite explicit
about untrusted certificates, debugging should not be too difficult.
Let's wait until tomorrow to see how Mozilla decides - should they choose to keep this
CA on board, we can always discuss whether or not we want to follow this decision. :-)
Thanks, and best regards,
Peter Müller
next prev parent reply other threads:[~2022-11-21 14:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 10:39 Peter Müller
2022-11-10 14:17 ` Michael Tremer
2022-11-21 14:30 ` Peter Müller [this message]
2022-11-21 14:44 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a83171c9-5db1-0847-68db-1e43d457b2fd@ipfire.org \
--to=peter.mueller@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox