Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No, don't enable revocation checking

imperialviolet.org

Post reply on HN
Print view View original

61–70 of 157 posts

Re: No, don't enable revocation checking

#61

Post by einhverfr »

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 what is the point of revoking the cert? The author has points but the approach Google ie taking is a cure worse than the disease...

Re: No, don't enable revocation checking

#62

Post by einhverfr »

higherpurpose wrote: post #51
sarahj wrote: post #27

Earlier quoted context omitted.

There is one blockchain. The security of the blockchain requires everyone working very hard to maintain it - while it is made out of many parts it is 1 entity (like an ant colony). Contrast with something like Convergence, where, while they share a common protocol (maybe...not necessarily) each part is responsible for itself, and not tied to any particular larger whole.

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. .

Re: No, don't enable revocation checking

#63

Post by chmars »

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…

Honestly, I don't see a point in certificate revocations anymore, i.e., your implicit conclusion seems to be correct. And I don't blame Google for our broken revocation system – especially because the even the best revocation system couldn't fix the current certification system that is broken in its core.

Re: No, don't enable revocation checking

#65

Post by hereonbusiness »

So this complete infrastructure is crap. OpenSSL, a software half the internet uses but no one cares about because it's crap. CA's not revoking keys even though they know they're compromised. Revocation being worthless because it's too much of a hassle for anyone to bother.

Great. Maybe now, when half the internet is already compromised and all our certificates are not worth the bytes they're made of ... maybe we should try to come up with something better.

edit: Actually, this whole heartbleed affair has been quite eyeopening for me, so I'm thankful for that. But it certainly didn't help with the paranoia I feel the last couple of years while using services on the internet.

Re: No, don't enable revocation checking

#67

Post by sp332 »

psykovsky wrote: post #56
x0x0 wrote: post #25

Earlier quoted context omitted.

answered in adam's blog; see the paragraph beginning with Everyone does soft-fail

That is simply not true. Firefox does hard-fail with the default settings.

I'm sure it doesn't. I just checked Options -> Advanced -> Certificates -> Revocation, and it's not checked by default.

Re: No, don't enable revocation checking

#68

Post by moe »

gojomo wrote: post #7

Still seeing lots of explanation about why the current system sucks, and not much about how a more robust system might be created and promptly adopted. Langley (the author) mentions short-lived certificates (either rapid expiration or via a 'must staple')... how soon can we enforce that? How short can that make the danger-period where the CA, and Google, and the "connected web" all know that a certificate is invalid,…

how a more robust system might be created and promptly adopted

I'm quite fond of how the SSH host key system works.

Prompt me the first time I see a new key, provide me with supporting evidence (e.g. show me how many people have previously accepted this fingerprint for this domain) and alert me the same way in the future if the key ever changes.

If the 'supporting evidence' was plugin-based then this system could quickly become more user-friendly and trustworthy than the current centralised system can ever be.

There could be plugins to automatically trigger a SMS challenge on first contact with particularly sensitive sites. Multiple competing P2P web-of-trust plugins, plugins that let you follow trust-lists from third parties, etc.

In the current system you rely on a single, very questionable opinion on the trustworthiness of a given certificate. In the new system you'd be presented with a trust-score compiled from a whole range of opinions. The sources of which you chose before-hand.

Of course this approach doesn't include a license to print money for corrupt CA organisations and is not going to happen for that reason alone.

Re: No, don't enable revocation checking

#69

Post by dfc »

tptacek wrote: post #33
dvanduzer wrote: post #11

Earlier quoted context omitted.

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

Sure, if "making the DNS totally unreliable", "baking 1990s crypto into the core of the Internet", and "conceding the CA PKI to world governments" is your idea of "better use of CAs".

  > "conceding the CA PKI to world governments" is your idea of "better use of CAs".
How much different is this than the current CA situation? Just recently a subordinate CA of ANSSI (the French Network and Information Security Agency) issued a wildcard cert that could MITM just about anything.[^1] Firefox's list of trusted CAs includes:[^2]

  China Internet Network Information Center (CNNIC)
  Government of France
  Government of Hong Kong (SAR), Hongkong Post
  Government of Japan, Ministry of Internal Affairs and Communications
  Government of Spain, Autoritat de Certificació de la Comunitat Valenciana (ACCV)
  Government of Spain (CAV), Izenpe S.A.
  Government of The Netherlands, PKIoverheid
  Government of Taiwan, Government Root Certification Authority (GRCA)
  Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)    
  Hong Kong
Firefox's list of pending CAs includes additional government CAs.[^3] Things are no different in Redmond. There are at least 56 government CAs (56 of the certs start with government probably others with less obvious names) in Microsoft's Root Certificate Program.[^4]

[^1]: https://blog.mozilla.org/security/2013/12/09/revoking-trust-...

[^2]: https://www.mozilla.org/en-US/about/governance/policies/secu...

[^3]: https://www.mozilla.org/en-US/about/governance/policies/secu...

[^4]: https://social.technet.microsoft.com/wiki/contents/articles/...

Re: No, don't enable revocation checking

#70

Post by e12e »

dvanduzer wrote: post #11
e12e wrote: post #8

I think the author is a little disingenuous with the term "security theatre". Basically he argues that OCSP doesn't work because hard fail might cause DOS -- but fails to conclude that without OCSP SSL/TLS is useless . It's a long argument for saying that the CA system is broken (you can only trust the white-list chrome provides) -- and the sensible conclusion is that you cannot trust any other certificate chains (wi…

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 implemented, and when DNS resolvers implement checking -- many ISPs don't. Delegating CAs are already part of SSL/TLS.

DNSSEC requires fidling with the DNS information -- delegating CAs, while requiring issuing certs, only require configuration of the various services (web, imap, smtp etc) -- as per usual.

For delegating CAs to improve the security of any given domain -- some infrastructure would be needed to set up an intermediate CA. I guess for small organizations, OCSP wouldn't really be needed, as the CRLs would be small (assuming different CA for public facing services and stuff like personal certs for users). Another option would be to simply roll certificates frequently.

Post reply on HN