3 ms·

How come it's just one CA that is needed to ensure the trust of a domain, especially one as important as *.google.com? It seems like it's only a matter of time

How come it's just one CA that is needed to ensure the trust of a domain, especially one as important as *.google.com? It seems like it's only a matter of time before something like this happens again.

deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
InclinedPlane 15y ago
The idea is that all CA's are effectively fully trustworthy. The public keys for the CA's certs are loaded into browsers. When a specific SSL cert is created the private key is generated by the buyer (and never revealed) then the public key for that is sent to the CA and signed. In this way a link of trust is created between the CA and whoever bought the SSL cert. Now, when a browser is used to go to a website using SSL it will ask that site for its cert, which contains the public key and the digital signature from the CA. If the cert is signed by a CA that the browser trusts then the browser in turn trusts that specific cert. The browser then uses the public key to encrypt a message to the site containing information for encrypting return transmissions to the browser. The point being, all CA's are on an equal playing field, and fully trusted. The moment any one CA is no longer fully trustworthy or the moment its private key is no longer secure the whole system fails.
- deleted 15y ago
  [deleted]
- tonfa 15y ago
  The said chrome will only accept one particular CA when verifying the signature for google.com (which is one of the reason the fraudulent cert was detected).
  - waitwhat 15y ago
    This should be a feature they offer to all of the Alexa top 100 websites.
    - tonfa 15y ago
      Given the last comment here, I think they would accept it: http://www.imperialviolet.org/2011/05/04/pinning.html http://www.imperialviolet.org/2011/05/04/pinning.html
tptacek 15y ago
The worst breakage in the HTTPS/TLS security model is the fact that every CA is a full peer to ever other CA and can sign anything. Combine that with the fact that CA's are allowed to have resellers and the whole thing breaks down predictably. It doesn't have to be that way. SSL/TLS libraries, for the most part, only verify that the certificate chain is properly signed all the way to the root. That doesn't mean the browser trust system is limited to that! After certificates are verified, it should be straightforward to apply additional policies, such as "Colin Percival does not trust certificates from this CA with the exception of these three domains which unfortunately rely on it, but Colin and all his friends are also helpfully monitoring the fingerprints of the known good certs for those domains". You don't need permission from the IETF, IANA, Mozilla, or Verisign to build this. You just have to build it and get people to use it. Moxie Marlinspike is working on an idea similar to this at CONVERGENCE.IO.

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

InclinedPlane 15y ago

The idea is that all CA's are effectively fully trustworthy. The public keys for the CA's certs are loaded into browsers. When a specific SSL cert is created the private key is generated by the buyer (and never revealed) then the public key for that is sent to the CA and signed. In this way a link of trust is created between the CA and whoever bought the SSL cert. Now, when a browser is used to go to a website using SSL it will ask that site for its cert, which contains the public key and the digital signature from the CA. If the cert is signed by a CA that the browser trusts then the browser in turn trusts that specific cert. The browser then uses the public key to encrypt a message to the site containing information for encrypting return transmissions to the browser. The point being, all CA's are on an equal playing field, and fully trusted. The moment any one CA is no longer fully trustworthy or the moment its private key is no longer secure the whole system fails.

deleted 15y ago
[deleted]
tonfa 15y ago
The said chrome will only accept one particular CA when verifying the signature for google.com (which is one of the reason the fraudulent cert was detected).
- waitwhat 15y ago
  This should be a feature they offer to all of the Alexa top 100 websites.
  - tonfa 15y ago
    Given the last comment here, I think they would accept it: http://www.imperialviolet.org/2011/05/04/pinning.html http://www.imperialviolet.org/2011/05/04/pinning.html

tptacek 15y ago

The worst breakage in the HTTPS/TLS security model is the fact that every CA is a full peer to ever other CA and can sign anything. Combine that with the fact that CA's are allowed to have resellers and the whole thing breaks down predictably. It doesn't have to be that way. SSL/TLS libraries, for the most part, only verify that the certificate chain is properly signed all the way to the root. That doesn't mean the browser trust system is limited to that! After certificates are verified, it should be straightforward to apply additional policies, such as "Colin Percival does not trust certificates from this CA with the exception of these three domains which unfortunately rely on it, but Colin and all his friends are also helpfully monitoring the fingerprints of the known good certs for those domains". You don't need permission from the IETF, IANA, Mozilla, or Verisign to build this. You just have to build it and get people to use it. Moxie Marlinspike is working on an idea similar to this at CONVERGENCE.IO.