From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Handling of TrustCor Systems' root CAs Date: Mon, 21 Nov 2022 14:44:54 +0000 Message-ID: <8BE7B344-5858-4994-B282-2445EE94A097@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5179427984494212997==" List-Id: --===============5179427984494212997== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Peter, > On 21 Nov 2022, at 14:30, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, > hello *, >=20 >> Hello Peter, >>=20 >>> On 10 Nov 2022, at 10:39, Peter M=C3=BCller = wrote: >>>=20 >>> Hello development folks, >>>=20 >>> 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/globa= l-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-ad= dresses-government-connections/ >>>=20 >>> 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. >=20 > meanwhile, a TrustCor Systems representative provided some answers to the q= uestions > raised (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX= 69KFvsm4). > From what I gathered, the common sentiment on the dev-security-policy maili= ng list is > that these answers were not satisfying - a sentiment to which I concur. >=20 >>>=20 >>> 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 tr= ust store >>> we ship, this would be a slippery slope: First, we would have _another_ t= hing we have >>> to maintain our own, and second, there are plenty of other dubious root C= As out there - >>> where do we draw the line? >>>=20 >>> (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.) >>>=20 >>> I guess this leaves us with watching Mozilla's trust store closely, and a= dapt their >>> changes before releasing the next Core Update. >>=20 >> Yes, I would say so. >>=20 >> You mentioned the obvious reason before. Another one would be that it is n= ot 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. >=20 > Just for the records, mobile operating system GrapheneOS announced to unila= terally > remove TrustCor Systems' root CAs: https://twitter.com/GrapheneOS/status/15= 90621986044383232 >=20 > Regarding intuitiveness, I would argue that IPFire machines establish a ver= y limited > number of HTTPS connections to an (usually) relatively small amount of targ= et FQDNs, > so the removal of a root CA used as little as TrustCor Systems apparently i= s is unlikely > to induce major side-effects. Given that HTTPS fetching tools are usually q= uite explicit > about untrusted certificates, debugging should not be too difficult. >=20 > Let's wait until tomorrow to see how Mozilla decides - should they choose t= o keep this > CA on board, we can always discuss whether or not we want to follow this de= cision. :-) Agreed. I hope they will remove it and then we can put this problem aside. -Michael > Thanks, and best regards, > Peter M=C3=BCller --===============5179427984494212997==--