Hacker News Reader

Comment by gefh | Hacker News Reader

Is the CA model just unfixably broken at this point? What should replace it if so?

Convergence was the perfect replacement, but it never gained any traction.

Moxie's talk at BlackHat[0] introducing it is a good watch for those unfamiliar with the idea, and if you want to be wistfully frustrated at what could have been.

[0] http://www.youtube.com/watch?v=Z7Wl2FW2TcA

We still don't know how that would have worked in practice. Even skilled people have trouble making trust decisions reliably for everything and while we'd avoid the compromised CA threat I'm certain we'd start seeing equivalents like dishonest or incompetent notaries – and those might last longer because fewer people see the dodgy results since not everyone is using the same set of notaries.

If it became popular, it's really easy to imagine something like the Great Firewall being configured to block outside notaries to encourage people to use local notaries which are still under the control of the local authorities.

That's not to say it's not interesting work or potentially a solid improvement, only that I would be extremely hesitant to make absolute statements about an untested internet-scale security protocol. The approaches we're seeing work now do so because they're adding to well-understood protocols (e.g. HSTS, key-pinning, etc.) or don't change the trust model (if Google goes rogue, Chrome users are already screwed).

I have no doubt that there would be incompetent or dishonest notaries. The difference being that in an alternative universe, where Convergence is used, a rogue notary doesn't destroy the trust of the entire system. When Symantec is a rogue notary, oh well, Mozilla and Google push out an update and no one uses Symantec anymore, their notary just becomes irrelevant. However, in this reality, the darkest timeline, deciding to stop trusting Symantec immediately breaks 30% of HTTPS websites on the internet, so even though Symantec has given everyone plenty of reasons to stop trusting them, we have no choice. Same for Comodo, their notary would have stopped being used in 2011 (after their root certificate compromise).

Instead, with Comodo and Symantec combined, we now have over 60% of HTTPS websites secured by authorities who are incompetent and/or dishonest.

> Convergence was the perfect replacement, but it never gained any traction.

It's really not.

https://github.com/okTurtles/dnschain/blob/master/docs/Compa...

That sounds like it was written by someone who doesn't completely understand Convergence, and also has an alternative agenda (they want their own solution adopted).

> It is not very user friendly. Users are asked to manage a list of notaries. This list of notaries is stored locally on the computer, or even the browser. Managing this list is not feasible for most users.

Browsers can replace the CA root certs with a notary list and pick notaries at random from the list. This is not a problem like with CAs as multiple notaries have to collude to form a consensus (you only need one rogue CA), and rogue notaries can be removed on a whim, unlike CA roots which are indentured (removing a CA breaks any site that uses it).

> It's not clear how well it protects (or can protect) if some notaries haven't yet cached the latest SSL certificate for a particular website.

This doesn't matter at all. The notary looks the cert, checks the signature and tells you if it matched what you're seeing.

> It does not provide MITM protection on first visit.

Yes it does. If your connection is MITM'd the notaries won't match your perspective.

> Waiting for group consensus means all connections have higher latency (slower page loads).

Only the first visit, before the notaries confirm the certificate signature you're seeing, and then you cache it and only need to check it again if it changes.

> Both Convergence and Perspectives (see below) results in you sharing every website you visit with random third-parties.

Bounce notaries exist for this reason.

> With DNSChain, if privacy is a concern, you can run your own server and only rely on it

Same with Convergence.

Thank you glass-! The information you've provided here I did not find in the Convergence documentation. I've updated the document to be accurate with your reply and added a new, rather significant critique that I somehow missed the first time around. Please feel free to re-review:

> It does not protect you if the MITM is sitting in front of the server you are visiting. Notaries would see exactly the same key that you see (the one that belongs to the MITM).

Something that sets things up so that the actual domain registrar becomes the only valid issuer of certificates for any given domain.

That would kill the possibility of unrelated entities issuing and obtaining certificates (well, unless you go with a registrar that happens to cheat on you, but at least you can avoid shady registrars and limit that possibility. Also if you registrar is that shady, they could already today switch around your nameservers or WHOIS records if only for a second and simply buy a certificate)

Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!

That's called DANE, and it's already in use by a number of websites and supported by many registries. Unfortunately the major browsers do not support it.[1] There's an extension for Mozilla Firefox that implements it.[2]

[1]: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...

Is there a particular reason why it's not supported?

Because DNSSEC can't be trusted. Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs.

Of the two evils, the CA model is slightly better because the incentives align

> DNSSEC places trust on the various countries registries

I'm not a security expert. Aren't DV certificates put trust on the registries too? If you control the domain then it's trivial to get a DV cert for the site. So with the CA model you trust both CAs and registries.

> [...]Instead of placing the trust on the commercial CAs that have all the incentive to do a good and trustworthy job if they want to stay in business, DNSSEC places trust on the various countries registries that have all the incentive to abuse their powers for national security or to enforce the current governments beliefs.

With very high probability, there are a number of nation-state governments controlling some entries in your CA store. Even a short glance at the content of debian's "ca-certificates" package gives these:

  - CNNIC (China)
  - TÜBITAK (Turkey)
  - WoSign (two certs, one specially named for China)
  - Juur (Estonia)
  - TeliaSonera (Sweden, Finland)

The last two are likely not going to be compelled to issue rogue certs, but technically the data interception laws in Sweden (and the ones proposed in Finland) might not even require any modifications to allow such operations. There are probably a lot more.

Certificate pinning will help, but even that faces a bootstrap problem for new clients. With smartphones being replaced, on average, every two years, there are ALWAYS new clients. Incidentally, a wide-scale MITM for new clients only is something I would expect the Great Firewall to be capable of.

So the commercial incentives for CAs may be more suitably aligned, but there is still overlap with the DNSSEC problems.

If only the registrar holding a domain can issue certs, and for example you don't trust CNNIC or the .cn TLD operator (which also happens to be CNNIC in this case), then you can simply avoid .cn domains and register your domain elsewhere, at a registrar that you trust not to issue fake certificates.

If you cannot trust the TLD operator, then you have already lost, as the TLD operator could arbitrarily fake data in WHOIS if only for a second, and obtain a DV certificate from any CA right now, since a WHOIS lookup for an email address is usually what powers the DV. But at least then you'd eliminate the risk of third parties (not the TLD operators) obtaining a parallel certificate that you don't even know about. Right now, I don't think there's anything stopping CNNIC (or any other root CA) from issuing certs for yourdomain.com, and you wouldn't even know it.

Might bring some value back into the reputation of TLDs and registrars, as a bonus :)

Ask to remember certificate at first contact with site, like openssh. Keep certificates in protected wallet, like passwords. Warn about any change of certificate, like Chrome does for Google sites. Get fingerprints of common sites from trusted sources by subscription, like spam and ad blocking lists.

Decentralize the PKI!

How would this make it more secure ?

How to revoke?

Blacklist bad certificates like spam lists.

Yes and no. Moving the responsibility for linking/attesting a secret key to an ip address (and DNS name) to the DNS system is probably the more sane model - but it's not really possible to do in a backwards-compatible way (such a system would be a new system).

The first thing we could/should do, is probably demand support for (sub)domain limits on CA certs. Eg one cert to sign CA certs for .com (but not eg: .cn) - and give each CA a limited cert for some subset of TLDs (preferably one for each). And remove the wildcart cert nonsense, and just give domain holders a CA cert for their domain.

[edit: And by demand, I mean that SSL clients such as Chrome and Thunderbird and Outlook and Safari... should treat "unbounded" CA certs as invalid. It would require a major overhaul. Also note that there are lots of broken clients (all of them?) that ignore limitations so any security gain wouldn't be seen until all those were upgraded/phased out. It may indeed be more realistic/easier to move to a new/more secure system (ie: the "www" would be "secure" with a "secure DNS with records for certs", but IMAP would remain broken)]

This would "compartmentalize" the trust somewhat, meaning that compromises would be more limited.

It would also allow us to move to a setting where the default is mistrust, rather than trust: make it normal that both certs and (intermediate) CA certs need to be rotated, say every month or so.

Certainly not perfect - but I'm not sure I trust the DNS system with encryption keys much more than the current CAs. So I'm not sure that "securing" DNS will really help - sure you could argue that SSL "just" binds a cert to a domain name -- but that isn't really any meaningful level of trust either. The fact that DNS is insecure, and CAs can sign willy-nilly any domain is bad. I'm not convinced allowing eg. all Russian registrars of .com-domains to issue .com certs is that much of an improvement.

No, its not. This problem detected by a third-party due to a recent industry initiative (Certificate Transparency). Now Google has doled out appropriate punitive measures which will greatly reduce chances of this happening again.

The industry is moving forward and doing lots to improve.

Lets also not forget a hugely important point that there is no evidence of harm from Symantec's action. They were just embarrassingly stupid and irresponsible.

But this is the 4th or 5th similar announcement I recall, some of which have been malicious, some incompetent. Maybe CAs are getting better but 'trusted' is not the first word that comes to mind any more.

Is the system problematic? Yes. Does it have room for improvement? Tons. Is it broken? No, I dont think so.

I dont think the CA system is unique in having breaches, holes, or incompetent actors.

The CA system is unique is that one hole, breach or incompetent actor compromises the entire system.

It's also unique is that when an authority has a hole, breach or is an incompetent actor, it's very difficult to remove them from authority.

>It's also unique is that when an authority has a hole, breach or is an incompetent actor, it's very difficult to remove them from authority.

There is no proof of this. There are lots of systems in place to deal with mistakes and trust breaches. If it gets to the extent that a Root or CA needs to be removed from trust stores, then they are removed.

Just this year we saw two CAs lose their trust.

This is the first of those by a CA that is actually too big to fail.

I think the last too-big-to-fail CA that misissued certs in recent memory was Comodo, in March 2011, who had a reseller's account broken into (apparently by an Iranian state-sponsored attacker). And that was well before there were options like insisting on Certificate Transparency, and Comodo reacted well (they had an accurate audit trail and deployed changes that blocked the attacker when they retried two weeks later), and it didn't involve active incompetence on Comodo's part. Since then, there's also been CNNIC, India CCA, TURKTRUST, ANSSI, and DigiNotar. CNNIC and DigiNotar have both been removed from Chrome's root store, India CCA and ANSSI have been restricted to their country's TLDs, and TURKTRUST (which apparently reacted well) lost their EV powers.

(There were also a couple of misissued certs due to Microsoft Live allowing anyone to sign up for accounts like "hostmaster", but those are not considered the CA's fault.)

Reply on news.ycombinator.com