Handling of TrustCor Systems' root CAs

Handling of TrustCor Systems' root CAs

[Peter Müller]

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

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.

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.

Any opinions?

Thanks, and best regards,
Peter Müller

Re: Handling of TrustCor Systems' root CAs

[Michael Tremer]

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

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.
> 
> 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.

Best,
-Michael

> Any opinions?
> 
> Thanks, and best regards,
> Peter Müller

Re: Handling of TrustCor Systems' root CAs

[Peter Müller]

[-- 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

Re: Handling of TrustCor Systems' root CAs

[Michael Tremer]

[-- 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