Competence is difficult to check systematically. The problem is in the auditing process. The CA auditors check a much shorter list than an application that needs FIPS compliance. They just check that the CA is using a FIPS compliant key generator, and then basic things like following a logged, standard, multi person process.
Anybody writing a system for a bank or the govt needs to have every line of code checked that it’s not doing something stupid with its crypto keys. That level of assurance would have caught this. But the process was defined too weakly.
Certificate transparency requirements effectively take the power away from certificate authorities.
They instead place the burden on individual webmasters again to actually verify that nobody has been falsely issuing for their domains. There are also some new vulnerabilities about CT logs who might be malicious.
I agree this is a burden placed on domain owners, but who else can know if a certificate for my domain 'scotthelme.co.uk' was supposed to be issued other than me, the owner of 'scotthelme.co.uk'?
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
Possibly CT logs revealing information about domain name and IP address spaces, or other information through implementation details, that might not otherwise be public.
There are chains of trust which are established for SSL certs, centered around the idea that if we can believe Mozilla et al. that the server responding is who they claim they are. Up until now, that is good enough to establish the trust needed to accept the 2 keys in the connection are connected, and then a secure connection could be established to the host server.
Mozilla et al. could claim trust for Microsoft and then MS would be an intermediary for Mozilla. There is a long history of sketchy intermediaries like GoDaddy and others that root certificate providers like Mozilla would block at times due to abuse.
This leads to users, usually ones that are not that technically savvy, seeing 'insecure' warnings on a page that actually offers HTTPS. ..but since the root servers no longer accept them as trusted, everything that GoDaddy supported, and every intermediary (child) cert which they approved would no longer be trusted and you would see a non-secure warning.
Which leads to users that are not that technically savvy learning to always click "Load it anyway!" and not think about it, even in financial management firms. Ask me how I know...
Zero would be hard but we could have signed CA cert put into DNS record and from that the org itself can create the certs for that domain.
Then at the very least one of the CAs leaking isn't automatic compromise, as leaking the key still doesn't make you insecure, that would also require intercepting and changing DNS records
In practice we have Certificate Transparency Logs that let us check whether a CA has issued a certificate for a domain you control without you asking them to.
This really reduces how much we need to trust the CAs, because we can detect any untrustworthy actions after the fact. Now detecting after it happened is too late. But it does mean that mistakes or malicious actions are much more expensive to a CA. In practice this has really reduced the risk, especially to those whom aren't interesting enough to burn a valuable capacity on. Which is the vast majority of people. Though perhaps if you count TLS traffic weighted by importance that count is different.
Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
The first time you go to the bank, you do the "trust exchange" (maybe scanning a QR? People sure love that) that verifies future connections, similar to how you acquire digital certificates today when you deal with the government online and similar.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
In retrospect, not having a tiny competency check may have been an oversight.
Competence is difficult to check systematically. The problem is in the auditing process. The CA auditors check a much shorter list than an application that needs FIPS compliance. They just check that the CA is using a FIPS compliant key generator, and then basic things like following a logged, standard, multi person process.
Anybody writing a system for a bank or the govt needs to have every line of code checked that it’s not doing something stupid with its crypto keys. That level of assurance would have caught this. But the process was defined too weakly.
> They just check that the CA is using a FIPS compliant key generator, and then basic things like following a logged, standard, multi person process.
FIPS-compliant key generator allowed key to be 4 ?
No, they just didn't check thoroughly enough
Oh for sure. And at the time these were done, I'd guess cracking them was a lot more work. But still. 4.
1 reply →
That really depends how you define "trusted certificate authorities".
If you're talking about root certs then it's almost 350 currently trusted by at least one major operator.
If you include intermediates, you're talking more than 3,600!
Certificate transparency requirements effectively take the power away from certificate authorities.
They instead place the burden on individual webmasters again to actually verify that nobody has been falsely issuing for their domains. There are also some new vulnerabilities about CT logs who might be malicious.
I agree this is a burden placed on domain owners, but who else can know if a certificate for my domain 'scotthelme.co.uk' was supposed to be issued other than me, the owner of 'scotthelme.co.uk'?
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
Possibly CT logs revealing information about domain name and IP address spaces, or other information through implementation details, that might not otherwise be public.
CT logs stapling proof, but then never actually including that cert in the log.
1 reply →
How are they trusted if they can just generate any key they like in their back room?
"Trusted" means how people treated them, it doesn't mean the extent to which they deserved trust.
This.
Good: trustworthy Often bad: trusted
There are chains of trust which are established for SSL certs, centered around the idea that if we can believe Mozilla et al. that the server responding is who they claim they are. Up until now, that is good enough to establish the trust needed to accept the 2 keys in the connection are connected, and then a secure connection could be established to the host server.
Mozilla et al. could claim trust for Microsoft and then MS would be an intermediary for Mozilla. There is a long history of sketchy intermediaries like GoDaddy and others that root certificate providers like Mozilla would block at times due to abuse.
This leads to users, usually ones that are not that technically savvy, seeing 'insecure' warnings on a page that actually offers HTTPS. ..but since the root servers no longer accept them as trusted, everything that GoDaddy supported, and every intermediary (child) cert which they approved would no longer be trusted and you would see a non-secure warning.
Which leads to users that are not that technically savvy learning to always click "Load it anyway!" and not think about it, even in financial management firms. Ask me how I know...
That's the thing about trust -- in order to get into the root key store for windows, chrome, linux, etc they were trusted not to do that.
they violated that trust.
Correct, we only need zero.
Interesting, what would be the alternative?
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
Zero would be hard but we could have signed CA cert put into DNS record and from that the org itself can create the certs for that domain.
Then at the very least one of the CAs leaking isn't automatic compromise, as leaking the key still doesn't make you insecure, that would also require intercepting and changing DNS records
In practice we have Certificate Transparency Logs that let us check whether a CA has issued a certificate for a domain you control without you asking them to.
This really reduces how much we need to trust the CAs, because we can detect any untrustworthy actions after the fact. Now detecting after it happened is too late. But it does mean that mistakes or malicious actions are much more expensive to a CA. In practice this has really reduced the risk, especially to those whom aren't interesting enough to burn a valuable capacity on. Which is the vast majority of people. Though perhaps if you count TLS traffic weighted by importance that count is different.
3 replies →
Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs.
43 replies →
Stop validating names, start signing content.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
12 replies →
For me the complexity of anything connected to public internet is now over what I can secure.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
I quite like how i2p does it. Public keys are part of addresses, human readable names are user defined and shared but static.
The first time you go to the bank, you do the "trust exchange" (maybe scanning a QR? People sure love that) that verifies future connections, similar to how you acquire digital certificates today when you deal with the government online and similar.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
14 replies →
or, perhaps you need more so that one being stupid doesn't effect so much.
Each CA is like a padlock locked in series with other padlocks. The weakest padlock is the only one that matters.
In a world with CT logs and CAA records, is that actually the case?
6 replies →
> perhaps you need more so that one being stupid doesn't effect so much.
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
I would assume that the client would need to validate the certs against more than 1 trust path (for the comment to make sense)