I honestly don't think the location should be a factor. How many countries are there that don't have things like national security letters?
I'd rather have a system where the same criteria apply to all CAs independent of their jurisdiction, coupled with mechanisms that guarantee transparency (like Certificate Transparency) and stuff like key pinning.
I don't think the general public realizes how important this is.
I only recently found out that anyone that can reliably man in the middle your server can get a valid HTTPS cert from CA's like Let's Encrypt. That includes cloud providers, backbone providers and possibly the local government where the server is located. [edit: It also includes anyone that can temporarily modify or spoof your DNS records.]
True! As someone working on Let's Encrypt, I'd like just to point out that this possibility didn't start with Let's Encrypt, but is generally true of CAs that issue using domain validation (DV).
The CA/Browser Forum has endorsed a variety of ways of proving control over a domain; for each of them, if some CA uses it and you can spoof it, you might be able to get that CA to misissue a cert for that domain.
The desire to somehow tighten this up is in tension with the desire to make HTTPS ubiquitous, and an underlying problem is that we're on the Internet where there is no central identity mechanism or source of proof of identity assertions -- except perhaps the DNS root and all of its associated registration and delegation mechanisms.
Maybe someday we could slightly clean up DV by making the proof of domain control go through DNS domain registries, since they're the underlying source of authority or ground truth in the DNS system right now. We could imagine a protocol where a CA has to ask the registry whether a particular certificate request is really from an entity that the domain registrant has approved, and both the CA and registry could publicly log the question and answer. (Perhaps we'll also have certs for other kinds of naming systems as well.)
In the meantime, you can make a CAA record, use HPKP, like pfg said, and check the Certificate Transparency logs. None of those are perfect, but they're a lot better than what we had with DV five years ago.
> imagine a protocol where a CA has to ask the registry
Or maybe registries could directly act as CAs for their own TLDs (and no others). It would be an interesting discussion about how this would be better or worse than what we have now.
I imagine a lot of registries wouldn't want to pay for the infrastructure to do this, but maybe it should be regarded as a basic part of their role. Right now it would be very annoying because you could no longer get a cert for multiple names under different TLDs, at least if they were managed by different registries (so you couldn't get a single cert covering example.io, example.cc, and example.net, even if you controlled all three names). Maybe if SNI becomes more ubiquitous this limitation will seem less annoying in the future.
This idea is DANE with DNSSEC, and it is unlikely to be adopted. tqbf has a good blog post[0] about why it's probably not a good idea (disclosure: I agree).
That article starts off by saying that DNSSEC slightly improves the security of DV certs, but not sufficiently.
What I was suggesting above was having domain registrars or registries use a new protocol (not DNSSEC) specifically to authenticate domain registrants to CAs for improving the security of DV certs -- and in order to replace existing DV mechanisms. My thought is that registries and registrars together possess the ground truth about domain ownership in the DNS system, and so it would be helpful if they had a way to securely communicate that directly to CAs. I didn't mean to suggest that DNSSEC should be that way.
I don't think this would be vulnerable to any of Thomas Ptacek's particular criticisms of DNSSEC, unless the first section implies that he wanted to completely eliminate DV certs or stop trusting them as a general matter. I didn't read it that way. However, we might take the article to imply that DV certs, even if they could be guaranteed to match up perfectly with the DNS ground truth at all times, may never be enough as the main or only means of authenticating some entities for some purposes, which is also fair.
The issue really isn't using DV (domain validation) or EV (extended validation), but the fact that the validation chain a particular client sees can be different from what everybody sees. The CA system could by augmented by various distributed trust and result consensus systems.
I wonder if this is a service Akamai/Amazon/Google/whoever-wlse-runs-lots-of-cdn-endpoints could sell to CAs? A kind of "reverse CDN request", where they can return (over TLS connections) a web page fetched from tens or hundreds of different edge servers all at once?
That'd at least mean an attacker would need to be MITMing the connection close to your server/loadbalancer instead of near to the CA?
Wouldn't help if someone was doing a Quantum Insert style attack from within your hosting infrastructure. (I wonder if there's pre-build AMIs to let you quickly spin up open source implementations of Qantum Insert on AWS already?)
'All at once' is being DDOS'd so you wouldn't want that.
In general, you are going to be MITM'd near your endpoint (ISP level DNS tricks, or on your WiFi) or near the destination endpoint, very rarely somewhere in the core (although that has happened with some BGP hacking). To prevent the client being mitmd you can ask something else on the internet what their cert resolution chain was.
If the server can be mitmd with a valid cert the only solution is for all clients to contribute to a distributed consensus -- appending the cert chain they see to a distributed log.
Cross-nationality cert validation would be good. Ie a cert signed by US and DE and RU registrars, with that list in the cert, combined with advertising via a distributed ledger what had been signed by whom.
I'm not sure which part of my reply you think is not possible - if it's the "guaranteed transparency" bit, that is very much possible and is the end-goal for Certificate Transparency. There is no way to "bypass" this with laws.
Most CAs that operate today are located in countries where mechanisms exist that could very well be used to force a CA to hand over private keys and/or sign certificates, not to mention that some intelligence agencies (or other actors) might use not-so-legal means to achieve the same thing. So why bother trying to enforce some kind of "NSLs (&co.) are bad unless you're one of The Good Guys" rule rather than embracing a mechanism that guarantees that CAs will be caught when they engage in such behaviour (willingly or not)?
Are you implying nation states are going to prevent browser vendors from implementing mandatory Certificate Transparency? Why haven't they done that for HPKP, which would allow ISIS to prevent being MitM'd as well? What about all those E2E-crypto messengers out there?
True.
But I've heard this before by European providers avoiding US-based certificates.
That doesn't make it any better, but this is a persistent myth, not limited to chinese customers.
That's not how the CA system works. Your security is unaffected by what CA you choose; it is invariably the minimum of all trusted CAs.