The EU is poised to pass a sweeping new regulation, eIDAS 2.0. Buried deep in the text is Article 45, which returns us to the dark ages of 2011, when certificate authorities (CAs) could collaborate with governments to spy on encrypted traffic—and get away with it. Article 45 forbids browsers from...
Centralized CAs were and are a mistake. HTTPs should work more like ssh-keys where the first time you connect to a website it’s untrusted, but once you have validated it the website you want, it never bothers you again unless the private key changes. Private key rotations can be posted on public forums, or emailed, or any number of other ways and users that don’t care can ignore the warnings like they do anyway, while users who DO care, can perform their own validation through other channels.
The most important aspect is that there is no “authority” that can be corrupted, except for the service you are connecting to.
There is no way a user can know the website is real the first time it’s visited, without it presenting a verifiable certificate. It would be disastrous to trust the site after the first time you connected. Users shouldn’t need to care about security to get the benefits of it. It should just be seamless.
There are proposals out there to do away with the CAs (Decentralized PKI), but they require adoption by Web clients. Meanwhile, the Web clients (chrome) are often owned by the same companies that own the Certificate Authorities, so there’s no real incentive for them to build and adopt technology that would kill their $100+ million CA industry.
There is no way a user can know that their traffic hasn’t been man-in-the-middled by a compromised CA either. And why is it “disastrous” to trust a website after you have cryptographically verified its the same website you visited before? It would present the same public/private key pair that you already trust.
Where does the initial cryptographic verification come from? I’m not arguing that you can’t pin certificates.
That’s where the SSH analogy comes from. On the initial connection you get the signature of the web-site you are trying to visit and your browser trusts it from then on. If something changes later, then the scary warning comes up.
I hope for you, that you don’t SSH into any random machine and just import their cert.
Usually you know the machines you are trying to connect to. That gives you the ability to add their cert to your trusted hosts before connecting the first time. So for browsing the WWW this makes not much sense, since you connect to way too many unknown hosts. It would create a ‘red is green’ mentality where users just import any unknown cert.
The only similarity i see, which makes sense, would be e-banking and such. The bank could send you their certificate with the login credentials by post.
Why? There is absolutely zero risk in SSHing into “random” machines especially since I’m using public ssh-keys. Of course the first time I connect to a machine it’s going to be untrusted, but who cares? I’m using SSH to ensure others can’t sniff my traffic.
If i want to sniff your traffic, ill set up another machine as MITM attack.
I guess as long as you stay inside a secure company network, it wouldn’t be that bad. But if you go through the WWW, my advice is to manually add trusted hosts.
Setting up a mitm on the internet is a non-trivial task and I’m quite confident you have neither the access, nor the ability to do that. Very few people do. So let’s just say that isn’t an attack vector that anyone should be concerned with.
No one can remove all risk but the security threshold between intercepting an initial connection and compromising a CA are vastly different. The latter would be much more difficult to pull off which is why we use them. Sounds like this EU rule is going to put a ceiling on that though.
making sure a small part is very secure vs having to verify every domain I visit? yeah, let me keep using the current system… are you aware of the amount of domains you connect to every day?
Also, I might be wrong, but if I remember correctly browsers/OS-es tend to come with a list of trusted certificate keys already, which makes adding compromised keys to that list not as easy as you suggest. (I don’t even know if that happens or if they just update as part of security updates of OS/browsers)