Comment by thatcks | Hacker News Reader

Comment by thatcks | Hacker News Reader

Parent Full thread

I disagree. A CA's actual product (what you pay money for) is some magic bits that put a padlock in the browser URL bar or, alternately, allow you to do HTTPS with browsers without your visitors getting scary warnings from the browser (and attackers being able to MITM your visitors). Since it is extremely rare that CA's are de-trusted by browsers, especially on short notice, any CA that can create this good today is basically as good as any other CA. 'Trust' doesn't come into it as such, and to the extent that you must trust your CA, you cannot feasibly verify that it actually is trustworthy and will remain trustworthy, and thus that certificates it has signed for you will remain trusted by browsers for their duration.

(DigiNotar was trustworthy right up until people discovered that it had been compromised. StartComm actively hid that it had been bought by WoSign; it took people some digging to turn this up and verify it. Other CAs have routinely denied that they had problems when they did.)

Even if you could, picking an especially trustworthy CA doesn't add any extra security for your website, because you are actually dependent on the security of all of the CAs out there, any of which can in theory mis-issue a TLS certificate for your site. Sure, there's CAA records, but this only helps if the CA actually follows the rules properly; CAs can fail here at both a technical and a business level. (One CA recently proposed that it should be allowed to ignore CAA records if the domain owner told it to.)

Even attempting to do basic checking of a CA probably doesn't make sense at a business level unless you're buying certificates in bulk. Suppose that you're buying four TLS certificates and the best price you can get is $30 per certificate per year, or $120 in total for a year. How much engineer time does it make sense to spend in order to pick the most 'trustworthy' CA (ie one that is likely to remain trusted by browsers for a year), given that CA de-trusting is an extremely rare event and if it happens, you're only out another $120 to buy certificates from the next CA?

(I'm the author of the linked-to entry and as you can tell, I have opinions on CAs and the TLS ecosystem. One of them is that Certificate Transparency is a really big deal because it removes a lot of the 'trust me' from the whole CA ecosystem.)

I'm not sure if you intended to or not, but you've perfectly proven my point. DigiNotar and StartComm were both forced out of business because people couldn't trust them.

I can generate a set of magic bits on my own computer without any input from a CA, and I'll be able to use them to encrypt a TLS session. What I can't generate on my computer is some trust, which is what I get when I buy a cert from a CA. Also, as a customer of CAs, I have a selection of different companies to choose from, and I base that selection mostly on trustworthiness. It's not so difficult for me to determine which CAs have had the least number of trust-undermining incidents.

To your point of likelihood around CAs being de-trusted, something that happens even less often (as fas as I'm aware), is relying parties claiming on the relying part warranty, so I don't think appealing to likelihood is an especially valid point here.

My apologies for not being clear about my DigiNotar and StartComm examples. What I intended to point out here is that in neither case were these failures something which one could have discovered in advance by reasonable amounts of checking how trustworthy the CA was. DigiNotar's compromise was (as far as I know) completely unpredictable and appears to have come from a state-level attack; StartComm actively hid itself and took significant work to uncover. Both CAs would have passed most people's checks done beforehand.

If advance warning is nonexistent, there's no point in even trying to check. If advance warning is hidden, you have a cost/benefit tradeoff to make, and I believe that in most cases (ie with low amounts of money involved), it's not good use of scarce and expensive engineer time to try to assess the state of a CA.

(This is especially the case if your company doesn't already have an engineer who is relatively expert in the CA ecosystem and knows where to even start looking. Without that expertise, would something like StartComm's quiet sale to WoSign have raised any alarms even if you discovered it?)

As far as magic bits go, the one thing that self-generated magic bits can't do is insure that a complete first time visitor can't be MITM'd by an active attacker. Whether this matters (or matters more than the scary browser warnings) depends on circumstances.

I think I can boil down an example about why I prefer not to talk about trust by itself as it relates to CAs. Imagine a hypothetical version of Let's Encrypt that has all of its operational excellence and security, but that uses root certificates that are not cross-signed and not included in any browsers. I would argue that this CA is exactly as trust-able as LE is (by hypothesis its procedures and technologies are the same, and we trust LE's), but clearly it is not as useful as a CA as LE is because it is not included in the root set of any browser (which we call 'trusted' and which generally implies that the people behind the browser believe that the CA will not issue certificates improperly).

If we say that this CA is not 'trustworthy' here, what we really mean is 'this CA is not in browser root sets and so the TLS certificates it issues provoke browser warnings'. This is useful in one sense (it is what most people care about), but I prefer to be explicit about what we mean (partly because 'trust' is a loaded term with tangled implications).

Reply on news.ycombinator.com