4 ms·

> I wish browser vendors would let me choose a trusted entity and make it simple for me to trust only CAs that my trusted entity supports, or the intersection o

by hannob 9y ago

> I wish browser vendors would let me choose a trusted entity and make it simple for me to trust only CAs that my trusted entity supports, or the intersection of what multiple trusted entities endorse. This is an idea that I hear in variations from time to time, yet I think it's utterly wrong and goes against everything we know about IT security UI. The reason why HTTPS works at scale and is - with all its weaknesses - a crypto success story is because it works automatically. Unlike other things like PGP that ultimately expect from the user to get an understanding of complex concepts like public key cryptography and web of trusts. What you're trying to do is move HTTPS away from "it just works" to "user has to understand what a CA and a PKI is". Fortunately none of the relevant actors or browser vendors is moving in that direction, the opposite is happening. HTTPS is becoming the default, it works automatically and the security improvements that are being deployed (mainly CT) are systemic improvements to strengthen the whole system.

ykler 9y ago
I certainly agree that something that just works is by far the most important priority and do worry about anything that could muddy that message. On the other hand, I suppose what the parent proposes could be useful for users with heightened security concerns even if they are only a tiny minority, similarly to how tor is useful (and, in fact, using this setting would be less conspicuous than using tor and also less suspicious since there is no way of using it for criminal activity).
mehrdadn 9y ago
Not really. To be honest, the existing UX for trust relationships is hardly near optimal. Nobody needs to understand what CAs and PKIs are. I actually think the proper UI could make it pretty smooth and understandable by the layperson. All a user needs to be asked is "Whom would you trust to certify that the websites you visit are genuinely those they claim to be?" and be presented with a few reasonable options, such as perhaps (1) Default (recommended), (2) Certification companies (Verisign, Thawte, etc.), (3) Government agencies (e.g. CIA, NSA, etc.), (4) Other/Custom (advanced).
- icebraining 9y ago
  I think that implies there's a choice, that when you access, say, ycombinator.com, you can choose to have that site certified by one or many agencies. In reality that choice only exists for the site owner, so if you choose a subset of CAs, you'll just have HTTPS errors on a bunch of sites. If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really. [1] https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)
  - mehrdadn 9y ago
    (Edit: I edited this example here to make it even simpler.) Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that the certificate is what they expect (so that we know it's not a MITM), whose public key they have already hopefully known about and pinned. Note: I just came up with these ideas on the spot. I believe they're much better than the current system but in no way am I suggesting they have no room for further improvement.
    - hannob 9y ago
      Have you ever seen this picture? https://www.reddit.com/r/funny/comments/42xxdh/what_computer_users_see_in_security_warning_boxes/ https://www.reddit.com/r/funny/comments/42xxdh/what_computer... Because that's exactly what you're proposing.
      - mehrdadn 9y ago
        Not that particular one, though I have seen similar, but no, that is not what I was proposing. Where is the "technical crap" in what I just suggested? Which part of it was hard to understand or make a decision on?
iliketosleep 9y ago
The parent is not suggesting a deviation from the "it just works" model. They are suggesting a convenient way for expert or "paranoid" users to be able to make changes to whom they trust as they see fit - this does not affect average users at all, but may provide significant benefits to an important minority of users.
- likelynew 9y ago
  We can add or remove root certificates for OS, it's just deliberately not easy.
  - chaz6 9y ago
    This makes me think that the package containing the trusted certificate list ought to be separated into a standalone repository, so that it is easy to change (like how you subscribe to an adblock list).
  - bryanrasmussen 9y ago
    the implication being that if you don't find it easy enough to do it, then you probably aren't expert enough that you should be doing it.
  - snakeanus 9y ago
    > it's just deliberately not easy And thus crippled and useless against state attackers. I fail to see the reason why my browser refuses to let me "pin" a CA only for certain sites for example.
bugmen0t 9y ago
I agree with Hanno here. There are great tools to make the CAs behave or at least make their mistakes being easily spotted: Name Constraints, DNS CAA records, Certificate Transparency and, if you must, HPKP and much more.
grandalf 9y ago
> crypto success story Suppose 5% of CAs are compromised. Is that a success? It is if you compare it to everyone using self-signed certs, but it is not if you consider that there are likely broad vulnerabilities that can be silently exploited by some groups/nations. We don't hear much about man in the middle attacks because we have no reason to be aware of them. > it just works The point of my remark is not to suggest that a list of trusted CAs compiled by someone like Bruce Schneier would result in a broken web. If it would, then it's hard to argue that the system is not already broken. The point is to allow experts to establish authority on the basis of careful (possibly paranoid) stewardship of a list of trusted CAs. Then when an attack is revealed experts who whitelisted that CA lose a bit of credibility, and those who blacklisted it gain some. As it stands, firms that ship a default list of trusted CAs have an incentive to err on the side of whitelisting, and then claiming "oops we had no idea that CA x was compromised..." There are clues about the relative trustworthiness of CAs, some of which are simply the governments that have jurisdiction to demand private keys, etc.

by hannob 9y ago

ykler 9y ago

I certainly agree that something that just works is by far the most important priority and do worry about anything that could muddy that message. On the other hand, I suppose what the parent proposes could be useful for users with heightened security concerns even if they are only a tiny minority, similarly to how tor is useful (and, in fact, using this setting would be less conspicuous than using tor and also less suspicious since there is no way of using it for criminal activity).

mehrdadn 9y ago

Not really. To be honest, the existing UX for trust relationships is hardly near optimal. Nobody needs to understand what CAs and PKIs are. I actually think the proper UI could make it pretty smooth and understandable by the layperson. All a user needs to be asked is "Whom would you trust to certify that the websites you visit are genuinely those they claim to be?" and be presented with a few reasonable options, such as perhaps (1) Default (recommended), (2) Certification companies (Verisign, Thawte, etc.), (3) Government agencies (e.g. CIA, NSA, etc.), (4) Other/Custom (advanced).

icebraining 9y ago
I think that implies there's a choice, that when you access, say, ycombinator.com, you can choose to have that site certified by one or many agencies. In reality that choice only exists for the site owner, so if you choose a subset of CAs, you'll just have HTTPS errors on a bunch of sites. If Convergence[1] ever becomes a thing, then I think your proposal makes sense, otherwise not really. [1] https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)
- mehrdadn 9y ago
  (Edit: I edited this example here to make it even simpler.) Again -- HTTPS errors are not exactly the epitome of the best UX. You could pop up a dialog saying "We can't seem to verify this site is really x.com. It might be someone else impersonating x.com. What would you like to do? [Ask Google/Microsoft] [Continue] [Cancel]" or something like that. And asking Google/Microsoft would be implemented by checking that the certificate is what they expect (so that we know it's not a MITM), whose public key they have already hopefully known about and pinned. Note: I just came up with these ideas on the spot. I believe they're much better than the current system but in no way am I suggesting they have no room for further improvement.
  - hannob 9y ago
    Have you ever seen this picture? https://www.reddit.com/r/funny/comments/42xxdh/what_computer_users_see_in_security_warning_boxes/ https://www.reddit.com/r/funny/comments/42xxdh/what_computer... Because that's exactly what you're proposing.
    - mehrdadn 9y ago
      Not that particular one, though I have seen similar, but no, that is not what I was proposing. Where is the "technical crap" in what I just suggested? Which part of it was hard to understand or make a decision on?

iliketosleep 9y ago

The parent is not suggesting a deviation from the "it just works" model. They are suggesting a convenient way for expert or "paranoid" users to be able to make changes to whom they trust as they see fit - this does not affect average users at all, but may provide significant benefits to an important minority of users.

likelynew 9y ago
We can add or remove root certificates for OS, it's just deliberately not easy.
- chaz6 9y ago
  This makes me think that the package containing the trusted certificate list ought to be separated into a standalone repository, so that it is easy to change (like how you subscribe to an adblock list).
- bryanrasmussen 9y ago
  the implication being that if you don't find it easy enough to do it, then you probably aren't expert enough that you should be doing it.
- snakeanus 9y ago
  > it's just deliberately not easy And thus crippled and useless against state attackers. I fail to see the reason why my browser refuses to let me "pin" a CA only for certain sites for example.

bugmen0t 9y ago

I agree with Hanno here. There are great tools to make the CAs behave or at least make their mistakes being easily spotted: Name Constraints, DNS CAA records, Certificate Transparency and, if you must, HPKP and much more.

grandalf 9y ago

> crypto success story Suppose 5% of CAs are compromised. Is that a success? It is if you compare it to everyone using self-signed certs, but it is not if you consider that there are likely broad vulnerabilities that can be silently exploited by some groups/nations. We don't hear much about man in the middle attacks because we have no reason to be aware of them. > it just works The point of my remark is not to suggest that a list of trusted CAs compiled by someone like Bruce Schneier would result in a broken web. If it would, then it's hard to argue that the system is not already broken. The point is to allow experts to establish authority on the basis of careful (possibly paranoid) stewardship of a list of trusted CAs. Then when an attack is revealed experts who whitelisted that CA lose a bit of credibility, and those who blacklisted it gain some. As it stands, firms that ship a default list of trusted CAs have an incentive to err on the side of whitelisting, and then claiming "oops we had no idea that CA x was compromised..." There are clues about the relative trustworthiness of CAs, some of which are simply the governments that have jurisdiction to demand private keys, etc.