public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Handling of TrustCor Systems' root CAs
Date: Mon, 21 Nov 2022 14:44:54 +0000	[thread overview]
Message-ID: <8BE7B344-5858-4994-B282-2445EE94A097@ipfire.org> (raw)
In-Reply-To: <a83171c9-5db1-0847-68db-1e43d457b2fd@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 3377 bytes --]

Hello Peter,

> On 21 Nov 2022, at 14:30, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> 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. :-)

Agreed. I hope they will remove it and then we can put this problem aside.

-Michael

> Thanks, and best regards,
> Peter Müller



      reply	other threads:[~2022-11-21 14:44 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
2022-11-21 14:44     ` Michael Tremer [this message]

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=8BE7B344-5858-4994-B282-2445EE94A097@ipfire.org \
    --to=michael.tremer@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