3 ms·

That's an amazingly AWESOME answer, thank you. So... what's an example of a CA that the most highest value targets on the internet trust? (like Google, Facebook

by Exuma 9y ago

That's an amazingly AWESOME answer, thank you. So... what's an example of a CA that the most highest value targets on the internet trust? (like Google, Facebook, Amazon, and various banks). Is there like a very trustworthy company that handles most of the big companies?

DCoder 9y ago
You can see overall statistics for CAs at [0] or [1]. Google recently created its own CA for its properties [2]. [0]: https://trends.builtwith.com/ssl/root-authority https://trends.builtwith.com/ssl/root-authority [1]: https://en.wikipedia.org/wiki/Certificate_authority#Providers https://en.wikipedia.org/wiki/Certificate_authority#Provider... [2]: https://pki.google.com/ https://pki.google.com/
toast0 9y ago
There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, you can't get a new cert (hope you had other options); note that CAs don't give much guidance about what to pin. If you pinned a CA that gets delisted, that's no good either. If you pinned two different CAs (a smart choice), but they merge, you no longer have a backup. So, you should pin a public key that you haven't gotten a cert with yet, and keep it safe,but also readily available for emergencies. But you only get one emergency -- hope your next emergency comes after you have time to figure out new pins and get them bundled everywhere; and in the meantime you have one key for everything, which isn't great. (Based only on the name) Expect-CT doesn't provide nearly as much protection, any CA cert will work, but only if it was publicly recorded. If you monitor for certs issued on your domains, at least you know to raise a fuss if a CA you didn't authorize issues on your domains. That's probably enough to keep CAs in line, unless Let's Encrypt drives the net present value of a well distributed CA to below the value of illicit certificates. [1] https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/net/+/master/...
- Exuma 9y ago
  Maybe this is a dumb question... but do larger companies like Google attempt to set up their own CA so they can be sure of the longevity and security, and not rely on a 3rd party?
  - PuffinBlue 9y ago
    Not a dumb question at all and the answer is yes they do set up their own CA's for that exact reason you mentioned. Google's is called Google Trust Services: https://pki.goog/ https://pki.goog/ (Note, Google was already running a sub-ordinate CA which was issued by a third party which is why you might have seen them issue their 'own' certificates previously, but they were actually 'subordinate' to the Root CA that issued them to Google initially). As part of this process of setting up a new trusted Root CA it's necessary to get your trusted Root certificates into all products that may need to use your services. This is a trust system and has to start somewhere, so there is a list of trusted Root CA's and certificates pre-installed in every device. As you can imagine this can take time to do. Sometimes you can cross-sign your Root certificates using another pre-existing trusted CA (I think this is what LetsEncrypt did?) so that all products that trust that third party will now trust your Root CA (well, it's certificate). That could potentially still leave you/devices that don't have your own Root CA's specific Root certificate open to tampering if the CA you got to cross-sign your certificates went rogue. In mitigation of that last point above you could just buy out a pre-existing CA so they couldn't go rogue and make them part of your new Root CA collection, which is what Google/Alphabet did: https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html https://security.googleblog.com/2017/01/the-foundation-of-mo... Even so, as you can see from that post, the process can still be lengthy to reach all products, particularly those that might not be updated with new trusted Root CA's (embedded devices etc) so Google Trust Services still plans (and has now I think?) to cross-sign its certificates with two other third parties it trusts to never go rogue (allowing products which already trust the third parties to now trust Google's new Root CA) in order to let it reach some of those products that don't (and perhaps will never be updated to ever) have it's newly owned Root CA's already installed in them. It's a question of risk management and as you mention, the only way to fully protect yourself is to get everyone to trust you (your CA) as a Root CA, the rest just leaves you open to meddling.

by Exuma 9y ago

DCoder 9y ago

You can see overall statistics for CAs at [0] or [1]. Google recently created its own CA for its properties [2]. [0]: https://trends.builtwith.com/ssl/root-authority https://trends.builtwith.com/ssl/root-authority [1]: https://en.wikipedia.org/wiki/Certificate_authority#Providers https://en.wikipedia.org/wiki/Certificate_authority#Provider... [2]: https://pki.google.com/ https://pki.google.com/

toast0 9y ago

There's a list of pinned CAs at the top of the hsts preload list [1]. Which gives you an idea of who might be trusted. Cert pinning is pretty nasty if you get it wrong. If you don't pin, there's a large number of CAs in most client's default trust stores. If you do pin, and the CA you pinned turns out to be bad, it didn't help. If you pin, but the CA stops issuing from the intermediate or the root that you pinned, you can't get a new cert (hope you had other options); note that CAs don't give much guidance about what to pin. If you pinned a CA that gets delisted, that's no good either. If you pinned two different CAs (a smart choice), but they merge, you no longer have a backup. So, you should pin a public key that you haven't gotten a cert with yet, and keep it safe,but also readily available for emergencies. But you only get one emergency -- hope your next emergency comes after you have time to figure out new pins and get them bundled everywhere; and in the meantime you have one key for everything, which isn't great. (Based only on the name) Expect-CT doesn't provide nearly as much protection, any CA cert will work, but only if it was publicly recorded. If you monitor for certs issued on your domains, at least you know to raise a fuss if a CA you didn't authorize issues on your domains. That's probably enough to keep CAs in line, unless Let's Encrypt drives the net present value of a well distributed CA to below the value of illicit certificates. [1] https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json https://chromium.googlesource.com/chromium/src/net/+/master/...

Exuma 9y ago
Maybe this is a dumb question... but do larger companies like Google attempt to set up their own CA so they can be sure of the longevity and security, and not rely on a 3rd party?
- PuffinBlue 9y ago
  Not a dumb question at all and the answer is yes they do set up their own CA's for that exact reason you mentioned. Google's is called Google Trust Services: https://pki.goog/ https://pki.goog/ (Note, Google was already running a sub-ordinate CA which was issued by a third party which is why you might have seen them issue their 'own' certificates previously, but they were actually 'subordinate' to the Root CA that issued them to Google initially). As part of this process of setting up a new trusted Root CA it's necessary to get your trusted Root certificates into all products that may need to use your services. This is a trust system and has to start somewhere, so there is a list of trusted Root CA's and certificates pre-installed in every device. As you can imagine this can take time to do. Sometimes you can cross-sign your Root certificates using another pre-existing trusted CA (I think this is what LetsEncrypt did?) so that all products that trust that third party will now trust your Root CA (well, it's certificate). That could potentially still leave you/devices that don't have your own Root CA's specific Root certificate open to tampering if the CA you got to cross-sign your certificates went rogue. In mitigation of that last point above you could just buy out a pre-existing CA so they couldn't go rogue and make them part of your new Root CA collection, which is what Google/Alphabet did: https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html https://security.googleblog.com/2017/01/the-foundation-of-mo... Even so, as you can see from that post, the process can still be lengthy to reach all products, particularly those that might not be updated with new trusted Root CA's (embedded devices etc) so Google Trust Services still plans (and has now I think?) to cross-sign its certificates with two other third parties it trusts to never go rogue (allowing products which already trust the third parties to now trust Google's new Root CA) in order to let it reach some of those products that don't (and perhaps will never be updated to ever) have it's newly owned Root CA's already installed in them. It's a question of risk management and as you mention, the only way to fully protect yourself is to get everyone to trust you (your CA) as a Root CA, the rest just leaves you open to meddling.