Hacker News new | past | comments | ask | show | jobs | submit login

Unfortunately, it's probably more common than you think for CAs to delegate their authority to other organizations; some US commercial CAs have been caught selling this capability.

The (small) good news is that these delegations aren't intended to compromise the TLS PKI (for instance, to enable dragnet surveillance). Instead, they're a part of the normal security regime within large IT departments. Network security teams want to be able to monitor comms in and out of their networks. Most large enterprise networks require users to navigate through a proxy to get to the Internet, and block direct access. The CA certificate delegation is simply an act of laziness: rather than push a custom certificate to all their endpoints, a big-enough organization might simply buy a CA certificate that will work by default.

The bad news, of course, is that this activity is extraordinarily dangerous to the rest of the Internet. If a delegated CA=YES cert is stolen, the thief can silently MITM connections across the world.

The fix for this problem is straightforward, and already in process. Chrome pins certificates: it hardcodes the relationships between certain sites and their place in the TLS PKI. When users at at networks with delegated ANSSI (or Trustwave or whoever) certs hit Google, the Chrome security team can detect the bullshit cert. This needs to (a) happen in all the browsers, not just Chrome, and (b) incur a CA death penalty in all but the most extraordinary circumstances.




I can understand why a lazy admin might want this, but why on earth would browser vendors permit CAs to issue such certificates? Surely it makes a joke of the entire security model?


X.509 has a top-down security model, which has benefits in authoritative deployment scenarios but is also vulnerable to things like seen today.

Chrome's ca-chain pinning is only available for a selected group of sites, e.g. google, twitter, tor2web while everyone can get their properties into the HSTS list (doesn't help if any CA goes bad).

This hard-coded, limited list does not scale. We need a bottom-up model, that allows something like pinning or "per-certificate" trust instead of recursive CA trust. This should not only work for things like TLS but also for S/MIME.

In addition, OS and browser vendors should ask the user before some certs are trusted or at least make it very easy to untrust a lot. On OS X it's a PITA to double click every CA cert and untrust it manually.


That's TACK.


I can't see, how this should work with S/MIME.


The CAs are not telling the browser vendors that they are doing this. When they get caught, "our investigation reveals that internal procedures and safety protocols had not been followed. oops."


The other fix is also very simple: death penalty for any business that sold a certificate delegation that is stolen. A little blunt, but if selling these represented the potential loss of millions of revenue, companies would pay more attention to it. We should all kill ANSSI certs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: