Rather than browsers arbitrarily only trusting certain lengths of certs, of much greater concern to me is the number of root CAs trusted by every major browser, some of which are companies under the control of authoritarian states (Turkey, China).
Go take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing.
Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.
It's a thing in that there are recordsets you can create to implement DANE for your zone, and software you can install that will validate those records. It is not a thing in that no mainstream browser will look at DANE, and in that virtually no popular sites (especially in the technology industry) use DANE.
Rogue CAs can do almost anything, but the browsers will kill any CA that is found to be (repeatedly) mis-issuing. And checking the CAA has apparently been in the CA/Browser Forum Baseline Requirements since 2017.
Theoretically, a client could also query the record and check it against the certificate presented. That would basically be the same as a DANE CA constraint.
I'm not aware of anyone actually doing this, though. Certificate Transparency requirements are probably enough to prevent any CA from attempting to cheat with CAA.
Don't do this. CAA is not "This is the list of CAs that are trustworthy for this domain".
CAA is "This is the list of CAs that can issue for this domain right at this precise moment".
If you aren't a CA you should only be looking at CAA either to debug a weird problem, out of curiosity or for some research purpose. Do not use it to make security decisions if you are not a CA.
That browser extension exists, or at least it used to. Of course, you run aground of the fact that nobody signs their zones (other than European domains whose registrars sign them automatically, which is, when you think about it, just theater).
I don't know what you mean by "Firefox doesn't enforce [CT]". Mozilla has been instrumental in dis-trusting misissuing CAs.
> I don't know what you mean by "Firefox doesn't enforce [CT]".
They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid.
Mozilla has lots of policy but Firefox has very little policy enforcement. This is important for practical reasons I explained only the other day.
For example Firefox doesn't check for SCTs so if you show my Firefox an apparently brand new certificate for which there are no SCTs (because maybe it's actually bogus) it will carry on as if nothing happened.
It also doesn't check validity periods. If you show Firefox a certificate from Let's Encrypt claiming notBefore 1986-03-02 and notAfter 2024-09-16 it considers that seems fine, never mind that the Web PKI didn't exist in 1986 or that nobody is allowed to issue leaf certificates that last almost 40 years - it doesn't care about that.
What's the deal with DNSSec for ordinary websites? I copied some code from namecheap (my registrar) to Cloudflare (my DNS hoster) and ticked DNSSec box, and it just worked. Literally few minutes. Setting up HTTPS with letsencrypt is thousand times harder and people manage to do that.
I guess that webmasters just don't care about DNSSec.
They do not, nor do the security teams of the tech industry or the financial industry (the second-best security staffed industry vertical) or really any other industry, because DNSSEC is silly and doesn't do anything important.
I will concede that if you centralize all your stuff on Cloudflare, it's very easy to set up. That's why Cloudflare makes it so easy to set up. Cloudflare is one of a single-digit small number of exceptions to the rule that big tech companies don't use DNSSEC; they do, of course, because it's part of the product they sell.
It’s more likely they are confused because of all of the conflicting opinions on the web. You’ll see people on HN who seem to have a personal vendetta against DNSSEC for reasons that only make sense to them.
For example, a common argument is that DNSSEC is controlled by world governments, as if certificate authorities and domain registries are free-standing entities separate from the countries they’re based in.
Many of these folks are actually misinformed, but there are quite a few who are clearly disingenuous about how DNSSEC works.
Let's clear this up: DNSSEC creates a chain of trust, from the root zone (the “.” at the top of the domain hierarchy) to your zone, such as example.com.
The chain is
. --> com --> example.com
Browsers trust hundreds of root and intermediate certificate authorities that can issue a certificate for any domain. This has happened more than a few times.
The DNSSEC trust chain is far more constrained and you get to create the KSK and zone signing keys (ZSK) for your zone.
Root Key Signing Key (KSK) is the public key of the key pair that’s for the root zone. The private key of this key pair is used to sign the top-level domains such as .com, .net, .org, etc.
The root KSK ships with all of the DNSSEC-supporting DNS resolvers and enables them to verify the authenticity of the trust chain.
It’s not clear what the paranoia is about; the public KSK is public; it’s referenced on thousands of websites and everyone involved with running the global internet knows about it. [1]
If something malicious or nefarious were to happen, all registries, regional internet operators, ISPs, etc. would immediately know about it.
All of the DNS resolvers that support DNSSEC have a built-in way to automatically upgrade to a new KSK when it’s released [2]. Even if you imagine the world’s governments colluding to change the key for whatever nefarious reason, DNS resolvers know not to trust any new key unless it’s been available for 30 days.
(The new key would need to be signed by the old key anyway, but for the sake of arguement, lets pretend that’s not neccessary.)
What those people neglect to mention is you’re not required to trust the root KSK. You can decide where your chain of trust starts if you wish, including only trusting your own zone. You can also create islands of trust, zones or domains you feel comfortable with.
Anyway, you can read rational, fact-based responses to these and other DNSSEC falsehoods. [3]
What's the deal with DNSSec for ordinary websites?
Even if don't use Cloudflare (or Google Cloud, which also supports DNSSEC), signing your zone has gotten pretty easy.
All of the major authoritative DNS servers support automatic DNSSEC signing and automatic key rollover of the Key Signing Key (KSK) and Zone Signing Key (ZSK).
For example, here's the configuration for automatic DNSSEC signing for Knot DNS [1]:
zone:
- domain: myzone.test
dnssec-signing: on
That’s all that’s required to DNSSEC sign a zone using Knot’s default settings. But if you want all of the bells and whistles, you can have that too.
Let me say just having SSHFP support thanks to DNSSEC turns using SSH from annoying to "it just works" [2] if you admin a server.
Setting up DNSSEC was difficult back in the day, but it’s pretty easy now.
These stats are damning for at least three reasons:
* You bring them up regularly without acknowledging that they're due in large part to European registrars that automatically sign new domains for their customers and hold the keys, which is security theater.
* The stats themselves are ludicrously misleading; for instance, they claim that 97% of .COM domains are signed despite listing only 1.5MM signed .COM domains, which is a tiny fraction of all of .COM (they are in reality listing the percentage of domains that have DNSSEC and properly validating signatures, and while it's amusing that something like 4% of DNSSEC domains don't even verifying, it's not evidence of adoption).
* The overwhelming majority of these domains don't matter at all, and a quick check of the lists of popular domains, from Alexa or the Moz 500, shows that virtually none of the popular domains outside the USG (where DNSSEC was formerly but is no longer required) are signed.
You can keep bringing this up, but all you're doing is giving me opportunities to put more facts about the failure of DNSSEC on the table, which is something I'm not actually all that committed to doing.
On the one hand we argue the Internet should be global and not get Balkanized and on the other hand we arbitrarily select certain countries to place lesser or higher trust in. Someone in China could legitimately have a similar low level of trust for US root certs and he/she would not be far wrong given that NSLs can gag companies into complying with arbitrary dictums that no one ever knows about.
Don't confuse a "country" with a "government". The Internet is global, but that doesn't mean I trust every person on it. That's why we have spam filters and block lists and cert trust lists.
The risk of the communication being compromised isn't necessarily the sole concern. There are also varying levels of consequences for various types of communication for different countries. When it comes to a country that has developed extensive censorship mechanisms and it's casually accepted that one could face a visit from the police or jailed for criticizing its leader or party it doesn't seem completely arbitrary to have some additional concern when it comes to that country possibly compromising your communication.
The original hacker dream of the internet was that it would break down borders and open up the free flow of information. Now that non-hacker types (politicians and bureaucrats, mainly) have had access for a few decades, they've realized how powerful a tool it is for empowering their authoritarian impulses.
Call me cynical but I think it's only a matter of time before the internet becomes totally Balkanized. Heck, it's almost there right now.
I live in Kazakhstan and I absolutely don't trust US. I don't fully trust Kazakhstani government either, but at least I know that they won't act hostile to me. I'm not removing US CAs, because it would be absurd, but I'm actually pretty angry at Firefox blacklisting some KZ certificates without my permission (and even without clear way to manually trust it again).
IMO software must respect every country and let government to act on their citizens as they want, even if some US guy thinks that it's not OK. It's not really his business.
> * I'm actually pretty angry at Firefox blacklisting some KZ certificates without my permission*
But you can understand why, by default, anyone who doesn't live in Kazakhstan has little to gain from trusting those CAs. The default roots are default for everyone, at the moment, so they need to be universal. Maybe they should have some sort of detection, i.e. "we see you're in Kazakhstan, trying to access this Kazakh site which is only available with this distrusted CA, would you like to trust this certificate?"
> IMO software must respect every country and let government to act on their citizens as they want, even if some US guy thinks that it's not OK. It's not really his business.
It's kinda two things, "letting" citizens submit to their governments with your software is different from specifically enabling it, which seems like what you're suggesting. Out of principle, I won't be making any particular effort to enable a "government to act on their citizens as they want", because that is immoral.
If you want software that goes out of its way to oppress you, then you can write it yourself, or find somebody who will take money for that.
I would prefer that root certificates have restriction on what they can sign, eg. a Khazachstan root certificate can't legitimately sign a .com certificate. I think that not having this is a fundamental flaw in the certificate setup.
X.509 has supported this for a long time and so have browsers, iirc Chrome restricted some French CA to specific domains at one point.
The issue here is not so much technical as cultural. Mozilla employees don't know or care about people from Kazakhstan and didn't prioritise finding ways to reduce the disruption.
> But you can understand why, by default, anyone who doesn't live in Kazakhstan has little to gain from trusting those CAs.
No more or less than any other root CA? They're run by the legitimate, internationally recognised, democratically elected government of Kazakhstan. I'd expect many Kazakh businesses to have a certification path with that CA at the root; that seems like no more or less legitimate a root certificate than, I don't know, Deutsche Telekom or VeriSign or whoever. Currently I use more websites that are based in the US or Germany than are based in Kazakhstan, sure, but it's not like there aren't legitimate web businesses in every country.
We're not talking about some pariah state here. Kazakhstan is pretty close to a model international citizen; they've not started any wars, they're not accused of hacking or spying on anyone or interfering in other countries. It's hard to imagine any reasonable standard that would exclude Kazakhstan but include enough countries to reasonably qualify as international.
There's nothing "model" about intercepting and surveilling all TLS traffic in your country. Nobody should get the impression that they are legitimately connecting to Google or Y Combinator when they are actually connecting to the government of Kazakhstan's SIGINT apparatus.
The government of Kazakhstan used the CA inappropriately, to impersonate at least 37 domains. That is at least illegal in itself, as far as international trademark law is concerned. It contravenes all norms of international business.
In short, the claim that the government of Kazakhstan is a "model international citizen" is particularly laughable in the context of their abuse of their root certificate, and you'd be an absolute fool to trust it when connecting to hosts outside Kazakhstan (assuming you kinda have no choice when doing business with hosts within Kazakhstan).
> The government of Kazakhstan used the CA inappropriately, to impersonate at least 37 domains. That is at least illegal in itself, as far as international trademark law is concerned. It contravenes all norms of international business.
Back when I worked for a Fortune 500 company they did exactly the same thing. So no, it's a completely normal, widely accepted practice for international businesses. (Also note that at least one major US ISP injects its own "content" into third-party websites).
> Back when I worked for a Fortune 500 company they did exactly the same thing.
No, it is not the same thing. Kazakhstan is not your employer intercepting your work computer's traffic while you're at work, it's a country intercepting all of your communications toward state goals. You can't just "quit" Kazakhstan.
As someone from neither the US nor China, I'd prefer CAs from both (and more) coming to a consensus. "All but X declared this site fine" sounds a lot more convincing to me. Sure, down the line the owner of the site will still be a single breaking point for that site. But I really don't like having to trust additional individual organizations.
I think we're generally on a trajectory towards addressing the fundamental issue --- a few major firms will implement free certificates, like LetsEncrypt and ACM, and the industry will consolidate around them. And browsers will get stricter about transparency requirements for the oddball CAs. But it seems like we're definitely going to salami slice our way out of this problem.
I guess because it is an unusual relatively small entity who's position as a CA is unusual. Plus, without certificate pinning [ie. before HSTS] you don't want rogue CAs.
The constraint loosening says your Leaf must be first. If you obtain different leaf certificates from different CAs then you can't "put the leaf first" for all of them.
In today's browsers the first leaf will be treated as your apparent leaf (so the Subject needs to match the hostname in the URL), other leaves presented will either be discarded or cause an error. So no benefit.
You've definitely misunderstood something here, I'm going to guess and explain the bit I think you have wrong, but if I guessed wrong and that's not the bit you were unclear on we can try again.
So, a Certificate Signing Request is a request that a CA signs some certificate but especially in the Web PKI it's an error to think of it as a request to sign one particular certificate. The result of sending CSRs to two or more CAs is not two otherwise identical documents with different signatures.
Experts talk about "signing a CSR" knowing that's not exactly what they mean even though in a toy CA built out of OpenSSL it seems like that works.
In reality a properly created CSR is proof that you know some private key (not revealed to the CA) corresponding to a public key (which is) and you want a certificate for some names. But the Certificate Authority will need to at least choose their own random serial number, fill out their own Issuer name and key, and choose appropriate date-time values for the certificate's lifespan (notBefore / notAfter). In reality they often at least partially discard the names you filled out because their rules may forbid issuing certain names you've asked for. If you use automation like Certbot the names requested exactly match what you wanted, but if you're building CSRs with OpenSSL or some 1990s Java web forms on an appliance chances are the names in the CSR are semi-bogus and issuing for them is forbidden so the CA needs to figure out what you actually needed.
Anyway, as a result for each CA you'd get a distinct Leaf certificate which (if you follow the DAG backwards) gets to a different trusted root. But you are only permitted to send one Leaf in TLS despite the otherwise relaxed constraints.
How much of this is fixable with generating the right CSR and choosing the right CAs? Does "will need to at least choose their own random serial number, fill out their own Issuer name and key" absolutely wreck it?
Actually better can be like nested signing with many CAs, I sign my certificate with 3 different CA, let's say from US, Russia, China etc. Unless all 3 are bad, I am safe.
> Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.
I think the real innovation in transparency will be client side. I have been wanting to develop a "root CA" hit counter that tracked locally which of the sites you visit used which CA. You could say the logical addition from there is to allow users to disable unused CAs (or do it automatically when unused) and have a opt-in when a disabled one is used, but I think that's too much. Just a client-side plugin to let me see which CA is used and keep track alongside history (i.e. not in incognito) would be nice.
Yes, the Firefox plug-in "Certainly Something" uses the equivalent APIs in Firefox and works today, giving back a nicer version of their old "View certificate" UI only to the fraction of people who care, rather than weighing down the actual Firefox browser with more and more X.509 features most users will never need.
You probably should not encourage lay users to disable CAs they aren't using, it's like those plastic "child safety" plug inserts in the UK - kids already can't actually do the thing the insert pretends to prevent, safety shutters mandated by law in your power sockets keep tiny fingers out of the live power - but the plastic insert is exactly the perfect shape for a kid to defeat the safety protection and electrocute themselves.
> You probably should not encourage lay users to disable CAs they aren't using, it's like those plastic "child safety" plug inserts in the UK - kids already can't actually do the thing the insert pretends to prevent, safety shutters mandated by law in your power sockets keep tiny fingers out of the live power - but the plastic insert is exactly the perfect shape for a kid to defeat the safety protection and electrocute themselves.
Your analogy is unnecessary. This is simply a case of determining which issuing authorities you want to trust. Do I want to trust ones in China? No. That's not racist by the way.
Since Firefox 72, the built-in certificate viewer actual reuses most of the JavaScript code from "Certainly Something". So the extension isn't strictly necessary anymore.
I don't think it'd be overkill to send a request to all 52 CAs (and fail if you get conflicting answers). Then the most a trusted CA could do is DoS some sites.
> The Turkish Government CA is name-constrained to a set of turkish toplevel domains - that is, .gov.tr, .k12.tr, .pol.tr, .mil.tr, .tsk.tr, .kep.tr, .bel.tr, .edu.tr and .org.tr.
What if there was a country flag or something, indicating where the CA was located -- in which country / jurisdiction?
Then, let's say it's in China or Turkey or Kazakhstan, etc etc, then I would know that the politicians/police there might have decided to man-in-the-middle listen to anything I type into that website.
And what if there was a Freedom of Press index number (or sth like that) next to this flag? (because who can remember all flags)
You absolutely can build a plugin for Firefox (and Chrome? Maybe? Sounds like some APIs needed are not finished) to add this UI feature for people who want it.
Experience shows that if everybody wants a UI feature from a plug-in it won't take long until the people you were plugging into implement it natively and you can choose to take that as praise or shake your fist at them for "stealing". I recommend the former.
But I doubt your new "Freedom of the Press of the CA issuer of this site" UI will be very popular because it's not at all obvious what anybody can do with that information or how to even interpret it.
I think that would be a wonderful idea. Show the flag (along with the lock icon) of the country of the CA. That would at least give a bit more transparency to the user of the certificate other than checking the details manually.
> Go take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing.
I do in some sense trust them to always do the right thing, but, as the saying goes "Trust but verify". As well as trusting them I also pay attention to what I see and other people see and press them to do better when they fall short.
I actually think their record has been fairly good, and is gradually improving. It could always be better, but on the whole what I see from CAs is exactly what I'd expect from humans generally, they are lazy and incompetent and so we have to design things to take that into account. I'd expect no more from any of us.
Sure, after Let's Encrypt posted initially at the end of February about their uh, bug, I responded in part:
> That is, how many certificates were really issued to multiple FQDNs (if a single FQDN the bug described
has no effect) more than 8 hours after initial correct CAA checks ? Intuitively this should be almost none, but intuitions can be misleading.
Jacob responded by saying that they were "working on this analysis today" although in fact the next we heard was a complete list of arguably misissued certificates a few days later in an announcement that was linked from Hacker News and which you've hopefully seen.
I wrote (in that Hacker News thread) that this was one way to answer my question :D
Certificate Transparency means SSL certs must have been logged to public CT log databases to be considered valid. This ensures that any monkey business MITMing with rogue certificates will be detected quickly, either by site owners seeing unknown certs for their sites in the log, or browsers rejecting unlogged certs.
Two related things are happening here, and a third thing isn't actually happening today but is an active subject of research.
1. All the trusted CAs log either all the certificates they issue or the vast majority of certificates intended for use on the public Internet. They do this because it's a good idea, and (as we'll see in #2) because it makes commercial sense. The effect is that if you have a way to trick a CA into issuing something that shouldn't exist, or if they just issue it through the usual human fallibility (e.g. an operator fat fingers something at a console) researchers can see it, the same way they'd see if your Senator doesn't bother attending Congress - it's a matter of public record.
2. Google's Chrome, and later Apple's Safari require SCTs (Signed Certificate Timestamps) from logs before they accept newer certificates. The cheap easy way to arrange this is to log "pre-certificates" which get you valid SCTs and then you bake those inside the real certificate given to a subscriber. If you use Let's Encrypt, this is how SCTs got inside all your certificates, no extra work for you. There are fancier options that let you get a certificate and then obtain SCTs later separately, but they're rather niche. This means if you can obtain an apparently valid certificate but only a new enough one (thus after enough time in the future, any certificate) but no SCTs for it, it won't be valid in those browsers. The logs aren't supposed to give out an SCT without logging the certificate. So now an attacker needs to either log their bogus certificate (if they can) and show it to the world, or corrupt the logs too, a big ask on top of whatever attack they've done to trick or corrupt the CA issuer or bypass them.
3. Eventually the intention is a Gossip protocol. The idea here is, when you browser sees an SCT we should like to verify that the associated certificate was really logged irrevocably for everybody to see. But we'd like not to undo your privacy in the process. You don't want to tell everybody "Hey I like Balloon Porn" but you'd ideally like to be sure the certificate on your Balloon Porn website is seen in the logs by everybody, not just a special version of the log shown only to you and six other people under investigation for liking Balloon Porn. Figuring out the best way to approach this is an active research topic.
I don't get why it is always authoritarian states that is pointed fingers at when history clearly shows us that it isn't authoritarian states that are the biggest problem but so-called democratic states. I get why one would dislike authoritarian states (I do too) but the smart move is to look at who history tells us not to trust - not just believing the bogyman is coming.
I personally only whitelist some authorities, but I think the threats to the CA infrastructure are sadly more mundane than the problems caused by weird fascist state actor CAs.
This is an unexpected (from someone outside the cert industry) development. I know for sure it will have some impact on servers I manage, since we typically purchase 2 year certs, and issue 5 year certs internally.
It's also been shown recently that not all companies are great at managing their certs, with notable shutdowns associated with expired certificates. Increasing the frequency of updating certs should be a good thing, but in practice I'm afraid that it will remain a manual project for some time to come.
I don't think it's unexpected. Browsers are _the_ lifeblood of CAs.
Unless CAs insert themselves more into the process of code signing, S/MIME, GPG or something like that. They will remain under the heavy influence of browsers.
And this is like that in an important way, for now.
Chrome and Safari both have browsers which implement a check such that you need to present enough "qualified" SCTs or the certificate is treated as invalid.
The easiest way to pass that check (for certificates you're going to sell or give to webmasters with no clue) is to log a pre-certificate with Google, and with at least one (preferably two) other logs that Apple and Google agree are trustworthy - then bake the SCTs you get back from those logs into the X.509 certificate you're issuing.
But these are not Trust Store policy requirements. If you in fact choose to issue (for a number of reasons some CAs do) without logging that's still permitted, the certificates just won't be trusted in Chrome or Safari. You obviously won't get far selling certificates that don't work out of the box in Chrome or Safari to the average punter, but not every customer is the average punter.
Apple's declared intention is that Safari will not trust long-lived certificates. But as far as I've seen it is not specified that they would consider a CA which chooses to issue such certificates to violate Apple trust store policy and pursue any sanction or demand revocation. The certificate just doesn't work in Safari.
Now, today Mozilla's Firefox is in a different situation from Safari and Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical enforcement. Mozilla works hard (and in public where we can all see) on policy decisions, but most of them are not enforced in its flagship browser product. Mozilla champions CT logging for example, but a brand new certificate presented with no SCTs works fine in Firefox even though it'd be rejected by Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even though those are the limits set in policy, and so following Apple's suggestion wouldn't actually be easy for them, there isn't a line of code (as there is in Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds, which can be adjusted to say 398 or some other number of days instead of 825.
Thank Christ. The browsers have been far, far better stewards of the Web PKI than the CA/B Forum (at large) has been, and, in the main, the Web PKI exists to support browser security. That the major browser vendors are getting more muscular about their demands is a major shift: antitrust was a real concern that prevented a lot of important Web PKI stuff from happening sooner. But with Google and Mozilla breaking the largest CAs over documented misissuance, it's possible that concern has finally gone by the wayside.
I feel like this is a fairly narrow view of the situation. In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff.
The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?
People say this a lot. But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI? Many of the most important public key crypto tools people actually use --- Signal, SSH and SSH CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.
You're not really answering my question. Assume the standardization falls into place, and it's all JSON instead of X.509 so that Javascript developers will actually use it. What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?
What gets better? What thing out there was just begging to be encrypted by a giant tree shared by the whole Internet?
The Nine Planes of the Internet would be connected. Níðhöggr, Dáinn, Dvalinn, Duneyrr and Duraþrór would be in their ordained places, no longer roaming lost in endless Violation of the Layers.
Companies sign official correspondence, and email clients give blaring sirens/red flags for unsigned correspondence (or send it straight to the spam folder) similar to how browsers now handle http vs. https traffic?
It would also be very easy to detect any misrepresentation. Email contains a link to a domain that isn't on your cert? Alarms / no clickable links / etc.
Scammers are capable of setting up signing and getting certificates for their domains. It's an extra hurdle, but, like setting up https, it's not a big hurdle.
No cross domain links would disrupt a lot of current emails, but most senders would likely setup in-domain redirectors to carry on their current mailing patterns. Unfortunately, some of those would probably be open redirectors (because it's easy to make an open redirector and it "solves" the immediate problem), leading to some amount of security issues.
> But where are the examples of all the "stuff" that would benefit by being linked into a single global PKI?
Estonia's national system and its e-services are a local example of a single central PKI. Provided services and systems seem to be far ahead of basically all other countries.
Identity theft, identification, authentication, signing etc. have been solved for nearly two decades now and I have to say the way the rest of the world does stuff looks stone-age to me.
For example I loathe how I've been asked to do identity verification by foreign companies "send us a picture of your ID", WTF. Sentences like "Use SMS 2FA to protect your account", "e-mail us the bill" and "come to our office to sign {x}" make me shudder, it's absolutely dogs*.
It's not an example of a global PKI and worse, Estonia had to invalidate/patch everyone's e-ids once already. A hassle somewhat mitigated by the fact that fewer people live in Estonia than in the Bronx.
I think the point is more that even the (massive) concentrated effort it takes to patch the IDs will be less than the collective impact of not having those IDs at all (in terms of the convenience it would add to peoples’ lives) OR having the IDs without the patches at all.
It's the closest to global we've had that involves actual people and agencies, not just computers. Dismissing it only gets you "send us a picture of your gas bill to prove your identity"-level hindrance and mess.
The anti-PKI crowd are getting waayyyyy ahead of themselves. Pretty much any large deployment of public-key cryptographic needs some sort of PKI. Any framework where there's a third-party authority that signs keys requires some sort of PKI, directly, indirectly, or both. And there's almost always such a third-party because otherwise public-key cryptography is barely just a step ahead of shared secrets. This is especially true when you have distinct vendors, but I can guarantee you that even Signal has an internal PKI framework, independent of the Android PKI framework that it also implicitly relies upon.
Someone else thread mentioned S/MIME. S/MIME might be a failure, but S/MIME is a thin wrapper around CMS (Content Messaging Syntax), which is widely deployed standard for signing, authenticating, and encrypting content. It's based on the same ASN.1 standards as PKIX. And like PKIX, the root authorities are whatever you want them to be; the standards just provide the syntax and semantics for building the PKI and providing interoperable messaging.
You tried the same rhetorical sleight of hand in a different thread a week ago; what you're doing is claiming that any use of asymmetric cryptography is by definition a form of PKI, when what we're talking about --- top-down tree-structured global PKI --- is clearly different from what they're doing.
Your point about S/MIME and CMS kind of makes my overall point for me. Sure. A global PKI is super useful for making things like CMS happen.
You're talking about global PKI. But the "public" in PKI doesn't imply global any more than the public in public-key cryptography does.
What PKI does usually imply is some sort of top-down tree of trust and mechanisms and policy for managing and verifying that tree. But the roots of that tree of trust don't have to be global, and with the exception of Web PKI aren't.
You're creating the straw man. You keep saying that new protocols don't need PKI. Well, if we accept your criteria for what PKI means, and considering that the only example that meets your criteria, past, present, or future, is Web PKI, then what exactly is the point of your argument?
If you have a beef against PKIX, CMS, X.509, ASN.1 etc--i.e. the mechanisms--then just say so. There's a ton of reasonable criticism to be made there. But those things are not equivalent to "PKI". There are plenty of PKI systems out there that make use of alternative mechanisms, though mostly proprietary and hidden as interoperability usually demands making use of pre-existing standards. But, to reiterate, using those standards to build a PKI system absolutely does not require relying on the same global roots of trusts. Nothing in those standards even identifies such a root or the shape of the tree at all.
OAuth2 relies on HTTPS and thus the Web PKI to prevent anyone from MitMing either the login page itself or API requests made using the OAuth token.
SSH's trust-on-first-use system is only secure under the assumption that you "usually" aren't being MitMed; this ought to be improved. For the typical server administration use case, I'd prefer a design that doesn't involve PKI – like encoding a hash of the key into the SSH command – but domain validation based on Web PKI could still be better than nothing. (Perhaps using some subdomain owned by the hosting provider, as opposed to the public-facing domain(s) for the server.) Domain validation would also be ideal for use cases where you're connecting not to your own server but to some known entity's, such as SSHing to GitHub. As for SSH CAs... I've never heard of them before. :) Looking it up, I see that some organizations use them, but I'm not sure their design is a good fit for the kind of non-organization-internal use cases I'm thinking of.
As it stands today, Signal's public key system is largely security theater since nobody bothers to check authentication codes. Even when people do check them, you always have an excuse for changing your code out of the blue (got a new phone, had to reset my phone, etc.), which an attacker can take advantage of. The latter could be fixed by having a better way to transfer trust between devices, but Signal could still have a better story for initial authentication than trusting the phone system. Now, I don't think a traditional PKI would help. But I do like what Keybase is doing here, bootstrapping trust off of a collection of signed attestations on social media accounts. I'd argue this amounts to a PKI in its own right, one where social media providers (unknowingly) play the role of CAs.
Sure a pki could help Signal. Carriers are the ultimate arbiters of who owns a phone number and have direct access to the hardware that checks that ownership. For many people they also do ID verification. Carriers could provision phones with certificates and that would decentralise the Signal key database enormously.
Firstly you often don't need a PKI, and when you do need a PKI (which as I said is less often than people think) you often don't need a public one.
Take EMV ("Chip cards"). There's public key crypto securing your payment card transaction. There are multiple organisations involved. So we've got a PKI, but does it need to be a public PKI? Why not just let EMVco run everything, probably badly, and have them and their members (the banks and other big financial firms) eat it when inevitably they do a bad job? So that's what happens. If a CA in the EMV ecosystem does a bad job your bank will end up eating the cost of that, or maybe your country, the headline won't be "Obscure CA misissues certificate" it'll be "Huge Bank loses $500Bn in IT catastrophe" or something.
Secondly, the thing a PKI does relies upon is a common naming scheme. The standard actually used in the Web PKI, X.509 was designed for a world with a global directory of everything, the X.500 global directory system. That directory does not exist. What common naming schemes are there that we'd want digital certificates for?
The IETF published RFCs from the PKIX working group, defining how X.509 can be used for the Internet's names. That is, mostly ipAddresses, dnsNames, and emailAddresses.
The Web PKI concerns itself de facto with the first two. You could and some people do use IP addresses or DNS names in a context outside the Web PKI, but mostly they don't. "Don't roll your own". Even the successor to TCP, QUIC, was re-designed to have it just envelop TLS and thus depend upon the Web PKI, rather than inventing a new shiny public key crypto technology and associated PKI.
So the only use case we actually care about that didn't end up happening was email, S/MIME is what was attempted and... I have no doubt Thomas Ptacek can explain at considerable length how unlikely it is that anybody can get that to do what you'd expect it to do and deliver you any meaningful security if you're interested.
It should definitely give you pause when you see a system which really seems like it could only be secured by a PKI and it isn't the Web PKI. Is it a private PKI? Who has oversight? Or are they just going through the motions and the security is illusory? The answer is the latter pretty often. Stakes are often thought to be very low until they aren't...
> In theory the CA "System" ought to be much bigger than just web traffic since a globally distributed hierarchical database of certs is neat and could be used for all sorts of stuff.
Honestly I would love it if my password manager would also act as a personal certificate authority.
PKIs are a much more general system, but this is a very specific PKI that was built specifically for web browsers. You can use others, you can even build your own. The fact that the this PKI was first, means that some people depend on it who probably shouldn't. But its still by the browsers, for the browsers.
It is difficult to find a group of companies less trusted to do the right thing than the major browsers (Apple, Google, Microsoft). However, the CAs qualifies, ironically perhaps, as less trusted.
Why is this an improvement? Has there been a rash of stolen certificates or domain name ownership changes? Is having a third party with a cert for a domain you're using for 12 months acceptable in a way that 2 years isn't?
It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.
> It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.
Does certificate length really matter? It seems like other factors related to certificates are much more important than the ability for a cert to be stolen, reused, and not revoked.
Cert revocation for the web is broken, which is why there's been so much emphasis on lifetime. Revocation checks are a privacy leak and reliability degradation and DoS vector, unless you use something like OCSP stapling, which fairly few sites do.
And the browsers, in turn, are controlled by a few big tech companies. Is it a good idea to give those companies control over the trust architecture of the internet? What happens if you get on tech's persona non grata list? Do you not get to use the PKI?
You'd need to ask Microsoft about that, theirs is (as far as I know) the only Trust Store which demands they get unilateral override for revocation decisions.
That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say "killtrump.example is not acceptable, revoke their certificate" Let's Encrypt says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say "Please reconsider this seems like a bad idea" and then Microsoft can say "We've thought about it, revoke" and the choice is only whether Let's Encrypt wants to remain trusted in Microsoft's products.
Nobody else has a rule like that, and it isn't a new rule, it's a published part of Microsoft's policy. Microsoft says they use it only to protect Microsoft's customers from phishing and similar attacks. Perhaps that's even true.
At no point have the browsers ever not been running the whole TLS show. The CAB forum is a useful construct, but its usefulness has a specific place.
Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote.
That be a useful set of meetings.
But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.
127 comments
[ 4.0 ms ] story [ 242 ms ] threadGo take a look at how many CAs your browser trusts, and tell me with a straight face that you absolutely trust every one of those CAs to always do the right thing.
Certificate issuance transparency helps, but doesn't get rid of the fundamental issue.
DANE is a dead letter standard.
https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...
That said, LetsEncrypt just had a nasty bug around CAA checking, and ended up not quite revoking all certificates for which insufficient checks had been executed: https://community.letsencrypt.org/t/2020-02-29-caa-recheckin....
I'm not aware of anyone actually doing this, though. Certificate Transparency requirements are probably enough to prevent any CA from attempting to cheat with CAA.
CAA is "This is the list of CAs that can issue for this domain right at this precise moment".
If you aren't a CA you should only be looking at CAA either to debug a weird problem, out of curiosity or for some research purpose. Do not use it to make security decisions if you are not a CA.
CT helps somewhat, but given that Firefox doesn't enforce it leaves a lot of people vulnerable.
I don't know what you mean by "Firefox doesn't enforce [CT]". Mozilla has been instrumental in dis-trusting misissuing CAs.
They mean Firefox, unlike Chrome and Safari, doesn't require proof of inclusion in a CT log for recently issued TLS certificates to be considered valid.
Source: https://developer.mozilla.org/en-US/docs/Web/Security/Certif....
For example Firefox doesn't check for SCTs so if you show my Firefox an apparently brand new certificate for which there are no SCTs (because maybe it's actually bogus) it will carry on as if nothing happened.
It also doesn't check validity periods. If you show Firefox a certificate from Let's Encrypt claiming notBefore 1986-03-02 and notAfter 2024-09-16 it considers that seems fine, never mind that the Web PKI didn't exist in 1986 or that nobody is allowed to issue leaf certificates that last almost 40 years - it doesn't care about that.
[1]: https://stats.dnssec-tools.org/#summary
I guess that webmasters just don't care about DNSSec.
I will concede that if you centralize all your stuff on Cloudflare, it's very easy to set up. That's why Cloudflare makes it so easy to set up. Cloudflare is one of a single-digit small number of exceptions to the rule that big tech companies don't use DNSSEC; they do, of course, because it's part of the product they sell.
For example, a common argument is that DNSSEC is controlled by world governments, as if certificate authorities and domain registries are free-standing entities separate from the countries they’re based in.
Many of these folks are actually misinformed, but there are quite a few who are clearly disingenuous about how DNSSEC works.
Let's clear this up: DNSSEC creates a chain of trust, from the root zone (the “.” at the top of the domain hierarchy) to your zone, such as example.com.
The chain is
Browsers trust hundreds of root and intermediate certificate authorities that can issue a certificate for any domain. This has happened more than a few times.The DNSSEC trust chain is far more constrained and you get to create the KSK and zone signing keys (ZSK) for your zone.
Root Key Signing Key (KSK) is the public key of the key pair that’s for the root zone. The private key of this key pair is used to sign the top-level domains such as .com, .net, .org, etc.
The root KSK ships with all of the DNSSEC-supporting DNS resolvers and enables them to verify the authenticity of the trust chain.
It’s not clear what the paranoia is about; the public KSK is public; it’s referenced on thousands of websites and everyone involved with running the global internet knows about it. [1]
If something malicious or nefarious were to happen, all registries, regional internet operators, ISPs, etc. would immediately know about it.
All of the DNS resolvers that support DNSSEC have a built-in way to automatically upgrade to a new KSK when it’s released [2]. Even if you imagine the world’s governments colluding to change the key for whatever nefarious reason, DNS resolvers know not to trust any new key unless it’s been available for 30 days.
(The new key would need to be signed by the old key anyway, but for the sake of arguement, lets pretend that’s not neccessary.)
What those people neglect to mention is you’re not required to trust the root KSK. You can decide where your chain of trust starts if you wish, including only trusting your own zone. You can also create islands of trust, zones or domains you feel comfortable with.
Anyway, you can read rational, fact-based responses to these and other DNSSEC falsehoods. [3]
[1]: https://www.iana.org/domains/root
[2]: https://tools.ietf.org/html/rfc5011
[3]: https://easydns.com/blog/2015/08/06/for-dnssec/
Even if don't use Cloudflare (or Google Cloud, which also supports DNSSEC), signing your zone has gotten pretty easy.
All of the major authoritative DNS servers support automatic DNSSEC signing and automatic key rollover of the Key Signing Key (KSK) and Zone Signing Key (ZSK).
For example, here's the configuration for automatic DNSSEC signing for Knot DNS [1]:
That’s all that’s required to DNSSEC sign a zone using Knot’s default settings. But if you want all of the bells and whistles, you can have that too.Let me say just having SSHFP support thanks to DNSSEC turns using SSH from annoying to "it just works" [2] if you admin a server.
Setting up DNSSEC was difficult back in the day, but it’s pretty easy now.
[1]: https://www.knot-dns.cz/docs/2.9/html/configuration.html#aut...
[2]: https://weberblog.net/sshfp-authenticate-ssh-fingerprints-vi...
* You bring them up regularly without acknowledging that they're due in large part to European registrars that automatically sign new domains for their customers and hold the keys, which is security theater.
* The stats themselves are ludicrously misleading; for instance, they claim that 97% of .COM domains are signed despite listing only 1.5MM signed .COM domains, which is a tiny fraction of all of .COM (they are in reality listing the percentage of domains that have DNSSEC and properly validating signatures, and while it's amusing that something like 4% of DNSSEC domains don't even verifying, it's not evidence of adoption).
* The overwhelming majority of these domains don't matter at all, and a quick check of the lists of popular domains, from Alexa or the Moz 500, shows that virtually none of the popular domains outside the USG (where DNSSEC was formerly but is no longer required) are signed.
You can keep bringing this up, but all you're doing is giving me opportunities to put more facts about the failure of DNSSEC on the table, which is something I'm not actually all that committed to doing.
Call me cynical but I think it's only a matter of time before the internet becomes totally Balkanized. Heck, it's almost there right now.
I love bashing America as much as the next guy, but equating it to China in terms of trust is not fair.
IMO software must respect every country and let government to act on their citizens as they want, even if some US guy thinks that it's not OK. It's not really his business.
But you can understand why, by default, anyone who doesn't live in Kazakhstan has little to gain from trusting those CAs. The default roots are default for everyone, at the moment, so they need to be universal. Maybe they should have some sort of detection, i.e. "we see you're in Kazakhstan, trying to access this Kazakh site which is only available with this distrusted CA, would you like to trust this certificate?"
> IMO software must respect every country and let government to act on their citizens as they want, even if some US guy thinks that it's not OK. It's not really his business.
It's kinda two things, "letting" citizens submit to their governments with your software is different from specifically enabling it, which seems like what you're suggesting. Out of principle, I won't be making any particular effort to enable a "government to act on their citizens as they want", because that is immoral.
If you want software that goes out of its way to oppress you, then you can write it yourself, or find somebody who will take money for that.
The issue here is not so much technical as cultural. Mozilla employees don't know or care about people from Kazakhstan and didn't prioritise finding ways to reduce the disruption.
No more or less than any other root CA? They're run by the legitimate, internationally recognised, democratically elected government of Kazakhstan. I'd expect many Kazakh businesses to have a certification path with that CA at the root; that seems like no more or less legitimate a root certificate than, I don't know, Deutsche Telekom or VeriSign or whoever. Currently I use more websites that are based in the US or Germany than are based in Kazakhstan, sure, but it's not like there aren't legitimate web businesses in every country.
The government of Kazakhstan used the CA inappropriately, to impersonate at least 37 domains. That is at least illegal in itself, as far as international trademark law is concerned. It contravenes all norms of international business.
In short, the claim that the government of Kazakhstan is a "model international citizen" is particularly laughable in the context of their abuse of their root certificate, and you'd be an absolute fool to trust it when connecting to hosts outside Kazakhstan (assuming you kinda have no choice when doing business with hosts within Kazakhstan).
Back when I worked for a Fortune 500 company they did exactly the same thing. So no, it's a completely normal, widely accepted practice for international businesses. (Also note that at least one major US ISP injects its own "content" into third-party websites).
No, it is not the same thing. Kazakhstan is not your employer intercepting your work computer's traffic while you're at work, it's a country intercepting all of your communications toward state goals. You can't just "quit" Kazakhstan.
https://bugzilla.mozilla.org/show_bug.cgi?id=373537
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Of course, you'd have to do the switching manually.
In today's browsers the first leaf will be treated as your apparent leaf (so the Subject needs to match the hostname in the URL), other leaves presented will either be discarded or cause an error. So no benefit.
So, a Certificate Signing Request is a request that a CA signs some certificate but especially in the Web PKI it's an error to think of it as a request to sign one particular certificate. The result of sending CSRs to two or more CAs is not two otherwise identical documents with different signatures.
Experts talk about "signing a CSR" knowing that's not exactly what they mean even though in a toy CA built out of OpenSSL it seems like that works.
In reality a properly created CSR is proof that you know some private key (not revealed to the CA) corresponding to a public key (which is) and you want a certificate for some names. But the Certificate Authority will need to at least choose their own random serial number, fill out their own Issuer name and key, and choose appropriate date-time values for the certificate's lifespan (notBefore / notAfter). In reality they often at least partially discard the names you filled out because their rules may forbid issuing certain names you've asked for. If you use automation like Certbot the names requested exactly match what you wanted, but if you're building CSRs with OpenSSL or some 1990s Java web forms on an appliance chances are the names in the CSR are semi-bogus and issuing for them is forbidden so the CA needs to figure out what you actually needed.
Anyway, as a result for each CA you'd get a distinct Leaf certificate which (if you follow the DAG backwards) gets to a different trusted root. But you are only permitted to send one Leaf in TLS despite the otherwise relaxed constraints.
I think the real innovation in transparency will be client side. I have been wanting to develop a "root CA" hit counter that tracked locally which of the sites you visit used which CA. You could say the logical addition from there is to allow users to disable unused CAs (or do it automatically when unused) and have a opt-in when a disabled one is used, but I think that's too much. Just a client-side plugin to let me see which CA is used and keep track alongside history (i.e. not in incognito) would be nice.
I am waiting for this Chromium issue to implement such a thing: https://bugs.chromium.org/p/chromium/issues/detail?id=628819 (looks already done in FF)
You probably should not encourage lay users to disable CAs they aren't using, it's like those plastic "child safety" plug inserts in the UK - kids already can't actually do the thing the insert pretends to prevent, safety shutters mandated by law in your power sockets keep tiny fingers out of the live power - but the plastic insert is exactly the perfect shape for a kid to defeat the safety protection and electrocute themselves.
Your analogy is unnecessary. This is simply a case of determining which issuing authorities you want to trust. Do I want to trust ones in China? No. That's not racist by the way.
I cannot fathom why browsers can’t pull this off.
I don't think it'd be overkill to send a request to all 52 CAs (and fail if you get conflicting answers). Then the most a trusted CA could do is DoS some sites.
https://wiki.mozilla.org/CA/Additional_Trust_Changes
> The Turkish Government CA is name-constrained to a set of turkish toplevel domains - that is, .gov.tr, .k12.tr, .pol.tr, .mil.tr, .tsk.tr, .kep.tr, .bel.tr, .edu.tr and .org.tr.
Then, let's say it's in China or Turkey or Kazakhstan, etc etc, then I would know that the politicians/police there might have decided to man-in-the-middle listen to anything I type into that website.
And what if there was a Freedom of Press index number (or sth like that) next to this flag? (because who can remember all flags)
Experience shows that if everybody wants a UI feature from a plug-in it won't take long until the people you were plugging into implement it natively and you can choose to take that as praise or shake your fist at them for "stealing". I recommend the former.
But I doubt your new "Freedom of the Press of the CA issuer of this site" UI will be very popular because it's not at all obvious what anybody can do with that information or how to even interpret it.
That is the validity never mind the importance of such metrics is a position of opinion.
Today, it takes a few more clicks to see the detailed certificate information (let alone the CA name), than it used to be.
OK. There are 52 of them, listed here: https://ccadb-public.secure.force.com/mozilla/CAInformationR... although perhaps don't bang on Salesforce's poor server, it seems like for some reason this isn't trivial for them to do?
I do in some sense trust them to always do the right thing, but, as the saying goes "Trust but verify". As well as trusting them I also pay attention to what I see and other people see and press them to do better when they fall short.
I actually think their record has been fairly good, and is gradually improving. It could always be better, but on the whole what I see from CAs is exactly what I'd expect from humans generally, they are lazy and incompetent and so we have to design things to take that into account. I'd expect no more from any of us.
Can you give an example of how you have personally pressed them and how they responded?
> That is, how many certificates were really issued to multiple FQDNs (if a single FQDN the bug described has no effect) more than 8 hours after initial correct CAA checks ? Intuitively this should be almost none, but intuitions can be misleading.
Jacob responded by saying that they were "working on this analysis today" although in fact the next we heard was a complete list of arguably misissued certificates a few days later in an announcement that was linked from Hacker News and which you've hopefully seen.
I wrote (in that Hacker News thread) that this was one way to answer my question :D
Could you elaborate on what transparency you are referring to here? How does it help with the amount of root CAs trusted by the browser? Thanks.
http://www.certificate-transparency.org/home
1. All the trusted CAs log either all the certificates they issue or the vast majority of certificates intended for use on the public Internet. They do this because it's a good idea, and (as we'll see in #2) because it makes commercial sense. The effect is that if you have a way to trick a CA into issuing something that shouldn't exist, or if they just issue it through the usual human fallibility (e.g. an operator fat fingers something at a console) researchers can see it, the same way they'd see if your Senator doesn't bother attending Congress - it's a matter of public record.
2. Google's Chrome, and later Apple's Safari require SCTs (Signed Certificate Timestamps) from logs before they accept newer certificates. The cheap easy way to arrange this is to log "pre-certificates" which get you valid SCTs and then you bake those inside the real certificate given to a subscriber. If you use Let's Encrypt, this is how SCTs got inside all your certificates, no extra work for you. There are fancier options that let you get a certificate and then obtain SCTs later separately, but they're rather niche. This means if you can obtain an apparently valid certificate but only a new enough one (thus after enough time in the future, any certificate) but no SCTs for it, it won't be valid in those browsers. The logs aren't supposed to give out an SCT without logging the certificate. So now an attacker needs to either log their bogus certificate (if they can) and show it to the world, or corrupt the logs too, a big ask on top of whatever attack they've done to trick or corrupt the CA issuer or bypass them.
3. Eventually the intention is a Gossip protocol. The idea here is, when you browser sees an SCT we should like to verify that the associated certificate was really logged irrevocably for everybody to see. But we'd like not to undo your privacy in the process. You don't want to tell everybody "Hey I like Balloon Porn" but you'd ideally like to be sure the certificate on your Balloon Porn website is seen in the logs by everybody, not just a special version of the log shown only to you and six other people under investigation for liking Balloon Porn. Figuring out the best way to approach this is an active research topic.
I don't get why it is always authoritarian states that is pointed fingers at when history clearly shows us that it isn't authoritarian states that are the biggest problem but so-called democratic states. I get why one would dislike authoritarian states (I do too) but the smart move is to look at who history tells us not to trust - not just believing the bogyman is coming.
It's also been shown recently that not all companies are great at managing their certs, with notable shutdowns associated with expired certificates. Increasing the frequency of updating certs should be a good thing, but in practice I'm afraid that it will remain a manual project for some time to come.
Unless CAs insert themselves more into the process of code signing, S/MIME, GPG or something like that. They will remain under the heavy influence of browsers.
Chrome and Safari both have browsers which implement a check such that you need to present enough "qualified" SCTs or the certificate is treated as invalid.
The easiest way to pass that check (for certificates you're going to sell or give to webmasters with no clue) is to log a pre-certificate with Google, and with at least one (preferably two) other logs that Apple and Google agree are trustworthy - then bake the SCTs you get back from those logs into the X.509 certificate you're issuing.
But these are not Trust Store policy requirements. If you in fact choose to issue (for a number of reasons some CAs do) without logging that's still permitted, the certificates just won't be trusted in Chrome or Safari. You obviously won't get far selling certificates that don't work out of the box in Chrome or Safari to the average punter, but not every customer is the average punter.
Apple's declared intention is that Safari will not trust long-lived certificates. But as far as I've seen it is not specified that they would consider a CA which chooses to issue such certificates to violate Apple trust store policy and pursue any sanction or demand revocation. The certificate just doesn't work in Safari.
Now, today Mozilla's Firefox is in a different situation from Safari and Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical enforcement. Mozilla works hard (and in public where we can all see) on policy decisions, but most of them are not enforced in its flagship browser product. Mozilla champions CT logging for example, but a brand new certificate presented with no SCTs works fine in Firefox even though it'd be rejected by Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even though those are the limits set in policy, and so following Apple's suggestion wouldn't actually be easy for them, there isn't a line of code (as there is in Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds, which can be adjusted to say 398 or some other number of days instead of 825.
The fact that browsers have so much say in how the CAs operate that database makes me think that the public CA system is actually a wildly successful failure. If the public CA system has no other use than to allow someone to securely connect to one of a handful of web browsers then why all the fanfare over just having letting the companies stewarding the browsers run the show entirely?
The Nine Planes of the Internet would be connected. Níðhöggr, Dáinn, Dvalinn, Duneyrr and Duraþrór would be in their ordained places, no longer roaming lost in endless Violation of the Layers.
It would also be very easy to detect any misrepresentation. Email contains a link to a domain that isn't on your cert? Alarms / no clickable links / etc.
No cross domain links would disrupt a lot of current emails, but most senders would likely setup in-domain redirectors to carry on their current mailing patterns. Unfortunately, some of those would probably be open redirectors (because it's easy to make an open redirector and it "solves" the immediate problem), leading to some amount of security issues.
Estonia's national system and its e-services are a local example of a single central PKI. Provided services and systems seem to be far ahead of basically all other countries.
Identity theft, identification, authentication, signing etc. have been solved for nearly two decades now and I have to say the way the rest of the world does stuff looks stone-age to me.
For example I loathe how I've been asked to do identity verification by foreign companies "send us a picture of your ID", WTF. Sentences like "Use SMS 2FA to protect your account", "e-mail us the bill" and "come to our office to sign {x}" make me shudder, it's absolutely dogs*.
I think the point is more that even the (massive) concentrated effort it takes to patch the IDs will be less than the collective impact of not having those IDs at all (in terms of the convenience it would add to peoples’ lives) OR having the IDs without the patches at all.
Someone else thread mentioned S/MIME. S/MIME might be a failure, but S/MIME is a thin wrapper around CMS (Content Messaging Syntax), which is widely deployed standard for signing, authenticating, and encrypting content. It's based on the same ASN.1 standards as PKIX. And like PKIX, the root authorities are whatever you want them to be; the standards just provide the syntax and semantics for building the PKI and providing interoperable messaging.
Correct me if I'm wrong, but AFAIU CMS is the basis for various European digital identity systems. See, e.g., https://en.wikipedia.org/wiki/CAdES_(computing)
Your point about S/MIME and CMS kind of makes my overall point for me. Sure. A global PKI is super useful for making things like CMS happen.
What PKI does usually imply is some sort of top-down tree of trust and mechanisms and policy for managing and verifying that tree. But the roots of that tree of trust don't have to be global, and with the exception of Web PKI aren't.
You're creating the straw man. You keep saying that new protocols don't need PKI. Well, if we accept your criteria for what PKI means, and considering that the only example that meets your criteria, past, present, or future, is Web PKI, then what exactly is the point of your argument?
If you have a beef against PKIX, CMS, X.509, ASN.1 etc--i.e. the mechanisms--then just say so. There's a ton of reasonable criticism to be made there. But those things are not equivalent to "PKI". There are plenty of PKI systems out there that make use of alternative mechanisms, though mostly proprietary and hidden as interoperability usually demands making use of pre-existing standards. But, to reiterate, using those standards to build a PKI system absolutely does not require relying on the same global roots of trusts. Nothing in those standards even identifies such a root or the shape of the tree at all.
Primarily because very few e-mail clients support it and no web client seems to.
> Correct me if I'm wrong, but AFAIU CMS is the basis for various European digital identity systems
Yes, they're in theory trying to legislate the same thing across EU what Estonia has done.
SSH's trust-on-first-use system is only secure under the assumption that you "usually" aren't being MitMed; this ought to be improved. For the typical server administration use case, I'd prefer a design that doesn't involve PKI – like encoding a hash of the key into the SSH command – but domain validation based on Web PKI could still be better than nothing. (Perhaps using some subdomain owned by the hosting provider, as opposed to the public-facing domain(s) for the server.) Domain validation would also be ideal for use cases where you're connecting not to your own server but to some known entity's, such as SSHing to GitHub. As for SSH CAs... I've never heard of them before. :) Looking it up, I see that some organizations use them, but I'm not sure their design is a good fit for the kind of non-organization-internal use cases I'm thinking of.
As it stands today, Signal's public key system is largely security theater since nobody bothers to check authentication codes. Even when people do check them, you always have an excuse for changing your code out of the blue (got a new phone, had to reset my phone, etc.), which an attacker can take advantage of. The latter could be fixed by having a better way to transfer trust between devices, but Signal could still have a better story for initial authentication than trusting the phone system. Now, I don't think a traditional PKI would help. But I do like what Keybase is doing here, bootstrapping trust off of a collection of signed attestations on social media accounts. I'd argue this amounts to a PKI in its own right, one where social media providers (unknowingly) play the role of CAs.
Firstly you often don't need a PKI, and when you do need a PKI (which as I said is less often than people think) you often don't need a public one.
Take EMV ("Chip cards"). There's public key crypto securing your payment card transaction. There are multiple organisations involved. So we've got a PKI, but does it need to be a public PKI? Why not just let EMVco run everything, probably badly, and have them and their members (the banks and other big financial firms) eat it when inevitably they do a bad job? So that's what happens. If a CA in the EMV ecosystem does a bad job your bank will end up eating the cost of that, or maybe your country, the headline won't be "Obscure CA misissues certificate" it'll be "Huge Bank loses $500Bn in IT catastrophe" or something.
Secondly, the thing a PKI does relies upon is a common naming scheme. The standard actually used in the Web PKI, X.509 was designed for a world with a global directory of everything, the X.500 global directory system. That directory does not exist. What common naming schemes are there that we'd want digital certificates for?
The IETF published RFCs from the PKIX working group, defining how X.509 can be used for the Internet's names. That is, mostly ipAddresses, dnsNames, and emailAddresses.
The Web PKI concerns itself de facto with the first two. You could and some people do use IP addresses or DNS names in a context outside the Web PKI, but mostly they don't. "Don't roll your own". Even the successor to TCP, QUIC, was re-designed to have it just envelop TLS and thus depend upon the Web PKI, rather than inventing a new shiny public key crypto technology and associated PKI.
So the only use case we actually care about that didn't end up happening was email, S/MIME is what was attempted and... I have no doubt Thomas Ptacek can explain at considerable length how unlikely it is that anybody can get that to do what you'd expect it to do and deliver you any meaningful security if you're interested.
It should definitely give you pause when you see a system which really seems like it could only be secured by a PKI and it isn't the Web PKI. Is it a private PKI? Who has oversight? Or are they just going through the motions and the security is illusory? The answer is the latter pretty often. Stakes are often thought to be very low until they aren't...
Honestly I would love it if my password manager would also act as a personal certificate authority.
It would be nicer if certs could be issued with long lives but required a stapled revalidation with a short time span (daily? weekly?), which would be automatically issued at any time requested unless the certificate was revoked.
That's called OCSP Must-Staple: see https://en.wikipedia.org/wiki/OCSP_stapling, https://github.com/acmesh-official/acme.sh/blob/d437d6fde95d..., https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...
https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...
That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say "killtrump.example is not acceptable, revoke their certificate" Let's Encrypt says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say "Please reconsider this seems like a bad idea" and then Microsoft can say "We've thought about it, revoke" and the choice is only whether Let's Encrypt wants to remain trusted in Microsoft's products.
Nobody else has a rule like that, and it isn't a new rule, it's a published part of Microsoft's policy. Microsoft says they use it only to protect Microsoft's customers from phishing and similar attacks. Perhaps that's even true.
Imagine a weird little town with 6 people who buy all the groceries and a 60 grocery stores. The stores get together periodically and meet with the 6 shoppers to talk about what the stores should stock. Maybe they even vote.
That be a useful set of meetings.
But ultimately those 6 customers are going to buy whatever the hell they want to buy, regardless of how the votes went.