3 ms·

> Online revocation is pointless. So is getting a subset of revoked certs Google deems "valuable." In fact, that may be even more dangerous since it establish

> Online revocation is pointless. So is getting a subset of revoked certs Google deems "valuable." In fact, that may be even more dangerous since it establishes first class secure sites vs everyone else. Why should Yahoo's cert revocatins get in the CRLsets but not less well known sites? How is that less broken than online revocation? Keep in mind, my big objection is: Google did not distribute our certificate vocation in their CRLSet, presumably because we weren't large enough. That is not a fix for anything.

tptacek 13y ago
This comment isn't responsive to mine.
- einhverfr 13y ago
  Ok, fair enough. I am just making sure my objection to Google's approach is clear. I would be OK if they guaranteed complete CRLsets from all participating CA's. Since they don't, their solution is more broken than what they are replacing. So I acknowledge that online revocation is problematic. I just think the crlset approach is an order of magnitude worse when the crlset is a subset of revoked entries sent by the ca.
  - tptacek 13y ago
    Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.
    - nomailing 13y ago
      hard revocation is not at all broken! The article is bullshit.
      - tptacek 13y ago
        By all means, totally anonymous Hacker News one-line comment writer, tell us why Adam Langley is full of shit about certificate revocation.
    - gojomo 13y ago
      The implied-preference-set shouldn't be restricted to the false binary choice of "the broken standardized system" and "Google's half-fixed proprietary approach". With the talent & resources that Google has, or the talent & resources that Mozilla has, or the talent & resources that Microsoft has, this should have been better solved, in a way that works for all TLS-reliant applications, years ago. Using Chrome's built-in auto-updates to make a subset of "high-value revocations" work, at a daily frequency, for Chrome users only, is not a very web-friendly solution. It's like a gated community hiring its own rent-a-cops... maybe that's an improvement for the fortunate ones on the inside, and maybe a necessary stopgap. But to people outside that perimeter – like someone whose revocation doesn't make it into the Google CRLSet – it feels like an abdication of duty by the web's stewards.
      - enneff 13y ago
        Christ, this kind of reactionary armchair criticism really is a cancer of HN these days. Adam has been pushing the state of the art in cryptography in the practical realm for years, and your criticism is "They should have just solved this problem better! They should just pull their finger out and get working on it." Making a real difference in the chaotic realm of standards bodies and browser vendors is a lot harder than it looks. Adam has an impressive track record for actually improving internet security for users. Where's your suggestion for how revocation could be solved better and implemented in a practical way? I don't see you rolling up your sleeves to get the actual work done.
        dang 13y ago
        > armchair criticism [...] is a cancer of HN Yes. It has been for a long time. Long term, we want to figure out ways to improve thread quality. Not so much in terms of the toxicity problem, which has seen some progress lately (we hope), but the arguably harder problem of voluminous uninformed commentary clustering around the mean. If you (or anyone) have any suggestions, I'd love to hear them. hn@ycombinator.com is the best place to send them. (This is not about any particular comments in the current thread, only the problem in general.)
        gojomo 13y ago
    - einhverfr 13y ago
      If Amazon, Yahoo, and the small SaaS provider are in the same boat security-wise, then you have the incentive to get the root problems fixed. Google's approach takes away that incentive from the large providers. I don't think it is just a question of pretending. It is a question of making sure that everyone is in the same boat security-wise so that the root problems in fact get addressed. What Google does is make Amazon more secure and the small SaaS provider less so. And it makes sure that the big providers have less incentive to fix the underlying concerns.
      - tptacek 13y ago
        The Chromium team didn't choose how big to make the lifeboat. They have the one they have. If they've got to choose between putting Amazon in it or you, then, as a user, I'm glad they chose rationally.
        gojomo 13y ago
        It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).
        tptacek 13y ago
        Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.
        gojomo 13y ago
        Then correct me, don't insult me. Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates? All I know about it, I read from Langley's writings. Is there a better reference? Who set the implemntation limits, if not Google? Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.

tptacek 13y ago

This comment isn't responsive to mine.

einhverfr 13y ago
Ok, fair enough. I am just making sure my objection to Google's approach is clear. I would be OK if they guaranteed complete CRLsets from all participating CA's. Since they don't, their solution is more broken than what they are replacing. So I acknowledge that online revocation is problematic. I just think the crlset approach is an order of magnitude worse when the crlset is a subset of revoked entries sent by the ca.
- tptacek 13y ago
  Respectfully, I think an accurate summary of your argument is that you would rather pretend to be secure using broken online revocation checks than to have to stomach the Chromium team providing a marginal amount of actual security by deciding which sites are and aren't worthy of protection.
  - nomailing 13y ago
    hard revocation is not at all broken! The article is bullshit.
    - tptacek 13y ago
      By all means, totally anonymous Hacker News one-line comment writer, tell us why Adam Langley is full of shit about certificate revocation.
  - gojomo 13y ago
    The implied-preference-set shouldn't be restricted to the false binary choice of "the broken standardized system" and "Google's half-fixed proprietary approach". With the talent & resources that Google has, or the talent & resources that Mozilla has, or the talent & resources that Microsoft has, this should have been better solved, in a way that works for all TLS-reliant applications, years ago. Using Chrome's built-in auto-updates to make a subset of "high-value revocations" work, at a daily frequency, for Chrome users only, is not a very web-friendly solution. It's like a gated community hiring its own rent-a-cops... maybe that's an improvement for the fortunate ones on the inside, and maybe a necessary stopgap. But to people outside that perimeter – like someone whose revocation doesn't make it into the Google CRLSet – it feels like an abdication of duty by the web's stewards.
    - enneff 13y ago
      Christ, this kind of reactionary armchair criticism really is a cancer of HN these days. Adam has been pushing the state of the art in cryptography in the practical realm for years, and your criticism is "They should have just solved this problem better! They should just pull their finger out and get working on it." Making a real difference in the chaotic realm of standards bodies and browser vendors is a lot harder than it looks. Adam has an impressive track record for actually improving internet security for users. Where's your suggestion for how revocation could be solved better and implemented in a practical way? I don't see you rolling up your sleeves to get the actual work done.
      - dang 13y ago
        > armchair criticism [...] is a cancer of HN Yes. It has been for a long time. Long term, we want to figure out ways to improve thread quality. Not so much in terms of the toxicity problem, which has seen some progress lately (we hope), but the arguably harder problem of voluminous uninformed commentary clustering around the mean. If you (or anyone) have any suggestions, I'd love to hear them. hn@ycombinator.com is the best place to send them. (This is not about any particular comments in the current thread, only the problem in general.)
      - gojomo 13y ago
  - einhverfr 13y ago
    If Amazon, Yahoo, and the small SaaS provider are in the same boat security-wise, then you have the incentive to get the root problems fixed. Google's approach takes away that incentive from the large providers. I don't think it is just a question of pretending. It is a question of making sure that everyone is in the same boat security-wise so that the root problems in fact get addressed. What Google does is make Amazon more secure and the small SaaS provider less so. And it makes sure that the big providers have less incentive to fix the underlying concerns.
    - tptacek 13y ago
      The Chromium team didn't choose how big to make the lifeboat. They have the one they have. If they've got to choose between putting Amazon in it or you, then, as a user, I'm glad they chose rationally.
      - gojomo 13y ago
        It looks to me like the Chromium team did choose the size of the lifeboat: it's a Google-designed feature (CRLSet) based on another Google-designed feature (auto updates).
        tptacek 13y ago
        Then you simply don't understand what the CRLset revocation system is, or why it works the way it does.
        gojomo 13y ago
        Then correct me, don't insult me. Isn't CRLSet a Google invention? Doesn't it depend on Chrome software updates? All I know about it, I read from Langley's writings. Is there a better reference? Who set the implemntation limits, if not Google? Maybe those limits are justifiable, but that doesn't leave someone who's left unprotected, by what seem like arbitrary policy cutoffs, feeling any better.