3 ms·
Once an unreliable CA gets "trusted" and its public key added to browser bundles, that's when they can pivot to allowing undetectable surveillance of traffic, b
by pfarnsworth 9y ago
Once an unreliable CA gets "trusted" and its public key added to browser bundles, that's when they can pivot to allowing undetectable surveillance of traffic, by allowing access to private keys. Things like local DNS poisoning, etc, are all easy to do, and if you can create your own www.google.com certs temporarily, there's no limit to how much traffic you can acquire.
- alwillis 9y agoWhat are you talking about? The root certificate for this CA is already baked into our browsers; otherwise, there would be no way for them to issue working certificates. It’s actually much more difficult to issue a cert for a domain like “www.google.com”: - Google uses Certificate Authority Authorization (CAA) which tells the internet that only Google is allowed to issue certificates for google.com - Google uses HTTP Public Key Pinning (HPKP) headers that shows the hash of the public key that will be trusted; a cert issued for google.com by a rogue CA can’t have the same public key and thus won’t be trusted. - Google created the idea of Certificate Transparency (https://www.certificate-transparency.org); https://www.certificate-transparency.org); almost all certificates are logged publicly in cryptographically signed databases (blockchains actually) which anyone can examine. It would be obvious in a few minutes that a certificate were issued for google.com, assuming it could be done. Google, Apple, Mozilla, etc. won’t trust certificates that aren’t in CT logs. Here’s the info on Google’s latest certificate issued yesterday: https://crt.sh/?id=354538345 https://crt.sh/?id=354538345 The best part: everyone has access to these tools and standards, not just big companies. My free certificates from Lets Encrypt also go in Certificate Transparency logs, just like Google’s.