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...
A better solution would be to have both at the same time.
Browser says: x number of CAs say that this site is authentic (click here for a list). Do you trust this site? Certificate fingerprint: … Certificate randomart: …
And then there would be options to trust it once, trust it temporarily, trust it and save the cert. The first 2 could also block JS if wanted.
I can see this would annoy the mainstream users, so probably this should be opt-in, asked at browser installation or something like that.
But you only really need one to say it’s authentic. There are levels of validation that require different levels of effort. Domain Validation (DV) is the most simple and requires that you prove you own the domain, which means making a special domain record for them to validate (usually a long string that they provide over their HTTPS site), or by sending an email to the registered domain owner from their WHOIS record. Organization Validation (OV) and extended verification (EV) are the higher tiers, and usually require proof of business ownership and an in-person interview, respectively.
Now, if you want to know if the site was compromised or malicious, that’s a different problem entirely. Certificates do not and cannot serve that function, and it’s wrong to place that role on CAs. That is a security and threat mitigation problem and is better solved by client-based applications, web filtering services, and next-gen firewalls, that use their own reputation databases for that.
A CA is not expected to prevent me from hosting rootkits. Doesn’t matter if my domain is rootkits-are.us or totallylegitandsafe.net. It’s their job to make sure I own those domains. Nothing more. For a DV cert at least.
Public key cryptography, and certificates in particular, are an amazing system. They don’t need to be scrapped because there’s a ton of misunderstanding as to its role and responsibilities.
The plan was to have criminals use the storefront — an online end-to-end encryption service called Tutanota — to allow authorities to collect intelligence about them.
Oh, yes, sorry, I had a brainfart. Certs don’t usually (or at all?) have more than one root cert.
A CA is not expected to prevent me from hosting rootkits. Doesn’t matter if my domain is rootkits-are.us or totallylegitandsafe.net. It’s their job to make sure I own those domains. Nothing more. For a DV cert at least.
I thought that was the goal. Not to make sure that the website is secure, but that the connection is secure, and that I’ve connected to the server that I expected.
I don’t really care if a site is who they say they are, I’m the one connecting to the site, if the site does what I expect, they are serving their purpose. The only thing I use SSH/HTTPS for is to make sure that whatever communication between me and the site can’t be snooped. A CA allows a third party to snoop that traffic, and I have no indication they are doing it.
You are missing half the purpose of PKI. Identity is equally, if not more, as important as encryption.
Who gives a shit if your password is encrypted if somebody intercepts DNS and sends yourbank.com and makes it go to their own server that’s hosting a carbon-copy of the homepage to collect passwords?
And DNS isn’t the only attack vector for this. It can be done at the IP level by attacks that spoof BGP. It can be done by sticking a single-board computer in a trashcan at a subway stop. Have it broadcast a ton of well-known SSIDs and a ton of phones in the area will auto connect to it and can intercept traffic. Hell, if not for trusted CAs, it’d be very easy to just MITM all the HTTPS traffic anyway.
In reality, you would tofu the first website you went to and not know if it got intercepted or if they just rotated keys (which is also a common security practice and is handled by renewing certificates and part of the reason why publicly-issued CAs are trending down the life of certificates and it’s not a big deal for admins because of easy automation technology. HSTS and cert pinning is more of a PITA but really barely any effort when you consider the benefits of those).
Now, what certificates don’t protect, nor claim to protect, is typosquatting. If you instead go to yorbank.com, that’s on you, and protecting you from a malicious site that happened to buy it is the job for host-based security, web filters, and NGFWs.
A better solution would be to have both at the same time.
Browser says: x number of CAs say that this site is authentic (click here for a list). Do you trust this site? Certificate fingerprint: … Certificate randomart: …
And then there would be options to trust it once, trust it temporarily, trust it and save the cert. The first 2 could also block JS if wanted.
I can see this would annoy the mainstream users, so probably this should be opt-in, asked at browser installation or something like that.
But you only really need one to say it’s authentic. There are levels of validation that require different levels of effort. Domain Validation (DV) is the most simple and requires that you prove you own the domain, which means making a special domain record for them to validate (usually a long string that they provide over their HTTPS site), or by sending an email to the registered domain owner from their WHOIS record. Organization Validation (OV) and extended verification (EV) are the higher tiers, and usually require proof of business ownership and an in-person interview, respectively.
Now, if you want to know if the site was compromised or malicious, that’s a different problem entirely. Certificates do not and cannot serve that function, and it’s wrong to place that role on CAs. That is a security and threat mitigation problem and is better solved by client-based applications, web filtering services, and next-gen firewalls, that use their own reputation databases for that.
A CA is not expected to prevent me from hosting rootkits. Doesn’t matter if my domain is rootkits-are.us or totallylegitandsafe.net. It’s their job to make sure I own those domains. Nothing more. For a DV cert at least.
Public key cryptography, and certificates in particular, are an amazing system. They don’t need to be scrapped because there’s a ton of misunderstanding as to its role and responsibilities.
Oh, yes, sorry, I had a brainfart. Certs don’t usually (or at all?) have more than one root cert.
I thought that was the goal. Not to make sure that the website is secure, but that the connection is secure, and that I’ve connected to the server that I expected.
I don’t really care if a site is who they say they are, I’m the one connecting to the site, if the site does what I expect, they are serving their purpose. The only thing I use SSH/HTTPS for is to make sure that whatever communication between me and the site can’t be snooped. A CA allows a third party to snoop that traffic, and I have no indication they are doing it.
You are missing half the purpose of PKI. Identity is equally, if not more, as important as encryption.
Who gives a shit if your password is encrypted if somebody intercepts DNS and sends yourbank.com and makes it go to their own server that’s hosting a carbon-copy of the homepage to collect passwords?
And DNS isn’t the only attack vector for this. It can be done at the IP level by attacks that spoof BGP. It can be done by sticking a single-board computer in a trashcan at a subway stop. Have it broadcast a ton of well-known SSIDs and a ton of phones in the area will auto connect to it and can intercept traffic. Hell, if not for trusted CAs, it’d be very easy to just MITM all the HTTPS traffic anyway.
In reality, you would tofu the first website you went to and not know if it got intercepted or if they just rotated keys (which is also a common security practice and is handled by renewing certificates and part of the reason why publicly-issued CAs are trending down the life of certificates and it’s not a big deal for admins because of easy automation technology. HSTS and cert pinning is more of a PITA but really barely any effort when you consider the benefits of those).
Now, what certificates don’t protect, nor claim to protect, is typosquatting. If you instead go to yorbank.com, that’s on you, and protecting you from a malicious site that happened to buy it is the job for host-based security, web filters, and NGFWs.