3 ms·

A free and automated CA goes against exactly what a CA is supposed to be: someone you can trust. If you can't trust the CA, then you can't trust anything relate

A free and automated CA goes against exactly what a CA is supposed to be: someone you can trust. If you can't trust the CA, then you can't trust anything related to the CA. What's the point in having this, besides the convenience of importing their untrustworthy CA key and then using https without getting warnings? I would rather use http.

ameliaquining 9y ago
Trust to do what? What matters is whether they can be trusted not to misissue certificates. For Domain Validation certificates, this means only issuing a certificate for a domain if whoever holds the private key for that certificate also has technical control over that domain (there are other requirements but that's by far the most important one). This can easily be verified through automated means, so a CA automating the issuance of DV certs is no problem. There are other ways a CA can screw up, of course, but none of them is implied by automated issuance.
- 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 ago
    What 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.

ameliaquining 9y ago

Trust to do what? What matters is whether they can be trusted not to misissue certificates. For Domain Validation certificates, this means only issuing a certificate for a domain if whoever holds the private key for that certificate also has technical control over that domain (there are other requirements but that's by far the most important one). This can easily be verified through automated means, so a CA automating the issuance of DV certs is no problem. There are other ways a CA can screw up, of course, but none of them is implied by automated issuance.

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 ago
  What 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.