From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Handling of TrustCor Systems' root CAs Date: Mon, 21 Nov 2022 14:30:12 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2860288985181055824==" List-Id: --===============2860288985181055824== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, hello *, > Hello Peter, >=20 >> On 10 Nov 2022, at 10:39, Peter M=C3=BCller w= rote: >> >> Hello development folks, >> >> well, I always hate it when the concerns expressed in blog posts of mine c= ome 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 o= perator >> likely providing TLS surveillance capabilities to government entities: >> https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-add= resses-government-connections/ >> >> Mozilla stated that it is currently investigating into TrustCor Systems' n= ature, 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 que= stions raised (https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69= KFvsm4). >>From what I gathered, the common sentiment on the dev-security-policy mailin= g 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 tru= st store >> we ship, this would be a slippery slope: First, we would have _another_ th= ing we have >> to maintain our own, and second, there are plenty of other dubious root CA= s 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 ad= apt 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 no= t 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 unilate= rally remove TrustCor Systems' root CAs: https://twitter.com/GrapheneOS/status/1590= 621986044383232 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 qui= te 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 deci= sion. :-) Thanks, and best regards, Peter M=C3=BCller --===============2860288985181055824==--