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.
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.
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.
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.
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.
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.
Of course, you'd have to do the switching manually.
I cannot fathom why browsers can’t pull this off.
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.
Today, it takes a few more clicks to see the detailed certificate information (let alone the CA name), than it used to be.
That is the validity never mind the importance of such metrics is a position of opinion.
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.
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.
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.
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....
* 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.
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.
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
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...
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
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
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
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.
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.
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.