3 ms·

The problem is partly that you personally aren't using just a widely adopted algorithm, you're using a specific implementation layered on some monster protocol

by shabble 13y ago

The problem is partly that you personally aren't using just a widely adopted algorithm, you're using a specific implementation layered on some monster protocol stack with weird legacy support for "Look the other way and ROT13" mode as well as AES-$Whatever. HTTPS, for example, depends on both crypto algorithm implementation, SSL/TLS, the responsible Certificate Authority[1], your random number generator, your OS, your hardware, and, of course, much the same list for the people at the remote end. The other part of the problem is that, IIRC, the NSA is one of the largest employers of crypto/number-theoretic mathematicians, and from the article, this program with a 35k headcount probably has a bunch of them. Between them, and compute clusters not implausibly denominated in acres, a teeny tiny little flaw might be enough, if they think you deserve the effort. [1] On a tangent, has anyone explored the implications of a "give us some valid certs/signing keys for $whoever and lie to everyone who asks" NSL to one of their domestic CAs? Apart from the EFF SSL-observatory or someone else maybe noticing, of course.

mikegioia 13y ago
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.
- shabble 13y ago
  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 https://www.imperialviolet.org/2011/05/04/pinning.html [2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [3] http://tack.io/ http://tack.io/ [4] https://www.eff.org/observatory https://www.eff.org/observatory (built into HTTPS Everywhere[5] but disabled by default, IIRC) [5] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
- harshreality 13y ago
  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.

by shabble 13y ago

mikegioia 13y ago

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.

shabble 13y ago
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 https://www.imperialviolet.org/2011/05/04/pinning.html [2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [3] http://tack.io/ http://tack.io/ [4] https://www.eff.org/observatory https://www.eff.org/observatory (built into HTTPS Everywhere[5] but disabled by default, IIRC) [5] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
harshreality 13y ago
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.