Hacker News Reader

Comment by ajross | Hacker News Reader

Obviously they don't blacklist the CA because doing so would break the sites of all of their customers. That's a very high-cost action, and the cost is borne by people not involved in the security situation. You do it only in an emergency. The system has an existing mechanism in place: revoke the cert, (though see the post by mrb above which argues that the revocation was done incorrectly).

Longer term, yes: I think looking at punishing TURKTRUST in some way, including revoking their CA, makes sense.

View on HN

Mozilla removed the CA, rather than just blacklisting the intermediate certificates: https://blog.mozilla.org/security/2013/01/03/revoking-trust-...

But isn't this exactly a high cost situation? Send a loud and clear message that CAs are entrusted with an enormous level of trust, and they damn well better make sure that their procedures are water tight, at the risk of losing their business overnight.

Punishing CAs is a laudable goal, but just immediately revoking a CA will result in worse security.

If TURKTRUST is immediately revoked, then all existing sites using it are toast, despite them not being compromised. That just tells users that SSL errors are not to be trusted, that you should just click through.

Hopefully, they remove TURKTRUST from signing future certificates. That way existing customers continue to work, but they can't do more damage, and the lesson is taught. Although, I don't think that's built-in to the cert system, it'd be a decent addition.

They could give them one month or even three months so their client have time to get their certs replaced, that's not terribly important. But in a broader sense, yes, they were compromised - they had an entity vouch for them that apparently vouched with a blank cheque.

If the CA issues certs like that they actually are compromised.

Maybe "cost" is the wrong metric to argue about. My point was that we have a situation where a bad cert was issued, and the correct treatment for it, barring special circumstance, is to use the process designed to revoke bad certs.

CA death penalty for someone like TURKTRUST matters to users a lot less than CA death penalty for a global CA like Verisign or Entrust. I'd rather get the policy demonstrated with a regional CA (or ideally a small/enterprise CA) and made clear enough to make all other CAs suitably cautious.

that logic is always going to apply , meaning effectively, you are never going to be able to remove their CA cert, because its always going to break their customer's sites. So no matter how glaring the security problems a CA is never getting delisted. The PKI model as it exists is broken beyond repair.

https://bugzilla.mozilla.org/show_bug.cgi?id=647959

No, Diginotar had their CA removed from several browsers and went bust https://en.wikipedia.org/wiki/DigiNotar

We need a solution to this. It comes up every time a ca misbehaves.

How hard would it be to allow a website to have multiple certs? If Turktrust's important customers had redundancy, we could pull less painfully.

Or for less rollout, could browsers acknowledge turktrust only as a root for .tr hosts? That would contain the damage, but probably not hit many legitimate customers.

Then you would just have two attack vectors; compromise either of the private keys and you can be the MITM.

You could use the same key and just submit multiple reqs to different CAs. This wouldn't be any worse than having one, and would be a way to have a "backup cert" in case a CA screws up.

Considering the private keys are probably stored in the same place, I wouldn't consider it an additional attack vector.

You can already MITM if you compromise any CA's private key.

Reply on news.ycombinator.com