Also browsers should display a warning when a certificate issuer for a website changes.
What you are proposing is an attempt at solving an entirely different problem that is, furthermore, largely orthogonal to ensuring the integrity and confidentiality of Internet traffic. It would be nice if that problem were solvable, but every time the Web PKI flirted with that it ended horribly[2]. (And now the EU authorities are trying to force it anyway, it seems[3].) Ensuring your bytes end up on the host you named, intact and unsnooped, is a comparatively easy problem that’s also pretty meaningful, and it seems smart to restrict ourselves to that. (I’d have advocated for DNSSEC+DANE instead of CAs, even, if I had any confidence at all in the DNS registrars’ ability to handle key material and willingness to give up domain control when that ability fails.)
[1] https://arstechnica.com/information-technology/2017/12/nope-...
[2] https://www.usenix.org/system/files/sec19-thompson.pdf
[3] https://scotthelme.co.uk/looks-like-a-duck-swims-like-a-duck...
That is, am I simply being phished in private or is the government also listening to me being phished?
It's trivially easy to solve the second problem and it doesn't require any PKI infrastructure whatsoever and we delayed secure transport by decades by tying it to the generally less-useful question in #1.
There are few entities online I trust more than I would trust someone impersonating them: basically only if money is changing hands. But I don't need to know that e.g. ycombinator.com is actually ycombinator.com because I don't trust ycmonbinator.com any more than I would trust someone impersonating ycombinator.com.
And then you find out there are ways to convert a passive eavesdropper into an active attacker (remotely injecting packets to manipulate the TCP connection state, based on observed sequence numbers), and the distinction becomes a bit fuzzy...
A) Long lived
and
B) why having an untrustworthy root CA is the most calamitous outcome possible.
Because the algorithm that yields the answer to your question really only answers the question "Does the cert I was handed cryptographically validate back to a trusted root?"
If you can pwn the routing/DNS sufficiently around an AS, you could MITM all the authoritative sources, and with something like TrustCor, willing to issue duplicitous root certs and cert chains, while being trusted by major OS and software package maintainers, you can, in theory, pull the old switcheroo, and the software will still tell you "seems legit, hoss".
This is part of why the Internet is architected as a "collective network of networks composed of Trusted Agents".
At the end of the day, you're depending on every middle box routing your packet to do the job to get it where it needs to go.
The type of Trust you're looking for is incompatible with technologically facilitated networking in a sense. The network cannot prove the trustworthyness of the network. Trust has to start outside it.
The trust we've rooted from is from the integrity of the institutions we've established. Something that has been eroded more and more over time as the Internet infrastructure has slowly been civically infiltrated to shape it into a surveillance tool by governments.
If you're feeling heartburn over this, the problem isn't the Internet per se. It's your Government, and your institutions, and for places that like to think they are populace driven, the people around you.
1. registering google.com requires it being available, and their registry and registrars prohibit registering already-registered domains
2. these registries contain the authoritative DNS records for google.com
3. when anyone wants to pull a certificate for `www.google.com`, they first need to create a DNS TXT entry called "acme-challenge.google.com" (for example)
Because of this, you know that whoever 'says' they're Google.com actually is Google.com because of how domain names work and because you see the lock icon in your browser. It's all built on trust of registries and registrars operating diligently, and it's checked by pretty much every big company watching for changes to their domains in case of malicious actions.
In this context it’s funny that https://satan.com redirects to https://mybible.com.
But I agree with you on the sentiment that stopping snooping technically is the easy part and this is already possible today with Public Key Pinning, DNSSEC, client certificates and so on.
But that's why I think the role of the CA should change so that the signatures actually gives some form of tangible trust that people can relate to.
But this is a tough thing to do. The best way to do this would be to introduce a new type of certificate, that can be stapled onto web requests maybe (eg. a signature at the end of the http body), that isn't controlled or authenticated by any existing system. This would allow clients to implement this system based on merit and based on whether or not it solves problems and concerns these clients have. For example, if it's literally just EV certificate boogaloo[0], then Chrome can choose to not implement it.
But when you try to force it onto people in the form of QWACs or what have you, and have it government-mandated, this goes against the theory of 'open source' standards being adopted because they're a good standard, and instead degrades user experience by forcing client vendors to implement them regardless of their flaws.
0: https://scotthelme.co.uk/the-power-to-revoke-lies-with-the-c...
What we should do is to delegate the few CAs that legitimately do non-domain validated certicates for specialized applications to only this. That includes things like signed code. Things like extended validation was invented solely to print more money and should be phased out of web browsers. They are not "more secure" and should not be regarded as such in any user interface.
The parties to issue domain validated certificates should be the domain registries. They do their job reasonably well already. They are already tasked with issuing domain ownership. It is only natural that they should validate this ownership cryptographically as well. It is a trivial extension to their business, and the registry/registrar model can be kept intact.
The trust chain for a domain validated certificate today includes both the registry and the CA, and either can fail. The risk is strictly minimized by removing the CA from the equation. CAs provide no value to the end user.
You will find several high profile people arguing against this. Do note that every one has vested interest in the status quo, either directly or indirectly by having CAs and governmental agencies as their clients.
How do we change this system? Mozilla has by way of their history some weight in these matters, and several capable people on board. It is my intense hope that they have a long term plan. Let's Encrypt is, as great an achievement as it is, still built on a broken trust model. But it could also be an excellent beachhead into a strictly better trust model for the end users.
For example, Azure's Key Vault has built-in certificate issuance automation capability, but only with two for-profit CAs: DigiCert and GlobalSign.
Why not Let's Encrypt?
Because there's no margin on free.
I think it would be great if something like EV certificates were available from national governments.
We have pretty solid digital ID support in Austria, but all the tech for signing and authenticating documents (useful for invoices or account statements) require special software, and aren't built into web browsers and email clients that people use.
It would be nice if I clicked a link in an invoice email, if I could check that aws-billing.at is indeed a domain that belongs to "Amazon Web Services" registered in Austria or if it is a phishing attempt from a script kiddie in a foreign country.
For domains this assumption been proven wrong in practice several times. There are too many issues with almost identical names, or names that merely look identical but aren't, or just the difference between "Amazon Web Services Inc." in two different jurisdictions.
Troy Hunt has made several long blog posts with some convincing real world examples.
It is easier for end users to see which is more reputable of "amazon.com" and "amaz0n.biz", than it is to value "Amazon Inc." against "Amazon Cloud Services". It is not that the CAs are doing a bad job. It's that domains are the identity we really care about.
Furthermore, I am of the opinion that CAs should be destroyed.
I think it would harm users relying on certain sites. This already happened with CNNIC and .cn, so I don't think that mandatory restrictions would make it better (and besides, the only CAs which voluntarily ask to restrict issuance to certain TLDs are government CAs).
Care to elaborate? I don't really understand how it harms users.
Also to clarify: restricting it to specific TLDs where the CA physically operated would amplify local laws, while restricting it to TLDs that are outside the CA's physical presence would basically mess up enforcement and would spur governments to curate a mandatory sanctioned list (heard of EU QWAC?) It's a lose-lose case either way.
I don’t understand the “amplifying local law” part. How is restricting the power amplifying?
That's not an example of limiting CAs to certain TLDs; that's an example of limiting certificate users to a single CA. I'd sooner use a self-signed certificate than one signed by a monopoly government-controlled CA.
Still, the name constraints extension, which restricts all certificates (transitively) issued from a given CA to a given DNS subtree, has been in the “Internet profile” of X.509 (PKIX) since the December 1996 draft[2]. The problem from this technical point of view is that very few implementations supported it until a couple of years ago[3].
[1] https://medium.com/@sleevi_/x-520-whats-in-a-name-da6ea8954b...
[2] https://datatracker.ietf.org/doc/html/draft-ietf-pkix-ipki-p...
It just turns out that delegating trust to root CAs, CAs, and browser/OS vendors (the latter via built-in certificate lists) makes it easy for the end user.
Netscape invented all this stuff in the 1990s as SSL. Turns out you need a PKI to make it work, because of a tricky edge case which otherwise makes the whole thing worthless. So, they used the existing but little used X.509 PKI left over from the X.500 directory work, even though the Internet is not part of the envisioned global network X.500 is for. The X.509 PKI had a bunch of famous brand "trustworthy" companies minting certificates.
PKIX, an IETF working group to figure out how to force X.509 to be suitable for the Internet, adds stuff like SANs (Subject Alternative Names, a way to express Internet ideas about naming like IP addresses and DNS names) but that all happens after SSL 2.0 and SSL 3.0 and people start writing https URLs.
This flexibility is what allowed let’s encrypt to bootstrap, right?
Obviously, that broke down over time, and nefarious actors (both governmental and private) popped up.
Peer-to-peer? That would require you to constantly monitor the activity of those peers and update your lust of trusted certificates.
Singular trusted entities like browser or OS vendors? We already have that. Browser/OS certificate list are currently the entry point and have even higher priority than root CAs -- that is what the article is about.
Government bodies are an easy-to-go "trusted" entity because, while you may or may not actually trust them, you are forced to "trust" them in many aspects of daily life anyway. You are forced to rely on the fact that the police doesn't randomly knock on your door and arrest you. Governmnent bodies may (depending on your country) simply demand higher taxes than you owe them, and you have to fight a lawsuit to avert that. Government bodies can easily falsify evidence that makes you lose your house because it now says that somebody else is the owner (lawsuit again).
Basically, establishing trust in a matter of "I am actually talking to the legitimate server behind example.com and not a MITM" is easy, that could be solved by DNSSEC and cert pinning (although for legacy reasons, we went with CAs as the middle man).
But the really interesting thing, which is unsolved to date, is making sure that when you type "bank.com" in a browser, you have some sign that you are actually talking to Bank LLC and not some other entity.
In ye olde times, you didn't have to worry about someone else spoofing the domain name of "bank.com", e.g. as "b4nk.com" or "bänk.com", for one because access to registering domains was complex and expensive, and for one because criminals hadn't found out they could make money...
This would be better solved if the URL as a middle step did not exist can I could directly select Bank LLC. Right now we rely on google to shield us from domain name spoofing.
But then, unless we exchange keys with an entity beforehand (1), how can I even express that I want to visit that entity's website? Let alone solve the spoofing problem. We have to delegate trust to search engines, browser built-in lists, governments, company registries, whatever.
(1) possible, but only works if you know in advance that you want to communicate with a specific entity. Like before opening a bank account. I does not help when you don't even know which banks make an offer you are interested in.
It can also be turned completely around: only trust a single root certificate. This design is often used in client authentication: each client need to get its certificate signed by the one single CA that's trusted by the server.