Can't the replay attack mentioned in the article be mitigated by using nonces? Why doesn't anyone do this? I'm genuinely confused by this.
No, don't enable revocation checking
41–50 of 157 posts
Re: No, don't enable revocation checking
#42Could we use bloom filters on the CRLs, before checking with OCSP? Maybe I should go crunch the numbers on the viability of that.
Adam Langley has some thoughts about how to do this, and some numbers, here:
Re: No, don't enable revocation checking
#43This argument only holds if the attacker controls every internet connection you use. If you're on a portable device or you're otherwise connecting through various networks, only a subset of which are compromised, revocations are still useful.
Re: No, don't enable revocation checking
#44This argument only holds if the attacker controls every internet connection you use. If you're on a portable device or you're otherwise connecting through various networks, only a subset of which are compromised, revocations are still useful.
Exactly. If I'm on my trusted network at home and receive a big revocation list, and a few weeks later go to, say, Egypt, and someone tries to MITM me there with a stolen certificate, then it would show up as invalid.
Re: No, don't enable revocation checking
#45My 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 revocations issue with 24hour valid certificates. Suggested at the end of my post.
But I must be naive on this as it's too simple, just haven't found the flaw in this myself. Yes, it needs technical orchestration, but at least it does not add extra layer of single point of failure for every session.
EDIT: Just finished the OP post and it does indeed also mention "short-lived certificates" in the end as a potential solution.
Re: No, don't enable revocation checking
#46Why 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
I guess that's true when a hard-fail causes the connection to be refused immediately by the client with no user input. In that case a DoS on the OCSP servers breaks things badly.
However what I meant to suggest is a third option. Something like hard-fail with a latch. The client should opt to fail but give the user the choice to proceed.
This would seem more desirable than the current soft-fail implementations when seem to be entirely silent to the end user.
Re: No, don't enable revocation checking
#47Earlier 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?
Most of the energy in this space has gone into http://tack.io/ which has been called "a non-controversial first step" - I believe it is making its way though standards talks at the moment although I have not looked into it for a while. Personally I think now is good time to revisit assumptions made a few years ago - security and privacy and in particular non-government controlled systems are on many peoples lips. If…
For those interested, here’s the latest update from the TACK mailing list: http://slexy.org/view/s20UsKEoRm (January 2014)
Re: No, don't enable revocation checking
#48Just make sure you still check revocation of code signing certificates. Otherwise you will end up running malware that is signed with a legit key they got off my stolen Windows laptop.
Re: No, don't enable revocation checking
#49I'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…
If Namecoin is anywhere near as insecure as Bitcoin, it's a nonstarter. Yes, I know the cryptography underlying Bitcoin is secure, but as a matter of practical fact, Bitcoin itself as an end-user technology is hopelessly insecure. It's one thing having an endless stream of people waking up to find their bitcoins are irrevocably gone because someone hacked the computer, but we can't have domain names being irrevocably lost in the same way.
Does Namecoin actually work like that? If so, is there a similar alternative that doesn't?
Re: No, don't enable revocation checking
#50Earlier quoted context omitted.
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…
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."