4 ms·

Its hardly extreme, your browser quite literally trusts hundreds of CAs. How much do you trust: GUANG DONG CERTIFICATE AUTHORITY Turkiye Bilimsel ve Teknoloj

by throwaway2048 7y ago

Its hardly extreme, your browser quite literally trusts hundreds of CAs. How much do you trust: GUANG DONG CERTIFICATE AUTHORITY Turkiye Bilimsel ve Teknolojik Arastirma Kurumu - TUBITAK Unizeto Sp. z o.o. XRamp Security Services Inc [1] AC RAIZ FNMT-RCM etc, To have not been compromised, or selectively delivering certs to "interesting" targets. Because they can tell you practically any host on the internet is a valid SSL domain. Stuff like DNS CAA records, and certificate transparency help somewhat, but are either trivially stripped by MITM attacks or not implemented at the CA or software level. [1] Appears to have went out of business entirely, how safe is that SSL cert now?

tptacek 7y ago
As Adam Langley has observed, fully implementing DANE doesn't get rid of these "hundreds of CAs", but rather adds a hundredsth-and-first --- the DNS hierarchy. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Meanwhile, CT has done more to protect the Web PKI in a couple years than DNSSEC ever has, and without forklifting out infrastructure. In fact, if rumors are true and at least some of the CA misissuance was detected due to broken pins, you can say the same thing about HTTP certificate pinning, and that technology wasn't even successful.
- peterwwillis 7y ago
  Doing anything to detect or prevent cert mis-issuance would have resulted in better outcomes, because DNSSEC has nothing to do with HTTPS. All the previous attempts were lame, optional hacks that had obvious workarounds. I keep repeating the following and people ignore it, but it's a guaranteed way to stop mis-issuance cold - not detect it after a few hours, not make it less likely when a domain and website opt to jump through five separate hoops. The registrar should coordinate between domain owners and certificate authorities to provide a second factor, second party, cryptographic verification of the intent to issue a cert. Rather than say "ok, this organization says who owns this domain", and then "ok, this other organization controls who can make domain certs", you actually validate the second thing based on the first thing. A hacker can control a domain, but that doesn't mean they own it, or that they control the private key(s) used to purchase or transfer the domain. And you can automate this a dozen different ways for large organizations, it's not difficult. The difficult part is getting the registrars, CAs, and browsers to accept it.
  - tptacek 7y ago
    Several of the most engaged and well-known people in the DNSSEC community, including Geoff Huston, who wrote this blog post and said as much in it, not only believe that DNSSEC does have something to do with HTTPS, but that HTTPS is essentially DNSSEC's raison d'être.
- cryptonector 7y ago
  It adds one more, yes, but it is exclusive. That is, if a domain wants to use DNSSEC and DANE, then that is mandatory for clients that support it, and for them WebPKI becomes a non-issue. The fact that DNSSEC is a true PKI, and the only true Internet-scale PKI, and one that is 100% aligned with the domainnames that users understand and which are embedded in URIs and email addresses, and the fact that DANE gives one a way to opt out of the WebPKI mess -- that all makes DNSSEC/DANE superior.
  - tptacek 7y ago
    If someone today wanted to use DANE exclusively, opting out of the rest of the Web PKI, what percentage of Internet users would be able to make HTTPS requests to their site?
    - comex 7y ago
      If browsers someday decide to implement some DANE-like feature, it would quickly become a fairly high percentage. There would still be a rather long period where browsers would have to continue to trust Web PKI certificates in general, even assuming they decided to phase them out. But... during that time, anyone using DNS over HTTPS with a trustworthy resolver would presumably get the right TLSA records, so their browser would reject attackers’ certificates even if validly signed by the Web PKI, no?
      - tptacek 7y ago
        That's an answer to the "hypothetical someday" question, but I'm interested in what the number would be today.
        comex 7y ago
        Then the answer is approximately 0%, right? But what does that prove? Perhaps DANE is not ready yet, or perhaps it’s struggled to get adoption because its design is fundamentally flawed; you’re versed on the details, I’m not. But to me that seems pretty orthogonal to whether “adding one more” is good or bad, or whether DANE’s design is fundamentally superior to the CA model as cryptonector claims. Or at least it’s a very oblique way to make a point about that.
theamk 7y ago
I trust that the first time those would try to do something bad, CT will catch them, and in a few weeks, they will no longer be trusted. Entering this list costs hundreds thousands of dollars, an attack using a different channel is going to be more economical.
- throwaway2048 7y ago
  CT only covers a small subset of CAs, and an even smaller subset of TLS clients.
  - profmonocle 7y ago
    > CT only covers a small subset of CAs I’m curious what you mean by this. CT is required for a cert to be trusted by Chrome. It seems like most CAs would participate, considering the low value of a cert not trusted by Chrome.
    - tialaramex 7y ago
      All major public CAs participate. There are some smaller subCAs which do not participate at all because they've defined their problem space such that Chrome + Safari is irrelevant, e.g. GlobalSign is responsible for some legacy subCAs that issue for a single company, that company doesn't care about web browsers for these certs and so logging (which isn't required by policy) is not interesting to them. GlobalSign expects these legacies to go away over the next year or so. Some of the large public CAs offer, either explicitly in their ordinary "purchase" journey or by special arrangement, not to log pre-certificates. And a few in-house CAs at very big outfits like Google deliberately don't log pre-certificates. You do NOT need to log pre-certificates to be trusted by Chrome, the reason to do that is to produce a drop-in experience for non-technical subscribers. If you have technical staff (which obviously Google does) you can log certificates retrospectively and staple the SCTs to the TLS setup as needed, allowing you to log on a "just in time" basis at a cost of needing a bunch more smart people to run your web servers. If those servers serve google.com and gmail.com you already needed a large international team anyway. So these latter certs do get logged, but literally it may be seconds before they're used (and inevitably Google has screwed up and not logged one and that broke some of their sites in Chrome briefly... closed course, professional drivers, do not attempt)
jcranmer 7y ago
> How much do you trust ... I trust them no less than I trust the domain resellers who administer DNS. It used to be that all you had to do to be a CA was knock on some browsers' doors and say "I'm a CA, plz add me, kthxbai." But that hasn't been true for quite some time; now you have to go through audits and several other hoops to be added to the lists, and miscompliance results in browsers dropping often fatal ban hammers, as DigiNotar and WoSign can attest. Browsers have also developed fairly stringent policies for enforcing minimum cryptographic rules and audit mechanisms that allow for strong policies. The goal of many DANE proponents is to replace the entire CA infrastructure and PKI system, but they haven't really put in the work to actually demonstrate the ability of clients to enforce strong policies in practice. The root keys are no longer unacceptably weak, but there is still a proliferation of weak keys. And it's not like DNS providers have done a good job of actually enforcing policies around things like name spoofing or enforcing UTS#46 validity. Instead, we're just supposed to take it at their word that DNS providers make better CAs than our current CAs, and drop all of the auditing and the like that happens today. And if the Libyan government decides it wants to MITM a popular link shortener, we're supposed to just shrug our shoulders and say "nothing we can do," I guess.
- throwaway2048 7y ago
  At least the Libyan government can only MITM .ly in DANE world, and not a Libyan CA and consequently every other domain in existence.
  - comex 7y ago
    Also, if the Libyan government decides they want to seize the domain of a popular link shortener (like the US government has seized some domains under US TLDs), they can just get a certificate from Let’s Encrypt. The Web PKI system isn’t really set up to stop them from doing that. The only scenario where the current CA system possibly has an advantage is if they apply their MitM covertly, only to a subset of clients. If this is discovered, CAs who participate in the scheme can be blacklisted, whereas with centralized control you’d have to basically blacklist all of .ly…

tptacek 7y ago

As Adam Langley has observed, fully implementing DANE doesn't get rid of these "hundreds of CAs", but rather adds a hundredsth-and-first --- the DNS hierarchy. https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html Meanwhile, CT has done more to protect the Web PKI in a couple years than DNSSEC ever has, and without forklifting out infrastructure. In fact, if rumors are true and at least some of the CA misissuance was detected due to broken pins, you can say the same thing about HTTP certificate pinning, and that technology wasn't even successful.

peterwwillis 7y ago
Doing anything to detect or prevent cert mis-issuance would have resulted in better outcomes, because DNSSEC has nothing to do with HTTPS. All the previous attempts were lame, optional hacks that had obvious workarounds. I keep repeating the following and people ignore it, but it's a guaranteed way to stop mis-issuance cold - not detect it after a few hours, not make it less likely when a domain and website opt to jump through five separate hoops. The registrar should coordinate between domain owners and certificate authorities to provide a second factor, second party, cryptographic verification of the intent to issue a cert. Rather than say "ok, this organization says who owns this domain", and then "ok, this other organization controls who can make domain certs", you actually validate the second thing based on the first thing. A hacker can control a domain, but that doesn't mean they own it, or that they control the private key(s) used to purchase or transfer the domain. And you can automate this a dozen different ways for large organizations, it's not difficult. The difficult part is getting the registrars, CAs, and browsers to accept it.
- tptacek 7y ago
  Several of the most engaged and well-known people in the DNSSEC community, including Geoff Huston, who wrote this blog post and said as much in it, not only believe that DNSSEC does have something to do with HTTPS, but that HTTPS is essentially DNSSEC's raison d'être.
cryptonector 7y ago
It adds one more, yes, but it is exclusive. That is, if a domain wants to use DNSSEC and DANE, then that is mandatory for clients that support it, and for them WebPKI becomes a non-issue. The fact that DNSSEC is a true PKI, and the only true Internet-scale PKI, and one that is 100% aligned with the domainnames that users understand and which are embedded in URIs and email addresses, and the fact that DANE gives one a way to opt out of the WebPKI mess -- that all makes DNSSEC/DANE superior.
- tptacek 7y ago
  If someone today wanted to use DANE exclusively, opting out of the rest of the Web PKI, what percentage of Internet users would be able to make HTTPS requests to their site?
  - comex 7y ago
    If browsers someday decide to implement some DANE-like feature, it would quickly become a fairly high percentage. There would still be a rather long period where browsers would have to continue to trust Web PKI certificates in general, even assuming they decided to phase them out. But... during that time, anyone using DNS over HTTPS with a trustworthy resolver would presumably get the right TLSA records, so their browser would reject attackers’ certificates even if validly signed by the Web PKI, no?
    - tptacek 7y ago
      That's an answer to the "hypothetical someday" question, but I'm interested in what the number would be today.
      - comex 7y ago
        Then the answer is approximately 0%, right? But what does that prove? Perhaps DANE is not ready yet, or perhaps it’s struggled to get adoption because its design is fundamentally flawed; you’re versed on the details, I’m not. But to me that seems pretty orthogonal to whether “adding one more” is good or bad, or whether DANE’s design is fundamentally superior to the CA model as cryptonector claims. Or at least it’s a very oblique way to make a point about that.

theamk 7y ago

I trust that the first time those would try to do something bad, CT will catch them, and in a few weeks, they will no longer be trusted. Entering this list costs hundreds thousands of dollars, an attack using a different channel is going to be more economical.

throwaway2048 7y ago
CT only covers a small subset of CAs, and an even smaller subset of TLS clients.
- profmonocle 7y ago
  > CT only covers a small subset of CAs I’m curious what you mean by this. CT is required for a cert to be trusted by Chrome. It seems like most CAs would participate, considering the low value of a cert not trusted by Chrome.
  - tialaramex 7y ago
    All major public CAs participate. There are some smaller subCAs which do not participate at all because they've defined their problem space such that Chrome + Safari is irrelevant, e.g. GlobalSign is responsible for some legacy subCAs that issue for a single company, that company doesn't care about web browsers for these certs and so logging (which isn't required by policy) is not interesting to them. GlobalSign expects these legacies to go away over the next year or so. Some of the large public CAs offer, either explicitly in their ordinary "purchase" journey or by special arrangement, not to log pre-certificates. And a few in-house CAs at very big outfits like Google deliberately don't log pre-certificates. You do NOT need to log pre-certificates to be trusted by Chrome, the reason to do that is to produce a drop-in experience for non-technical subscribers. If you have technical staff (which obviously Google does) you can log certificates retrospectively and staple the SCTs to the TLS setup as needed, allowing you to log on a "just in time" basis at a cost of needing a bunch more smart people to run your web servers. If those servers serve google.com and gmail.com you already needed a large international team anyway. So these latter certs do get logged, but literally it may be seconds before they're used (and inevitably Google has screwed up and not logged one and that broke some of their sites in Chrome briefly... closed course, professional drivers, do not attempt)

jcranmer 7y ago

> How much do you trust ... I trust them no less than I trust the domain resellers who administer DNS. It used to be that all you had to do to be a CA was knock on some browsers' doors and say "I'm a CA, plz add me, kthxbai." But that hasn't been true for quite some time; now you have to go through audits and several other hoops to be added to the lists, and miscompliance results in browsers dropping often fatal ban hammers, as DigiNotar and WoSign can attest. Browsers have also developed fairly stringent policies for enforcing minimum cryptographic rules and audit mechanisms that allow for strong policies. The goal of many DANE proponents is to replace the entire CA infrastructure and PKI system, but they haven't really put in the work to actually demonstrate the ability of clients to enforce strong policies in practice. The root keys are no longer unacceptably weak, but there is still a proliferation of weak keys. And it's not like DNS providers have done a good job of actually enforcing policies around things like name spoofing or enforcing UTS#46 validity. Instead, we're just supposed to take it at their word that DNS providers make better CAs than our current CAs, and drop all of the auditing and the like that happens today. And if the Libyan government decides it wants to MITM a popular link shortener, we're supposed to just shrug our shoulders and say "nothing we can do," I guess.

throwaway2048 7y ago
At least the Libyan government can only MITM .ly in DANE world, and not a Libyan CA and consequently every other domain in existence.
- comex 7y ago
  Also, if the Libyan government decides they want to seize the domain of a popular link shortener (like the US government has seized some domains under US TLDs), they can just get a certificate from Let’s Encrypt. The Web PKI system isn’t really set up to stop them from doing that. The only scenario where the current CA system possibly has an advantage is if they apply their MitM covertly, only to a subset of clients. If this is discovered, CAs who participate in the scheme can be blacklisted, whereas with centralized control you’d have to basically blacklist all of .ly…