Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If CAs gave up valid certs/signing keys for google.com, would the fingerprint be different? And if so, would it be possible to verify the fingerprint if Google hosted it at like pki.google.com?

I've been wondering if there's a public registry of certificate fingerprints somewhere to verify you're getting the cert the domain owner knows about.



Having thought about it a little bit more, I remember there are actually a few things being done about it.

Certificate Pinning[1] (bundle your cert with Chrome/$browser)

HSTS[2] (cache the cert you receive on this connection for $num days, bitch vocally if it changes)

Convergence (Dead?) / TACK[3] (add an independent site-specific key to cross-sign the CA-provided certs, like pinning but more flexible)

And the more passive detection approach I mentioned like the SSL Observatory[4] which looks for "unexpected" changes in certs.

To finally answer your question, no, I don't think there is any sort of list. Doing essentially that without any centralised bookkeeping (I mean, why trust those guys any more than the CAs? Not to mention it'd be hard to scale) is the plan.

DNSSec might have some sort of role in there, but I'm sufficiently hazy on how it works, and you're back to trusting your registrars/registries again anyway (see recent excitement at the NYTimes for why that's not such a great idea)

[1] https://www.imperialviolet.org/2011/05/04/pinning.html

[2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

[3] http://tack.io/

[4] https://www.eff.org/observatory (built into HTTPS Everywhere[5] but disabled by default, IIRC)

[5] https://www.eff.org/https-everywhere


They could then generate a new key for site.com, trusted by browsers that don't support cert pinning, but yes, that new key for site.com would have a different fingerprint. The only way to keep the same cert fingerprint is to get site.com's cert's private key, either by demanding it with a NSL or FISA order, or by breaking RSA (2048bit, in most cases) if the site uses RSA as almost all of them do.

Generating a new cert from a trusted CA would be caught by EFF's SSL observatory (an optional feature in the HTTPS everywhere extension) and similar efforts.

It would fail if used against a site that has its certificate's CA pinned in the browser, unless the NSA gets the CA private key for the right CA.

Therefore, if they do have CA root key(s), they wouldn't MITM all the ssl connections they can. They would use that capability sparingly.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: