No, don't enable revocation checking

Post by richardwhiuk » Sun, Apr 20, 2014, 2:37 PM UTC

einhverfr wrote: post #61

wpietri wrote: post #2

For those, like me, wondering who the author might be, it appears to be this guy: "Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world - See more at: http:/…

On the other hand we found that as of Friday, Chrome DID NOT recognize that one of our wildcard certs for Efficito had been revoked. We sent out an email to our customers saying to enable cert revocation checking. Revovation isn't perfect and I would not suggest the current status quo is OK but the intermediary approach Chrome takes cannot be trusted as they have now shown. If Chome will not show our cert as revoked…

Post by vertex-four » Sun, Apr 20, 2014, 2:52 PM UTC

einhverfr wrote: post #62

higherpurpose wrote: post #51

Earlier quoted context omitted.

And do you think that makes it inherently less secure than a "free-for-all" system? I think the point of the blockchain is to remove trust and become trustless, while the point of something like this is to keep the trust system, but actually give you some choice of who you trust. It seems a little better, but I think trustless authentication (as in no 3rd party required) would be preferred.

Trustless is great for so many things but try answering this question in a trustless environment: "Before I give you my credit card info, how do I know you are who you say you are?" If you can answer that without trust. .

Post by tptacek » Sun, Apr 20, 2014, 3:08 PM UTC

y0ghur7_xxx wrote: post #55

tptacek wrote: post #34

Earlier quoted context omitted.

First, "TOFU/POP" has a real name; it's "key continuity". Second, certificate pinning as implemented in Chrome doesn't depend directly on key continuity. Third, key continuity destroys the incentive to attack sites by compromising CAs, because even if you're hitting a site for the first time, many of the 10,000 other people hitting it from the same browser at around the same time aren't, and they'll detect the bogus…

> certificate pinning as implemented in Chrome doesn't depend directly on key continuity. But it's unsuitable for the entirety of the web. You can't hardcode all certificate fingerprints of the whole internet inside the browser. >> The migration away from the CA model is called "certificate pinning". > key continuity destroys the incentive to attack sites by compromising CAs We need to ELIMINATE CAs (CA as in some th…

Post by jackalope » Sun, Apr 20, 2014, 3:18 PM UTC

e12e wrote: post #70

dvanduzer wrote: post #11

Earlier quoted context omitted.

The "better use of CAs" you describe is essentially DNSSEC.

No, not really. DNSSEC secures DNS, allowing it to be used (among other things) as a secure transport for delivering other certificates. CAs already provide the same trust infrastructure, but due to incentives do not sign delegating certs by default, but typically charge extra for certs that allow the owner of a domain to set up their own internal CA. DNSSEC only works (reasonably) for TLDs where DNSSEC is implemente…

Post by wpietri » Sun, Apr 20, 2014, 3:42 PM UTC

tptacek wrote: post #31

wpietri wrote: post #2

For those, like me, wondering who the author might be, it appears to be this guy: "Adam Langley works on both Google’s HTTPS serving infrastructure and Google Chrome’s network stack. From the point of view of a browser, Langley has seen many HTTPS sites getting it dreadfully wrong and, from the point of view of a server, he’s part of what is probably the largest HTTPS serving system in the world - See more at: http:/…

He's also the author of Golang's native crypto/tls TLS stack, a longtime contributor to the IETF TLS WG, and the author of some of OpenSSL's curve software. He's not messing around.