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

51–60 of 157 posts

Re: No, don't enable revocation checking

#51

Post by higherpurpose »

sarahj wrote: post #27
wyager wrote: post #19

Earlier quoted context omitted.

> Why have a single entity at all? How do you figure that Namecoin is a "single entity"?

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.

Re: No, don't enable revocation checking

#52

Post by ivanr »

AhtiK wrote: post #45

My quick write-up on this from few days ago, http://www.ahtik.com/blog/startssl-revocation-fees-will-not-... Yes, revoke is broken by design, especially with mobile and Chrome browser. I'd say it's broken everywhere except Firefox with OCSP Hard Fail enabled. Thanks to this flaw StartSSL business model has become somewhat outdated IMHO with the free certs and paid revocations. I'm dreaming that we can fix the revocat…

Indeed, short-lived certificates do seem like a solution to this problem. One downside might be the fact that (anecdotally) many users have inaccurate clocks. I read somewhere recently that a large web site has to back-date their new certificates, because, otherwise, certificate rotation/revocation causes a large spike in support tickets.

Short-lived certificates were explored in Towards Short-Lived Certificates http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-shortliv...

Re: No, don't enable revocation checking

#53

Post by ivanr »

higherpurpose wrote: post #50
vxNsr wrote: post #36

Earlier quoted context omitted.

The project seems to have lost support, the last github commit was over 2 years ago. Do you know if there was a specific reason or were people just not interested/none of the browsers jumped onboard?

From Moxie: "Convergence is blocking on TACK, which is blocking on browser vendors." https://twitter.com/moxie/status/451020203099299840

There should be a clear statement about the status of Convergence on the web site. IIRC, the Firefox extension has been broken for more than a year now. Why? If Mozilla broke their APIs and made it impossible for the extension to work, then we should know about that. Otherwise, what's the excuse for the extension being broken for so long?

Convergence had the momentum, and there was a small but vocal group of people willing to support it. But, due to project mismanagement and lack of communication, that momentum has been lost.

Re: No, don't enable revocation checking

#54

Post by SixSigma »

sarahj wrote: post #13
wyager wrote: post #4

I'm honestly kind of surprised how little action there has been to assist with a migration away from the CA model. The technology is there, but people just don't seem interested enough to leverage it. Systems like Namecoin could serve this purpose marvelously. Powerful devices have direct access to the entire cryptographically authenticated DNS and certificate database. Weak devices can specify whom they trust to pro…

Why have a single entity at all? Moxie Marlinspike proposed Convergence ( https://www.youtube.com/watch?v=Z7Wl2FW2TcA ) as a solution - I think that something like that has far more potential wheels to travel than a Namecoin based system. I should be able to choose who I trust, a notary system would allow me to do just that. No central CA systems. The biggest concern I can see is Identity management, but, as mentione…

But I trust your rabbit and it can happily take as many of my dandelions as it wants.

Re: No, don't enable revocation checking

#55

Post by y0ghur7_xxx »

tptacek wrote: post #34
wyager wrote: post #18

Earlier quoted context omitted.

>The migration away from the CA model is called "certificate pinning". TOFU/POP is not an effective model for the web. There are simply too many sites for it to be useful. It's pretty much an everyday occurrence that I go to a site I've never been to before, and certificate pinning won't help at all there.

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 third party (google, Verysign, GoDaddy, ...) who you have to trust). The whole concept of trusting a CA is broken, and pinning does nothing to address that, at least not in the proposed TACK implementation.

Re: No, don't enable revocation checking

#56

Post by psykovsky »

x0x0 wrote: post #25
dwightgunning wrote: post #21

Why not hard-fail by default and give the user the option to ignore/override it? Similar to the way other certificate warnings are shown to the end-user.

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.

Re: No, don't enable revocation checking

#57

Post by 0x006A »

ivanr wrote: post #53
higherpurpose wrote: post #50

Earlier quoted context omitted.

From Moxie: "Convergence is blocking on TACK, which is blocking on browser vendors." https://twitter.com/moxie/status/451020203099299840

There should be a clear statement about the status of Convergence on the web site. IIRC, the Firefox extension has been broken for more than a year now. Why? If Mozilla broke their APIs and made it impossible for the extension to work, then we should know about that. Otherwise, what's the excuse for the extension being broken for so long? Convergence had the momentum, and there was a small but vocal group of people w…

There are some more active forks like https://github.com/mk-fg/convergence/ but they too seam to not really work in current versions of Firefox.

Re: No, don't enable revocation checking

#58

Post by y0ghur7_xxx »

higherpurpose wrote: post #50
vxNsr wrote: post #36

Earlier quoted context omitted.

The project seems to have lost support, the last github commit was over 2 years ago. Do you know if there was a specific reason or were people just not interested/none of the browsers jumped onboard?

From Moxie: "Convergence is blocking on TACK, which is blocking on browser vendors." https://twitter.com/moxie/status/451020203099299840

I don't understand this. Can someone weight in with an explanation? Convergence works just fine without TACK: I can set up two or more notaries on some VPS somewhere, and my browser would check if the notaries see the same certificate on that server I am trying to connect to as my browser. Seems secure to me: no external CA involved, the certificate on the web server can be self signed, and a MITM attack would need to hack two or more external servers to be successful. How does TACK fit in all of this?

Re: No, don't enable revocation checking

#59

Post by mobiplayer »

I've wondered many times why OCSP isn't distributed as DNS is. When we talk about websites, surely there's no more than one certificate per hostname (or less, i.e. wildcards). I don't think we're talking here of something impossible to do or not feasible with our current technology and computing power.

Also, certificate "whitelisting" could be a part of the DNS protocol itself (return the IP address of the requested hostname and the hash of its current, valid certificate).

Re: No, don't enable revocation checking

#60

Post by mobiplayer »

mobiplayer wrote: post #59

I've wondered many times why OCSP isn't distributed as DNS is. When we talk about websites, surely there's no more than one certificate per hostname (or less, i.e. wildcards). I don't think we're talking here of something impossible to do or not feasible with our current technology and computing power. Also, certificate "whitelisting" could be a part of the DNS protocol itself (return the IP address of the requested…

Just to clarify: OCSP is distributed, but I can't ask my local ISP OCSP server about your certificates. I have to ask your OCSP server about your certificates.
Post reply on HN