4 ms·

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

by gefh 11y ago

0x0 11y ago
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)
- gefh 11y ago
  Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!
  - rvern 11y ago
    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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...
    - david_ar 11y ago
      Is there a particular reason why it's not supported?
      - pilif 11y ago
        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
        leni536 11y ago
        > 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.
        bostik 11y ago
        > [...]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.
        0x0 11y ago
        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 :)
glass- 11y ago
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 http://www.youtube.com/watch?v=Z7Wl2FW2TcA
- acdha 11y ago
  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).
  - glass- 11y ago
    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.
vtlynch 11y ago
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.
- gefh 11y ago
  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.
  - vtlynch 11y ago
    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.
    - glass- 11y ago
      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.
      - vtlynch 11y ago
        >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.
  - 11y ago
lisivka 11y ago
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.
- awakeasleep 11y ago
  Decentralize the PKI!
  - chmike 11y ago
    How would this make it more secure ?
- leni536 11y ago
  How to revoke?
  - lisivka 11y ago
    Blacklist bad certificates like spam lists.
e12e 11y ago
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.

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

by gefh 11y ago

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

0x0 11y ago

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)

gefh 11y ago
Maybe some combination of DNSSEC and cert pinning? Of course, without slowing anything down!
- rvern 11y ago
  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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... [2]: https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/ https://addons.mozilla.org/en-US/firefox/addon/dnssec-valida...
  - david_ar 11y ago
    Is there a particular reason why it's not supported?
    - pilif 11y ago
      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
      - leni536 11y ago
        > 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.
      - bostik 11y ago
        > [...]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.
        0x0 11y ago
        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 :)

glass- 11y ago

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 http://www.youtube.com/watch?v=Z7Wl2FW2TcA

acdha 11y ago
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).
- glass- 11y ago
  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.

vtlynch 11y ago

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.

gefh 11y ago
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.
- vtlynch 11y ago
  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.
  - glass- 11y ago
    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.
    - vtlynch 11y ago
      >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.
- 11y ago

lisivka 11y ago

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.

awakeasleep 11y ago
Decentralize the PKI!
- chmike 11y ago
  How would this make it more secure ?
leni536 11y ago
How to revoke?
- lisivka 11y ago
  Blacklist bad certificates like spam lists.

e12e 11y ago

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.