Mozilla, Microsoft drop TrustCor as root certificate authority Mozilla and Microsoft have taken action against a certificate authority accused of having close ties to a US military contractor that allegedly paid software developers to embed data-harvesting malware in mobile apps. The CA, TrustCor, denies this, but has not responded to direct questions at time of publication. After a …
Oh, lordy! Pessimism radar pegging in the red!
Fair go, Mozilla and Microsoft et al may be acting entirely honestly. I mean, in an infinite universe I can't exclude that! But a few other scenarios refuse to remain quiet in my increasingly Nietzsche-esque mind.
1. They were all in cahoots, but were tipped-off that they were about to be rumbled. Then either TrustCor/Measurement Systems is hung out to dry as the actual perp, or as a patsy.
2. They were all in cahoots, but TrustCor/Measurement Systems narked someone off and "Man Overboard Plan A" was executed.
3. It was a <insert government agency> collaboration with TrustCor/Measurement Systems, but the big boys were cut out and so are "doing the right thing". (Who do we know with strong ties to Panama?)
The apps were pulled, though some have since returned to Google Play with the offending code removed.
=> The apps were pulled, though some have since returned to Google Play with the offending code steganographied. (Apologies for uncling my uncle. Tut tut!)
So do I.
A transparent and honest explanation, not just a "promise, we didn't do nuthin' wrong" explanation.
In any case, when you are root certificate, you should be above suspicion. That does not mean you shold not be suspected, it means you should do everything, continuously, to prove that there is no need to suspect you.
TrustCore has failed on that count, so its status as root cert should be revoked.
The VP of operations for TrustCor states no wrong doing and no relationships with defense companies so, if there is a USA spy op tied to TrustCor, I doubt anyone's inquiries are identifying anything... ever. I'm not implying TrustCor isn't guilty, I'm just saying you ain't getting shit out of inquiries.
FWIW, Ubuntu 22.10 still has 3 for TrustCor.
sudo dpkg-reconfigure ca-certificates
Turtles all the way!
It's blatant there are more parties involved. Did the CA engage an out-of-State developer for their own ends? If an official inquiry by [a higher authority] is not undertaken to identify those players, it's suggestible the [higher authority] is complicit. The production of a report will either be a clear whitewash or reveal those that are culpable. The plausibility of the findings, or lack thereof, will reveal much.
That doesn't mean SFA will actually happen as a result, as I also strongly doubt anyone's inquiries will produce anything. It kinda feeds my turtles!
FWIW, Ubuntu 22.10 still has 3 for TrustCor. +1
TLS and certificates are technically sound but the idea behind the certificate chain is fundamentally flawed.
Having entities like Google and Micros~1 decide who can issue certificates that users are supposed to trust does not really start that "chain of trust" on a very high level of trust for me.
I'd have much more trust in the security of communication with my bank if the bank would have given me a printed copy of the hashes of their certificates when i signed up for electronic banking so i can check the certificate on my own without depending on some third party (CA) that another third party (browser maker) decrees to be trustworthy.
I have no business with the CA and trust it less than i trust my bank so why should the CA be in a position to tell me whether my bank's certificate can be trusted?
As the typical customer of the bank is not even aware of how certificates work or can be checked they do not bother but just go ahead with that hand waving "you can trust our certificate because $CA said so", much less trustworthy and not secure but much less hassle and cheaper.
Do you trust an over-the-counter medicine
With over-the-counter medicine there usually is no third party that asserts its safe so i don't see the equivalent of a CA.
Its usually just the producer that makes claims that i either trust or not.
Didn't down vote you though, i think i see your point.
I have to admit that i do rely on my governments vetting process for behind the counter medicine while knowing the supervision of proper handling from production to the sale at the chemists is pretty inconsistent.
-> With over-the-counter medicine there usually is no third party that asserts its safe
That is not what over the counter means. It means that you are not able to buy it directly without approval from the pharmacist. They don't generally tell you it is safe, they say that it is not unsafe.
I'm not trying to have an argument, but I was looking for an analogy which would be suitable. I think we can agree that most people are not competent when it comes to computer security, and in general I do not expect them to be. Hence somebody more competent needs to be able to tell somebody that something is "safe" (very questionable term, I agree).
No one – not a single person – would be able to routinely verify TLS entity certificates under normal use. Few people can even list all of the required per-certificate and chain checks (name, validity dates, basic constraints, KU, EKU, CA/BF requirements, ...) and variants (SAN vs CN, if you want to support X.509v1 or poorly-issued v3; BC vs chain length, again if you want v1 support; entity-name wildcarding; ...), to say nothing of the shambling horror that is revocation. Even if you have a very restricted trust store and reject out of hand certificates that don't meet a stringent set of requirements, it doesn't scale.
Even moderate interoperability with PKIX is very much an arcane specialization. Applications which roll their own checks nearly always get it wrong.
I doubt any one person could run a root-certificate program competently, for general PKIX use. Look at what goes into the CCADB. Just try to follow MDSP on a regular basis, to say nothing of the CT logs and the like.
The simple fact is that the major root-certificate programs, and now the CCADB, are the least-terrible form of X.509-based PKI management for the Internet that anyone's been able to come up with so far, flawed though they are.
With over-the-counter medicine there usually is no third party that asserts its safe so i don't see the equivalent of a CA.
Its usually just the producer that makes claims that i either trust or not.
Au contraire...
The FDA / MHRA / [your nation's drug approval agency] is the one making exactly this assertion. Just because it's over-the-counter doesn't mean it's unapproved, unregulated by a third party.
Not being a native speaker i assumed over-the-counter would cover thinks like dietary supplements that do not have special restrictions but can be sold like other food and behind the counter being things only a pharmacists may hand out (and in some cases only when you have a prescription).
Looks like my assumption was wrong, at least in this case the damage was limited to el reg's forum.
Thanks for pointing out my mistake (allowing me to learn from it).
Well, you're not incorrect, you're correct. Over the counter does mean no prescription necessary, such as vitamins and lotions.
FWIW, the term, as used in the United States, originated in firearm sales where everything under the counter was "special" (which much later on led to a special tax).
Things like dietary supplements and food also have government regulators asserting that they are safe.
The exact details of what "safe" means and how that's checked vary greatly between jurisdictions, of course.
This is vaguely similar to whether it's Microsoft, Mozilla, Apple, Debian etc providing the root certificate list.
> Not being a native speaker i assumed over-the-counter would cover thinks like dietary supplements that do not have special restrictions but can be sold like other food and behind the counter being things only a pharmacists may hand out (and in some cases only when you have a prescription).
The phrase written by @VoiceOfTruth was (emphasis mine):
> Do you trust an over-the-counter medicine ...
The key word is actually medicine. For something to be labelled a medicine it has to be approved by the relevant countries equivalent of the FDA. Dietary supplements are most definitely not medicine, in fact it would be illegal to label them or advertise them as medicine. That's why they are called supplements rather than medicine.
No, not without doing research and knowing what the drug is, understanding its method of action and its common and rare side effects. The same goes for hygiene products... I want to know what's in my mouth wash, for example. Both "medical" and "non-medical" ingredients, because often that's disingenuous too (e.g. listing methyl salicylate as a non-medical ingredient as if it's just wintergreen flavouring)
I don't trust Microsoft, Google or Mozilla, for that matter, to decide who I don't get to communicate with. Why should I trust the certificate authorities? They can only revoke a certificate after some tomfoolery has occurred. I don't really have much choice as that's the way we're set up, but I don't have to like it.
> does not really start that "chain of trust" on a very high level of trust for me.
Indeed not. For decades I've been disabling the pre-installed CA certs on my devices and only reenabling those I actually need and trust.
I can understand why vendors might want to ship them all enabled (though I'm not sure why say a Catalan localisation of Mozilla needs to ship with trust enabled for some Turkish bank's CA) but they shouldn't make it such a pain in the arse to disable the lot in one go.
> In your world Spanish people are not allowed to visit Turkey
In my world people of whatever nationality that use a Catalan localised browser would have to explicitly enable CAs with which they are statistically unlikely to interact in a legitimate situation.
Did you post your comment just to be facetious or do you really not understand how the technology works?
"I'm not sure why say a Catalan localisation of Mozilla needs to ship with trust enabled for some Turkish bank's CA)"
Two problems. First, it's not the bank's CA. That bank's certificate will be signed by a much larger root CA. My version of Firefox has 78 of those. They don't exactly hand them out to everyone, including Turkish banks. You need to prove quite a lot before you can issue certificates rather than just get some from an existing authority and use them.
But let's say there's one of these that's basically only used in Turkey. Why should the Catalan localization include it? Because if the average web user has to enable each new CA the first time they see it, they're going to get used to clicking the trust button on new CAs way too often. Yes, many won't use the Turkey-limited CA because they won't use any sites based there, but they'll have a reason to visit a Romanian site. And someone else will enable a Pakistani CA because they wanted to see something hosted over there. Someone in Catalonia set up a website of their own but used an Australian CA because their domain provider suggested it (or is it), so all their users will need to enable that one. And someone else speaks Catalan at home but moved to Sweden, so they'll have a few to turn on. And someone else set up that version as a way of practicing the language but lives in Senegal. If all of these people get used to trusting things their browsers wouldn't, then when they get a phishing site with its own untrustworthy CA, they might be more willing to trust that site's CA because they've been taught that sometimes you have to click that button for sites to load. That phishing site is now free to redirect them to more convincing fake pages which their browser trusts.
> First, it's not the bank's CA
I can't be bothered to look now but there is, in Firefox's certificate store, a CA cert from some sort of Turkish bank. Take a look under "T". Whoever has access to that certificate's private key can sign any X.509 certificate in the world.
> Because if the average web user has to enable each new CA the first time they see it, they're going to get used to clicking the trust button on new CAs way too often.
I have exactly *five* CAs enabled in my browsers. Save for a US government website a few weeks ago, it's been more than five years since I needed to enable a CA.
Truth is, people tend to visit a very small part of the web.
Could the user experience be improved? Yes, probably. Through education at an early age would be a good start, same way children learn to wait for a green light before crossing the road.
"I have exactly *five* CAs enabled in my browsers. Save for a US government website a few weeks ago, it's been more than five years since I needed to enable a CA."
So you've had to enable one five times. You know what you're doing when you do that, but most users do not. If they have to do something five times (per device and browser), it becomes a thing they expect. Not to mention that some people use a lot more of the internet. I routinely visit sites hosted in a lot of countries, usually small personal sites by people running technical projects. As geographic and linguistic diversity also brings CA diversity.
There is no harm in you disabling all the CAs. There is some in doing that to people who won't know what that means and might be trained to bypass certificate warnings by doing so. Browsermakers are better at judging certificate trustworthiness than a child who only understands "If I press this button, the site loads" or adults who in my experience manage to understand even less and damage more.
"I can't be bothered to look now but there is, in Firefox's certificate store, a CA cert from some sort of Turkish bank. Take a look under "T"."
Challenge accepted. I think I found it:
Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK
I don't speak Turkish, so this looks like a lot of scary words. Let's see what it translates to:
Scientific and Technological Research Council of Turkey
That doesn't look like a bank, but maybe it's a front for one. Let's see who runs it: www.tubitak.gov.tr. So not a bank. A part of the Turkish government. Now maybe we don't trust the Turkish government, but there is a difference between that, a bank, or every bank out there. Incidentally, that is not the only one run by a government entity of some sort.
> You know what you're doing when you do that, but most users do not.
If I know what I'm doing that is because I received proper education on this point. There is no reason why other people cannot be educated as well.
> Not to mention that some people use a lot more of the internet. I routinely visit sites hosted in a lot of countries, usually small personal sites by people running technical projects. As geographic and linguistic diversity also brings CA diversity.
I didn't mention this, but I conduct my daily business in five languages (out of a total of eight that I can speak). And, probably because of US hegemony and tech dominance, five CAs cover my entire web space.
Let's talk specifics. How many CAs do *you* require? It'd be interesting to have more than one data point.
You talk about the education of others, you make various claims and assertions, but just a couple of posts ago, you couldn't be bothered to do the handful of clicks needed to check that what you were writing was, in fact, false.
As it happens, the people you condescendingly think need education, they're just like you: they can't be bothered.
> you couldn't be bothered to do the handful of clicks needed to check that what you were writing was, in fact, false.
False? In what way? In that it may not be a bank but some other entity? So what? It's hardly relevant to the point, which is that you should not ship every CA under the sun enabled because *some* user may need it.
> the people you condescendingly think need education
Since when is advocating for education "condescending"??? Is that really what you think of the value of education?
Whoever has access to that certificate's private key can sign any X.509 certificate in the world.
Anyone can sign any certificate they want. That's how certificates work.
A CA that's in the Mozilla root program that signs an entity certificate for an entity they shouldn't be signing for would be quickly detected by CT, and required to revoke that certificate and address whatever underlying issues led to signing it, or they'd be removed from the program.
I too believe there are too many CAs in the major root programs, but the situation is not nearly as simple as you make it out.
(And your scenario is wrong anyway. An entity certificate signed directly by a root would raise all sorts of flags. The actual attacks would be signing a new intermediate with the root, or compromising an intermediate's private key. But both of those are less likely than easier attacks such as legitimately signing certificates for entities with similar names, or simply compromising a legitimate host.)
> the situation is not nearly as simple as you make it out.
Just wondering, who is "you" in this context?
I find ElReg's new threading system pretty nightmarish to locate the parent post. That's why I try to quote whatever I'm replying to.
Good point about certificate transparency though!
I have no business with the CA and trust it less than i trust my bank so why should the CA be in a position to tell me whether my bank's certificate can be trusted?
The idea is that the CA's are so well-known and so universally trusted that the trust is implicit.
If a CA ever did anything that showed it to be untrustworthy then that implicit trust would be withdrawn and they would cease to be trusted by default as a CA.
... which is what's happening here.
I say "by default", above, because the fact that the CA's root certificate isn't handed to you as a de facto default, trusted, certificate doesn't stop you adding it to the browser's certificate store yourself.
The idea is that the CA's are so well-known and so universally trusted that the trust is implicit
Nice idea but most people won't have heard the name of any but the biggest CA's that come with their browser or OS.
I just had a look and found that e.g. "Starfield Class 2 Certification Authority" is trusted both by my browser (LibreWolf, about:certs) and Windows 10 (see certlm). If i asked the next 100 random people in the street i believe i would not find even a single person that knows in what business "Starfield Technologies, Inc." is.
"Universally trusted and known" in reality boils down to "trusted by Google and Microsoft and Apple (and some IT security experts)".
"Universally trusted and known" in reality boils down to "trusted by Google and Microsoft and Apple (and some IT security experts)".
Well, yes. The problem with certificate trust is that the average person or even the generally technical person doesn't automatically know what's trustworthy, so people who know a lot more about that provide a prebuilt mechanism that answers that question completely and can be changed to fit the desires of any user who wants to do that.
Just as we assign the job of deciding whether medicines are safe to people trained in pharmacology and statistics, and in most cases take their word for it, the decision over certificate trust can be made by experts. People are free to do something either set of experts hasn't reviewed or approved, and sometimes it will be fine, but sometimes it won't be. If those experts have gone far enough to recommend against something, they probably know what they're talking about.
"people who know a lot more about"
That's a joke, isn't it? Who are *paid a lot more* and sit in suitable governmental position. Like a subcontractor to DoD, like in this case.
Whole CA system is mined by US government and it's basically meaningless by now: Any US TLA organisation has full access to everything via root cert US corporations are pushing by force to everyone, globally.
I think if root certs were being abused there would be more evidence of this wouldn't there?
The way prism was set up seems to indicate that this isn't true.
Unless I've missed something.
Not that they couldn't abuse it, I'm sure, but I've seen nothing to indicate they do, and they'd probably prefer less visible attacks than swapping out certs on MITMd traffic
There is evidence for CA's handing out intermediate certificates to organizations that abuse them to sign fake certificates to allow monitoring traffic.
One example would be this article.
Google has found a number of such things. That is probably because Google is in a pretty unique position being able to pin their own certificates in their browser and have experts on hand to investigate any reports. I believe this happens a lot more often than is publicly known.
I'm sorry, I was more referring to US, (and partly UK), but the context of the post I was replying to US and definitely should have been clearer.
You are right these get abused, or root certs added by govts or root certs added by software.
But what I haven't seen before is, say, evidence American TLA's doing that because there are softer and more deniable targets.
"Who are *paid a lot more* and sit in suitable governmental position. Like a subcontractor to DoD, like in this case."
Please reparse the original statement. Who are the "people who know a lot more"? It's not the issuing CA. It's the browsermakers or OS cert providers. The people who knew enough to detect dodginess, were paying attention to figure it out when I and I'm pretty confident in saying you, were not diving into this company's actions, and the people who took the action to block it. Even though I work in security and I'm guessing you have a technical background, I have not studied the administrative background of CAs, which these people are doing. Yes, they know a lot more than a lot of people, including us.
The problem with certificate trust is that the average person or even the generally technical person doesn't automatically know no one knows what's trustworthy
FTFY.
Not that "trustworthy" is a useful criterion here anyway. Membership in a root program for widely-used applications is far more complex than a boolean "Alice is trusted, Bob is not".
The idea is that the CA's are so well-known and so universally trusted that the trust is implicit.
Perhaps at one time, and naively, but that's certainly not the guiding principle behind the major root programs or the CADDB now.
In contemporary PKIX, trust (for the root programs, etc) is based on continually satisfying various criteria (CA/BF Base Requirements and the root-program additional requirements, among others) and review, some of which is largely automated (e.g. CT), and some largely manual (e.g. MDSP).
This is exactly the problem that web3 will face in the future. PKI was originally intended to be a decentralized system with each person managing their own keyring of trusted keys. Such as system becomes unwieldy pretty fast for general members of the public, so authority becomes centralized into organizations that will do it for you.
Web3 is touted as being decentralized, and allowing individual fine-grained management of your own data. Members of the public will not want to have to mess around with fine-grained data permissions and so will "outsource it" to companies that offer to do it for them. Then oh look, we are back where we are now.
PKI was originally intended to be a decentralized system with each person managing their own keyring of trusted keys.
This is not historically correct.
There are many possible PKI architectures. PKIs were being discussed in public as far back as the 1970s when asymmetric cryptography appeared in the public research; it's hard to believe they weren't discussed in private at GCHQ (and possibly other government agencies) before that.
Some of the proposals were no doubt for decentralized PKIs, but many of them assumed centralization. Decentralized PKIs really only became a popular topic with PGP, which Zimmermann published in 1992.
PKIX was only standardized in 1999 (RFC 2459, currently superseded by 5280). But PKIX notes that PEM used a hierarchical PKI in RFC 1422, which replaced RFC 1114, from 1989 – three years before PGP's "web of trust". And PKIX (RFC 5280) itself allows alternative, non-hierarchical topologies.
PKI topology has been an area of research and debate for nearly half a century (at least). It's not a case of "originally it was going to be a people's topology, but then the Man took over".
I'd have much more trust in the security of communication with my bank if the bank would have given me a printed copy of the hashes of their certificates
And when those certificates are renewed, as should happen in about a year at the most, and is increasingly happening more often (short-lived entity certificates becoming the norm)?
They could give you the fingerprint of the public key, which would at least make a bit of sense. That's what HPKP did, though, and in practice it was a bit of a disaster, and is now deprecated in favor of CT.
And, of course, nothing stops you from implementing your own HPKP mechanism (which will have the same failure modes), or following the CT logs.
PKIX is a mess, and the major root-certificate programs include far too many CAs for my liking (though conversely concentrating too much of the CA power in a handful of entities – 90-something percent of TLS entity certificates are signed by one of five CAs, and nearly half by ISRG – is not great either). And initiatives like QWAC will make it worse. But making every end user responsible for deciding what CAs to trust 1) is already possible (you can change the trust stores for browsers and most other applications, aside from crap mobile apps that have much bigger security issues), and 2) is a complete non-starter for the vast majority of users.
-> "Microsoft gave us no advance notice of this decision," McPherson said.
Company connected to malware enablement complains about a lack of advance notice. What next? Tell burglars there are police waiting at the address they are going to burgle?
To burgle -> To burglarize in non-conformant English.
If TrustCor is an untrustworthy as the evidence appears to be then Microsoft and Mozilla have done the right thing by disabling their root certs. But unfortunately since MS and Moz browser share combined is only about 10% of active browsers according to most stats, it really needs Google and Apple to act to since they control the two most widely used browsers and mobile OS.
Chrome uses the OS provided certificate store by default, so Microsoft revoking it covers Chrome on Windows. (And the majority of Chromium-based things like Edge and Electron)
It's reasonable to assume the rest will be revoking it momentarily - Apple clearly already know, but are probably waiting for their next scheduled update.
Which leaves Android and the major Linux distros. It's very unlikely they'll leave it active for long either.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
