Web trust dies in darkness: Hidden Certificate Authorities undermine public crypto infrastructure Security researchers have checked the web's public key infrastructure and have measured a long-known but little-analyzed security threat: hidden root Certificate Authorities. Certificate Authorities, or CAs, vouch for the digital certificates we use to establish trust online. You can be reasonably confident that your bank …
…to scare people isn’t exactly a new marketing tactic in computer security.
A root certificate is trusted or not. That people can generate root certificates is not new. Calling them “hidden” is the novel part of this research…
I can easily believe that there are 1 million untrusted root certificates that are used for VPNs and private networks that someone trusts, but I don’t.
I use my own self-signed root cert for IMAP access from outside my LAN on a public IP (SSL only of course). I had to add it to the Android device I read e-mail with when I'm out and about. That would be a legit use of such a cert. I am sure there are many others doing things LIKE this.
"We discovered that a Windows Trojan implanted root certificates disguised as SecureTrust CA 2 into infected hosts"
This of course is a malicious use of such root certs.
So, are Firefox, Chrome, Android, and maybe OTHER browser/mail-reader makers going to offer a utility to tell you which root certs are installed that are NOT in their approved list (and let you delete them)? Maybe add a "scan root certificates" function to let users easily do that from 'settings' ???
It sounds like a legit feature request. So what if it causes trouble for firewall appliances. Let IT managers deal with the aftermath. "Security Now" is a better plan, along with more end-user flexibility and control
So, are Firefox, Chrome, Android, and maybe OTHER browser/mail-reader makers going to offer a utility to tell you which root certs are installed that are NOT in their approved list (and let you delete them)?
Of course not. If you look at how any of the browsers work, they all pass the request to the OS for it to do the SSL bits. Most browsers have no idea which certs are trusted and which aren't.
Then we get to the corporate environment. If you're running Windows in a corporate environment the domain controller WILL have injected it's own cert. How many support calls would most help desks have if that feature was enabled ?
Their use of the term hidden has nothing to do with the certificate's local level of trust, but rather whether they are trusted by a public root programs, and also the certificate's visibility. If you'd bother to read the article, you'd see the reasoning behind the chosen terminology, which seem reasonable:
"In this study, we term root CAs that are not trusted by public root programs as “hidden” root CAs, because they are absent from the lists and are not publicly visible. Particularly, we focus on hidden
root certificates that have been imported into local root stores [...]"
When you first deploy many OS's, appliances, active directory, HTTPSi middleboxes, or software that has a HTTPS portal, the install process will generate a self-signed certificate to use for HTTPS connection.
A self-signed cert is also the definition of a root CA certificate.
It is up to the admin to replace that self-signed cert with a cert signed by a public CA, internal corporate CA, or leave it as it is.
Some of these roots might be such portals but the researchers clearly point out they found leaf certs being issued and this is very worrying.
The research should continue but it is very difficult to find a technical solution to what is ultimately a human issue.
As it's not one vulnerability, the answers to your questions can vary.
"What can actually happen to me or my system and how?"
The standard risk is that a certificate that your system trusts can be used to impersonate something else, either breaking encryption on a connection of yours or diverting that traffic. This requires that the attacker has malware on your system or controls a link in your network. Malware is the more likely option here, though it must be noted that local malware could do nasty things to ongoing connections anyway. Such certificates could also theoretically be used to make your system trust a binary that isn't signed with a key your OS provider normally would trust, although the paper is talking mostly about network certificates here so that's probably not the risk they have in mind.
"How can I protect against such 'bad' events?"
You could analyze a lot of your typical traffic and see if anything unexpected happens, but that will likely take a long time. Since the primary risk is malware, scan your system frequently to eliminate it should it become known.
"How can I check my systems to see if they are vulnerable and/or compromised already?"
Most things that have root certificates stored somewhere will allow you to view and edit the list. You could go into your network configuration (search for the instructions for your OS) and start auditing your certificates. The problem here is that, when you find something in there that doesn't appear on a list of trusted certs, you may not know where that came from. You could look for some of the red flags discussed in the article such as long cert lifetimes or you could delete the cert (keeping a backup copy) and see if things break. This takes a lot of time and effort and may not be needed in many cases.
on Linux and FreeBSD it appears that the cert list is protected.
OpenSSL has a utility 'certctl' for things like that.. 'certctl list' to see them.
on FreeBSD the files are in /usr/share/certs and it's writable only by root.
(I scanned the files and they all all read-only owned by root)
I would surmise that there is the ability to load local versions of these certs to extend the list. Firefox lets you add additional certs, for example (and it may have its own separate list)
> What can actually happen to me or my system and how?
Your main risk is being man in the middled.
> How can I protect against such 'bad' events?
A basic but fairly effective step is to manually disable / remove trust from all the CAs in your browser, email client and if applicable, operating system list of trusted CA.
As you browse the web and go through your daily routine, re-enable only those that are actually used by you, after satisfying yourself that they "make sense" (e.g., if visiting an Estonian government website you may expect an Estonian CA to have signed the site's certificate, but if you're trying to browse the BBC this is rather less likely).
After about a week you would have re-enabled 99.9% of the CAs that you need for your routine browsing / working habits. The expect to be shown the odd certificate warning when visiting an unfamiliar website a couple of times a year, then use your judgement to decide whether and how to proceed.
The structure of the certs aren't exactly the same, as part of the cert defines what the cert can be used for, and many applications will treat a root signing cert as invalid if submitted for a different role. Most apps these days will also pop a warning that it is not itself countersigned by another CA that is already in the trust store.
Once you add a bogus root though, you're screwed because that cert can be used to generate a spoof of any cert, for any site, and for any purpose.
SSLs math is sound, but it's logic of trust is, and remains, fatally flawed. As a result, the state backed CAs of the worlds repressive governments have been caught with their hands in the cookie jar issuing fake certs to MITM traffic to each other and the biggest sites on the internet.
So now Chrome uses pinned certs and will block connections if it see's a forged cert for Goofabet domains. Your banking sight might not be so lucky.
Fixing this means fixing the trust model, by allowing domains to declare or designate their CA's and only trusting certs for a domain that are signed by a designated authority. Annoyingly, this isn't even that hard to implement, but the bad faith actors like verisign and godaddy have enjoyed getting rich of the status quo.
A self-signed cert is also the definition of a root CA certificate.
No, it really isn't.
A root CA certificate is a certificate belonging to an entity (a root CA) that signs certificates for other entities (CAs) who can themselves sign certificates (for other CAs or for end users). Such a certificate will be self-signed, yes, but end user certificates can also be self-signed.
It isn’t a defining property of a root CA that it sign intermediate certificates - although public CAs always will, and most well managed internal ones too, so that the long term trust can be in an offline key.
A root CA is just a self signed cert with basic constraints CA: true. That is still true even if it has never actually been used to sign any other certificate.
Good summation - yes, that's exactly the issue.
It's a bit of a shame the paper doesn't seem to mention name constraints. I'm not clear when they talk about self-signed roots being generated by organizations to sign their own sites (internal or external), are those self-signed roots limited to a specific domain? Or are they universal?
To me it seems very reasonable for the browser to warn about any root certificate not managed by the browser that is universally applicable to any website. Those sound like a serious problem and I would always want to know about those. A root certificate issued only for ".blah.gov" or ".lan" or whatever is much less so.
https://en.m.wikipedia.org/wiki/DNS_Certification_Authority_Authorization
This is meant to make scrupulous Certificate Authorities not generate a certificate unless it's in an allow list, but could easily be deployed to make sure only the correct authority has authorised a certificate ...
...the article probably didn't do that because it's, uh. complicated. I wrote a blog about it six years ago:
https://www.happyassassin.net/posts/2015/01/12/a-note-about-ssltls-trusted-certificate-stores-and-platforms/
it hasn't changed too much since then. and that doesn't even really cover Windows at all...
For Google:
https://groups.google.com/g/mozilla.dev.security.policy/c/3Q36J4flnQs/m/VyWFiVwrBQAJ
https://g.co/chrome/root-policy
https://g.co/chrome/root-store
https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/net/data/ssl/chrome_root_store/store/certs/
For Apple
https://www.apple.com/certificateauthority/ca_program.html
https://support.apple.com/en-us/HT209143
https://support.apple.com/en-us/HT212773
https://opensource.apple.com/source/security_certificates/security_certificates-55188.80.4/certificates/roots/
For Microsoft:
https://docs.microsoft.com/en-us/security/trusted-root/release-notes
https://docs.microsoft.com/en-us/security/trusted-root/program-requirements
https://ccadb-public.secure.force.com/microsoft/IncludedCACertificateReportForMSFT (from https://ccadb.org)
I can say with authority that in an enterprise environment, group policy is frequently used to hand out certificates for things like MitM web filter proxies and other systems that use their own internal CA sub-system. (Call Manager, vCenter, etc.)
For Active Directory Certificate Services, the root and issuing certificate authorities have their certificates published to active directory, and it's pushed out to domain-joined computers.
Most of the internal CAs are a result of vendors putting out a "no touch" solution, and changing things out is... a bear. Don't know about Call Manager, but VMWare specifically says to leave their CA alone unless there's a specific requirement otherwise; from having to deal with it in the past, I believe them.
This is a very important question.
Traditionally, human trust is a personal decision derived from experience - you know a person for some time, have observed their behaviour, and come to the conclusion that you can reasonably reliably predict that behaviour in response to envisaged circumstances. General trust in things like currencies is based on a similar - if group - experience of predictability.
In the digital domain, 'trust' is little more than acceptance of assertions that can not be independently verified. So, for example, when DigiNotar was breached and certificates for Microsoft (and even, believe it or not, *.com) were illicitly generated they were 'trustable' because they were authentic (in the sense they were valid certificates) despite being fraudulently created. There's absolutely no way a person browsing the web can validate the probity of a root CA or the assurance it actually provides of the probity of organisations to which it issues certificates. So in reality, can any certificate actually be trusted, or is acceptance merely thrust on us?
Would you pass your credit card details to some unknown guy just because someone else you'd never met told you remotely that the guy could be trusted?
Would you pass your credit card details to some unknown guy just because someone else you'd never met told you remotely that the guy could be trusted?
You do this every time you use a credit card in person, too. It's actually the entire point of all payment systems.
You don't know the cashier and you don't know anyone at Visa Mastercard or Amex either.
You might possibly know a bank manager at the bank who issued the card, but probably not.
The trust comes from your contract with the bank, and any applicable law that requires the bank to refund fraudulent transactions. It doesn't come from actually knowing any of the individuals concerned at all.
Which means ultimately it comes from living in a country where the Government respects the rule of law.
And got a slap on the wrist for offenses that other CAs were removed from the trust store for. Same with Symantec. The problem is that when a CA gets a significant enough market share, removing their trust flag will break too many websites and clients will complain, so even Google with its Chrome monopoly cannot afford to drop the hammer.
Actually, a couple of their CA roots got burned from the big trusted root lists, and they had to backwalk their cavalier disregard for CA operations. Plenty of admins also ripped them from the trust stores on the systems they run, which was more for their benefit than any impact on the company, but most people that did that will also vote with their feet and strongly suggest using another CA instead. So it hurt their reputation and their bottom line.
I was in favor of stronger medicine. I think an example should have been set, and their CA operations permanently revoked.
And banking itself. When you deposit money the bank isn't 'looking after it for you'. You are actually giving the bank your money. You hope/assume that they will honour their side of the contract which is to give you some of their money when you ask for it.
In the digital domain, 'trust' is little more than acceptance of assertions that can not be independently verified.
Trust, in the digital domain, doesn't mean what most people want it to mean.
If I receive a signed messaged from someone called Fraudulent Frank, and the certificate supplied with the message comes from a reputable CA, and verification says that I can "trust" this certificate ... that means that the CA confirms that the sender of the message really is Fradulent Frank, not that Frank himself can be trusted.
In other words: I can trust the CA when it confirms Frank's identity, but I still don't know whether I can trust Frank ... would you?
But I assume I can trust Microsoft or Apple not to steal my credit card (cos they have more money than me) I need to trust that the link is to microsoft.com and not to m(unicode i)crosoft.com with https signed by Honest Achmed's discount camel store and root CA in North Cyprus
(note does not apply to Oracle, they have more money than me but would steal my lunch money out of general principles)
Most companies have internal PKIs with their own "self-built" root CAs. The trust is obviously limited to the company itself. How are you going to generate and provision automatically certificates for thousands and thousands of devices? Nor you can obtain certificates for LAN IPs - or domains which doesn't use a valid TLD
Once the certificate is for a fqnd what the fqdn resolves to it's up to the DNS. As long as you use a valid TLD, you can get a certificate and use it as you like.
Yet I have certificates which have IPs as alternate names - because for different reasons those devices need to be able to establish a trusted TLS connection even when accessed using the IP address. For example DoT/DoH requires certificates with IP addresses, since DNS servers are accessed using their IPs and not a fqdn...
Unless you're implementing a piece of software that uses openssl, you don't *need* to understand it, and probably shouldn't even try, since it's a gigantic swiss army knife. That's like asking if you understand grep or vi or ffmpeg -- no, I know what I need daily, and look up the rest the once a year I might need it, I don't need to memorize every command they have.
With two basic OpenSSL commands you can have a reasonably secure private PKI infrastructure up and running in minutes.
If you don't understand it, you're probably going to have a bad PKI infrastructure, and risk to follow the wrong/bad/outdated tutorial. One doesn't really need to understand all the nuisances of a PKI - but a solid grasp of the main requirements is needed - it's not a five minutes course, but it won't take weeks either.
What is difficult?
you can understand it in 10 secs
Theory
---------
generate a root cert which is arbitrarily "trusted" for use in your environment
Generate an intermediate cert which used the root to vouch for it (you could skip this but i wouldnt much easier to revoke and swap out an intermediate cert than a root)
Generate a client cert which uses the intermediate to vouch for it
Verify the client by checking each cert in the chain vouches for the one beneath it
Practical
------------
1) generate root cert using a strong cipher suite and as big a key as practical
2) generate an intermediate cert using the root cert
3) issue a cert using the intermediate for signing
learning openssl's cli takes a bit longer but conceptually its as complicated as lego
I agree doing it properly and setting the associated systems (CRL's, distribution points etc.) is a lot harder and does require indepth specialist knowledge, but getting enough of an indicative system up and running to use in a dev environment is trivial and not at all complicated
I agree doing it properly and setting the associated systems (CRL's, distribution points etc.) is a lot harder and does require indepth specialist knowledge, but getting enough of an indicative system up and running to use in a dev environment is trivial and not at all complicated
I think that was the point- if you are setting up a PKI for in house companies, you want to do it right the first time, because it's a pain in the anus to fix it.
I "inherited" the PKI hat at [RedactedCo] a number of years ago, and it was a train wreck from lack of maintenance, and from the fact that it was built with one purpose in mind but got repurposed for something else entirely. We ultimately ended up retiring it and stood up a new one along side it that's moderately future proof and also documented the living hell out of it, so that if I get hit by a bus or retire, whoever takes my place has at least a half clue about it's care and feeding.
openssl is a beast to get right, and while I take your point that a few cut and paste commands will get you to a self-signed cert in a dev environment, that is part of the problem.
How many products were shipped with a borked SSL config, or leave it to the end user to fix and manage? How many of those devs or users know how.
If you run an SSL/TLS validator, you will see just how broken some of those certs are, and not just on a trust level. Having had to re-tune the SSL handshaking and cipher settings on a few times now, I can say that you do kind of need to know what you are doing, or have really good instructions. And sometimes there are just trade offs, where changing the settings may break compatibility with certain classes of devices.
Even with a grasp of the underlying protocol and cert structure, the openssl syntax is not intuitive at all, so I have to triple check the results to make sure I didn't fat finger anything on a command that is almost always wrapping off the screen.
Yep hence last paragraph, getting it right is tricky, getting something that's good enough to get work done is trivial, 99% of an apps ssl tuning is in its config, so as long as your using the lib correctly it will dovetail into a properly configured pki infrastructure as well as a Rinky-Dink localhost ca...
Network spy appliances used to be sold featuring some of those wildcard certificates to intercept / modify / inject all user traffic - only effective if there is important stuff in the computer / network being targeted, or if the user doesn't know he is being spied, otherwise it is pretty much useless.
Wonder if they stil sell them. Forgot the name of the company.
You can do it even with Squid:
https://wiki.squid-cache.org/Features/SslPeekAndSplice
Anyway, you may want user know even their SSL/TLS traffic might be inspected - not only you want to limit the options someone with evil intent could use, you also want to avoid people doing silly thing just because they're lazy - i.e. sending/uploading sensitive information to external servers like their private dropbox disks or mailbox.
The Cisco Web Security (aka Ironport) appliance and Umbrella both have that feature as well- it effectively performs a man-in-the-middle on the SSL chain. The deployment instructions state that you are supposed to deploy the root certificate it generates to the workstations as a trusted root via your favorite bulk deployment tool (group policy, SCCM, etc.).
The down side is that it does screw with the various TLS protocols, and causes a BUNCH of other administrative hassles.
Yeah, though the version where the company bought a shady wildcard cert from a trusted CA is the bigger threat. At least the usual version of that idea requires local access to add the cert to the trust store on each devices, so companies can push it out to devices they control, but a visitors device will flag it as untrusted.
Unfortunately managing those certs is still a pain, so Bluecoat's sales drones convinced the company to utterly violate internet security standards by getting a "magic cert" installed that could spoof any host w/o triggering a trust warning.
If you can easily re-deploy the CA itself that's not a problem. If I'm a company and I fake certificates for HTTPS inspection, the CA that generates that certificates just need to be deployed to clients, and companies have the infrastructure to do this quickly. Just it needs to be a separate CA for that task - not one of the company main CAs.
That's different from the browser built-in CA where changing one is far more complex.
I have 3 CAs on my home network (MS Active Directory, oVirt & pfsense) but none of that makes them sinister or even particularly hidden. I've always thought that the long list of CAs my browser trusts is intrusive.. why do I implicitly trust all this organisations I have never heard of or know anything about? I get that we have 'outsourced' the decision on what CA is to be trusted to the browser/OS programmer - indeed we are trusting any application from a security point of view when we execute it so I guess my point is moot..
Any how exactly does the current long list of trusted roots we are supplied with fit into the zero trust model..? feels a little like a contradiction.. surely we should be trusting certificates on a per certificate/application basis and not at a higher level.. anyways...
There is space for an EFF project here.
If the user accepts, the browser register all certificate / domain / CA relationships from the pages users visit.
From time to time, user uploads the local DB of certificate / domain / CA relationships to .. let's say: sslverify.eff.org anonymously via TOR/I2p
Then EFF correlates and display a list of the offender CAs (May kill some spying gadgets)
This is an old never ending issue with the concept of root CAs: it's the browser *only* who knows the right ones. And browsers can be tampered with in this regard.
And since any official public X509 cert is pricey, many bit of infra rely on self-signed certs.
Other than that, it's working as expected: if your browser is not tampered with and has right CAs, it will tell you about dodgy sites, and it is up to the user to ignore the warning, if you know it is safe, whatever it means (LAN of the household only etc ...).
Yep.
That's one reason why certificate signed 'secure' emails never really took off- most CAs won't touch that use case because it's a giant hassle, and the few that will charge a ludacris amount of money for it.
I looked into it for [RedactedCo] one day, and dropped it almost as quickly- for the number of users we have, the cost was staggering, and had no real benefit; and having one of the cert companies do something where they sign root CA certificates for our public facing domains so we can run our own intermediates and publish externally acceptable certificates on demand? no one wanted to touch that with a barge pole.
Yeah, that and the pressure from law enforcement and the TLAs to "forget" about secure or signed email. How long has/was that SMIME cert stealing bug left untouched in the major email clients? I think Apple was still all WONTFIX last I looked. And most of the services claiming to host secure email have turned out to be selling snake oil because it's easier.
For companies that won't pass on any other opportunity to collect a buck, they have made doing secure email a giant PITA, and the few places that issue certs want a whole lot per year for something a computer can spit out for less than pennies. Until deploying them isn't a giant pain it's academic anyway.
I had hoped Let's Encrypt would spearhead getting email certs and non web-server certs rolling, but alas, they seem to have other priorities.
You'd think that after all of the embarrassing email links at least the politicians would be on board though.
That's one reason why certificate signed 'secure' emails never really took off- most CAs won't touch that use case because it's a giant hassle, and the few that will charge a ludacris amount of money for it.
Yes. I think there is a market for a company to sell EMail certificates for a few pounds a year per address, but the companies that could provide that service don't want to because it wouldn't make them enough money.
It's a pity that there is no government-mandated requirement to use encrypted (or, at least, signed) communications for all interaction with government offices (tax office, health services, car licensing, etc) and also with financial institutions. The government and/or banks could then provide the certification service -- after all, they already know who you are, so the ownership of the key would be simple for them to check when issuing the certificate.
> so we can run our own intermediates and publish externally acceptable certificates on demand? no one wanted to touch that with a barge pole.
Yeah, _you_ don't want to touch that with a bargepole either, because there's things like actual proper compliance audits, six-eye principles, "you spelled the company name in the certificate wrong: you said L.L.C. not LLC, all your certificates will now be revoked in 48 hours because it's obvious you're not trustworthy" and "please retain signatures on paper for each certificate for 8 years beyond expiry, I don't care you manage certs for 5000 VoIP phones, oh and you'll have to renew these every 30 days."
(Sometimes I feel like I'm a shoulder to cry on for our NREN's PKI folks, CA/B seems to be a right toxic shitshow.)
Before about 1860 the US's paper currency was issued by over a thousand banks so you never quite knew what you were getting -- the paper was really just a receipt for solid money but whether it had value depended on how reliable the issuer was, where they were based and so on. The Federal government fixed this by assuming a monopoly over the manufacture of notes.
We're in a similar situation with certificates. We have numerous root providers who may or may not be reliable. The only way to fix this is to make one public entity the authority over root and sub-root certificates. Any other solution is worthless -- you could publish a list of reliable certificate authorities but all you're doing is providing another source that needs to be trusted (and could conceivably be gamed).
I know that introducing a Federal bureaucracy -- or its equivalent -- cuts across the modern mindset of a free market free-for-all but this is one case where a deliberate, plodding, but above all accountable organization is necessary.
You have a point there, but the problem is that this unique authority which would decide over life and death of anything security-related can and will be misused. Monopolies never work out for the clients.
First of all it will be considered the perfect cash cow and certificates will cost literally a fortune, since, well, it's not like you have a choice. Pay up if you want or need one. Cert service will be awful or even broken because here again, the point is to make money, not to make clients happy or safe, and as long as the clients can't leave, there is no point in even trying to satisfy them. As long as the Root CA's selling argument is "it's me or nothing" they don't need to make any effort, not even a pretend one.
(And that's even before consider who would get to manage that. Would the USA trust a Chinese Root CA? Or the Chinese an USA Root CA? Why not settle for North Korea?... "Can of worms" would be an understatement...)
So you're saying the same thing is happening with money? With public services like police? At some point you're gonna have to trust SOMETHING because you lack the skills to do it yourself (why "If you want something done right" rarely works for cryptography). If you go full DTA, nothing gets done.
So, pick your poison...or starve...
> So you're saying the same thing is happening with money? With public services like police?
Apples and oranges. Certificate Authorities are definitely not a public service of some specific nation, they are (and need to be) international, above individual countries.
If only because, as I previously said, pretty few will trust some other country's official, government-controlled CA.
"Apples and oranges. Certificate Authorities are definitely not a public service of some specific nation, they are (and need to be) international, above individual countries."
Which means it'll never happen because each country necessarily has its own agenda. You basically need to have an enforceable global authority first. But odds are we'll get World War III instead.
> each country necessarily has its own agenda
That's precisely why it has to be above individual countries, independent from individual governments. This would also make things much easier to get everyone to agree, since it respects the old "If we don't get to control this, nobody else should": No government control, from anybody. (There obviously need to be control, but definitely not political.)
That's why it should not be an unique actor, but a constellation of independent service providers, so competition and lack of control prevent most of the temptations: If a provider gets cocky or sloppy, he will (should) lose business to the other providers, so he won't.
No, sorry, the only valid argument you could had put up is that this is already more or less what we have, and it doesn't seem to work all too well.
Oil and drugs (legal and illegal) yield huge benefits, thus the temptation to create cartels to control that profit. Certificate authorities simply don't compare, profit-wise. The people needing a certificate are very few and the resulting profit small, nowhere near enough to fund efficient lobbying. There won't be a CA cartel for the exact same reasons there isn't an international pizza parlor cartel.
Now I understand you're a stanch advocate of the "Big [something] vs. us" theory. I respect that, I'd just like to remind you to keep in mind Hanlon's razor: "Never attribute to malice that which can be adequately explained by stupidity"... While some conspiracies are most likely real, many are unlikely, as they imply a much more coordinated and intelligent species.
"Certificate authorities simply don't compare, profit-wise."
But what if the motive isn't profit but control of information flow (knowledge is power)...something governments might be interested in? Then money isn't the objective (and not as much an object in any event). Think about TOR and how trustworthy most people feel it to be at this stage.
I know about Hanlon's razor, but I'm also familiar with the natural human condition, which tend to be selfish if not tribal. Large societies don't tend to last long-term without a firm amount of control, something which favors authoritarian and similar regimes, and what have been the longest-lasting regimes in human history?
> what if the motive isn't profit but control of information flow
You don't need to control the CAs for that, you just need to control the ISPs. What would be more efficient in controlling snail mail use? Controlling the issuing of stamps, or controlling the postal delivery?
.
> what have been the longest-lasting regimes in human history?
Definitely the ancient ones! Ancient Egypt remained a superpower for over 2000 years, longevity went steadily downhill since then (Roman Empire 1500 years, British Empire 300 years). You can't pin it to one single reason though, and definitely not authoritarian regimes. Besides, those often tend to be rather short-lived (Nazi Germany, fascist Italy come to mind), even the more powerful and resilient ones eventually collapse (Soviets).
Whatever is is, I do not think Certification Authorities play any important role in civilization longevity. In the list of things any authoritarian government would want/need to seize control of, they come pretty low, somewhere along with the DMV.
"You don't need to control the CAs for that, you just need to control the ISPs. What would be more efficient in controlling snail mail use? Controlling the issuing of stamps, or controlling the postal delivery?"
Most ISPs are outside sovereign control, and unlike the post, a lot of the Internet traffic these days is black-boxed, preventing casual inspections like back in the old days (things like the Chinese Cannon). CA control provides the means for them to get back inside the boxes.
"Definitely the ancient ones!"
And last I checked, practically all of them were autocratic. Hierarchical structures seem to be the most natural for us if history is any indication, good or ill.
> Most ISPs are outside sovereign control
I'm talking about the national ISPs you and me use to connect to the Internet: Those are totally local and much likely to be leaned on (real world examples abound).
.
> Hierarchical structures seem to be the most natural for us
They are the most primitive form, inherited from animals. That been said, I remind you that it's ancient Greece which invented democracy, and that the ancient Romans were republican in the beginning (then at some point there was a coup d'etat and they turned autocratic). So one really can't say non-autocratic governments are a recent invention; The only thing one can say is they require an evolved, structured civilization. Each decline of civilization brings back the simpler, more primitive "might makes right".
"I'm talking about the national ISPs you and me use to connect to the Internet: Those are totally local and much likely to be leaned on (real world examples abound)."
But local ISPs usually don't do actual encryption and decryption; they just relay the data. You need to get to the endpoints, and the major endpoints aren't likely to be under the appropriate government's control.
"So one really can't say non-autocratic governments are a recent invention; The only thing one can say is they require an evolved, structured civilization. Each decline of civilization brings back the simpler, more primitive "might makes right"."
Which proves my point; non-autocratic governments tend to be the exceptions.
> But local ISPs usually don't do actual encryption and decryption
Indeed, that's not their job. You lost me here, what are you trying to say?
I never said ISPs (local or not) have anything to do with encryption. All I said is that, if I was a government wanting to control what my subjects are doing, putting up a "Great Firewall" and forcing everyone to go through that would be a much more efficient and easy solution than trying to control who is vouching for each individual website's SSL keys all over the world. The first is simple and straightforward, the second a huge legal whack-a-mole.
No, what they REALLY really would've done is develop their own, opaque protocols and use their "Great Firewall" to force gatekeeping (and translation) with the West. Otherwise, you find that geographic borders borders are notoriously porous (ask North Korea, who has trouble safeguarding a short one).
> develop their own, opaque protocols
It's a little too late for that, isn't it. The best any (rich!) nation with money to waste can hope to achieve is a "Great Firewall" type filter. Any totally closed and technically incompatible walled garden will collapse very quickly, as the French discovered with their Minitel service. Another proof it isn't really feasible is that there are many commercial entities wanting to create their own walled gardens (Facebook...), and despite their wealth they can't.
The social resilience of Internet is due to that, and that's the reason authoritarian governments can't really control it, just filter it or at best switch it off temporarily (temporarily because, authoritarian or not, you don't want a revolt on your hands, it's messy and expensive).
But this going OT, isn't it.
But that's just the French, with about 70 million people tops. China has over 1.5 billion, about 20% of the entire human population within its own borders. Why else do transnationals fear losing access to them? It's like the old saying, "If you default on a million-dollar loan, you're in trouble. If you default on a hundred-million-dollar loan, they're in trouble." If they really wanted to, they possibly have enough clout (and a desire to go in-house, most emphasized by President Xi) to dictate terms.
> China has over 1.5 billion
So what? Those 1.5 billion still love having access to "western" (are we actually west of China?) stuff, whatever it is, and Internet is part of it. Also, 1.5 billion angry people, that can get quite awkward... Which is why China didn't cut the wires altogether and set up their own Compuserve-like walled garden, but just set up a filter to suppress the most "harmful" content.
Sorry, I'm not sure I get your point. What are you trying to say?
In the mid to late 90s I was involved in one such program - that unfortunately died due to political differences/intransigence.
It was the United Nations Trade Pont Development Centre project.
It would have been (or at least the aim was) 'the' global root CA but unfortunately too many countries/people/politicians decided that they wanted to be "the boss".
So your last paragraph was the reality.
Private CAs have existed before the Internet. Most of the times they are used for good porpoises like implementing corporate PKI solutions for authentication, digital signature, VPNs. etc. Sometimes they are abused by evil actors (hackers or BOFHs) to intercept encrypted traffic, digitally sign malware, etc.
Perhaps more concerning are dodgy public intermediate CA issuing illegal, but technically valid certificates, to transparently intercept encrypted traffic, without having to install a "hidden" CA root in the victim's machine.
https://www.zdnet.com/article/google-catches-french-govt-spoofing-its-domain-certificates/
I'm seeing a lot of confusion here. Equipment generating a self signed certificate doesn't make it a root or even a trusted certificate, tahts why you get browser warnings when you attempt to load the page. Most chromium browsers on windows at least use the default windows certificate store, I think its mostly just firefox thats the hold out and still using its own store. Whatever else happens you are trusting the OS or browser vendor only to only install root certificates that should be trusted. You are then trusting the certificate authorities.
You've always been able to create your own root CA, most large enterprises have a PKI infrastructure of their own, windows domains create certificates that are loaded into your windows certificate store. Most security software now requires the install of a root cert on your machine to peruse and block encrypted bad content. I think its a stretch calling this hidden, you just have to trawl through the certificate store in use.
Yes I agree, but the CA's were deliberately designed to have this flaw to allow any government agency controlled CA (through shell companies) to issue a 100% valid certificate for any domain name. Then send that to any client that they want to man in the middle the traffic from and the client will happily accept signed certificate as 100% valid because it is totally valid. Any root CA can issue a perfectly valid certificate for any domain, even ones that have been already issued by another CA.
The CA system is broken by design.
By implementing DNSSEC and using DANE this turns DNS into a Global Distributed Certificate Authority as it allows four certificates type 0 - Global CA Certificate Public Cert, type 1 - Global CA Signed Server Certificate and the more important type 2 - Self Signed CA Public Certificate and type 3 - Self Signed CA Signed Server Certificate.
So security can be moved from Global CA to the local domain administrator , then it becomes a issue of domain reputational trust not an issue of Global CAs.
I expect that in some authoritarian regimes around the world, any private CA is always seen as a threat and will be called out as being called a malware motivated CA. There are certain strategic advantages to holding all the top level CA's. Such regimes will promote research as indoctrination that supports that viewpoint.
What is Microsoft UEFI CA? - Microsoft Corporation UEFI CA 2011. This one is used by Microsoft to sign non-Microsoft UEFI boot loaders, such as those used to load Linux or other operating systems. Technically, it's described as “optional” but it would be unusual to find a device that doesn't include it.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
