5 ms·

> The efforts of the CAB Forum to instil some level of additional trust in the system appear to be about as effective as sticking one’s fingers into a leaking d

by theamk 7y ago

> The efforts of the CAB Forum to instil some level of additional trust in the system appear to be about as effective as sticking one’s fingers into a leaking dam. The number of trusted CAs has extended conventional credibility well beyond the normal boundaries and has pushed the unsuspecting user into a fragile state of credulity. > Efforts to improve this mess, such as Extended Validation (EV) certificates, have gained no traction with users, as they are largely immune to subtle changes in the content and colours of the browser’s navigation bars, and certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. That’s a pretty extreme opinion. I am surprised it appeared on official apnic.net site. I do wonder if it has anything to do with the fact that most major browsers, who actually decide who get to be CA, are US based.

rschoultz 7y ago
I don't think Geoff Huston argued for more CAs or a different distribution. His view is, in my experience, shared by many, regardless of nationality, though not as vocal. There are simply too many examples of compromised CAs, and the webpki system makes anyone vulnerable to the weakest of them.
- theamk 7y ago
  Are compromised CAs worse than other software bugs though? Yes, we have too many CAs, and some of them are pretty suspicious. It would be great to be able to give them TLD limits. But becoming a CA is still very slow and expensive, and certificate transparency will catch bad behavior. So there is a very strong incentive for each CA to be good. Compare this to random server exploit, which is deployed anonymously and has no direct monetary harm to the maker company. No wonder there has been very few cases of CA-based compromise compared to good old software exploits.
- snowwrestler 7y ago
  I find it hard to square the paranoia about CAs with the imposed death penalty on Symantec's certificate business. If no one is watching the CA's, how did Symantec get caught and punished? And for what seemed like relatively minor infractions? I think its possible that the average web developer underestimates the degree to which the web PKI is monitored by private and government organizations. And public cert logging only makes that easier.
- cryptonector 7y ago
  "More CAs" == worse. I don't know what "different distribution" means. Anything that doesn't have a strong hierarchical binding to the names users understand (domainnames) is simply not going to have better security than WebPKI.
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.
cryptonector 7y ago
DNSSEC is the only true PKI we have. It has one set of roots and is workable even if we have competing roots, provided they sign roughly the same TLDs. The DNSSEC PKI is also truly hierarchical, while the WebPKI is absolutely not. The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users cannot understand x.500 naming. So the web absolutely needs a reliable way to authenticate domainnames. WebPKI is not reliable, no way, not even with CT. That leaves DNSSEC as the only remaining alternative. It's DNSSEC or WebPKI, and WebPKI is no good. So it's DNSSEC or nothing.
- jcranmer 7y ago
  > The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users don't actually understand domain names. If Google were to make the result of searching for "facebook" return a facebook.google.com that MITM'd Facebook, they could capture ¼-⅓ of Facebook's traffic without any software complaining about it. Your comments have a strong sense of "if we just made sure that the server is truly using the domain name, then everything would be hunky-dory." In fact, as far as I can tell from actual security problems, fully securing the domain name (or even authenticating the server properly in the first place) wouldn't improve security meaningfully for most people.
  - comex 7y ago
    By your logic, why use HTTPS in the first place? (Or at least why care about certificate validation at all?) Hint: Because ISPs are in a position to intercept and even MitM traffic, but generally not in a position to decide what URLs you go to.
    - tialaramex 7y ago
      Only what is possible can be done. We have the technology to actually ensure that https://news.ycombinator.com/ https://news.ycombinator.com/ is really https://news.ycombinator.com/ https://news.ycombinator.com/ but we do not have technology that could ensure this is where you get when you type "Hacker News" into Bing. Part of what has to happen to civilisations around technology is that they adjust to what is possible. Different adjustments are possible, the egg washing thing is an example: in some countries you purchase eggs in the state they're laid (which means sometimes there is dirt on the shell), and you don't keep them in a refrigerator; in other countries you purchase eggs "washed" clean and they're refrigerated. Either of these approaches works fine, but mixing them up doesn't work. So, for example, teaching people to bookmark sites is an adjustment that works with our technology, whereas teaching them to get everywhere by following sponsored links on Google not so much. WebAuthn is another example. A Security Key doesn't care that you thought mybnak.example was your bank, doesn't care if you got there from a phishing email, from a bogus advert or you just can't spell when typing. It will resolutely refuse to provide mybnak.example with your mybank.example credentials because those strings are not the same. You can press the button over and over, swear, throw things, but because it's based on the URL it won't let you screw yourself.

by theamk 7y ago

rschoultz 7y ago

I don't think Geoff Huston argued for more CAs or a different distribution. His view is, in my experience, shared by many, regardless of nationality, though not as vocal. There are simply too many examples of compromised CAs, and the webpki system makes anyone vulnerable to the weakest of them.

theamk 7y ago
Are compromised CAs worse than other software bugs though? Yes, we have too many CAs, and some of them are pretty suspicious. It would be great to be able to give them TLD limits. But becoming a CA is still very slow and expensive, and certificate transparency will catch bad behavior. So there is a very strong incentive for each CA to be good. Compare this to random server exploit, which is deployed anonymously and has no direct monetary harm to the maker company. No wonder there has been very few cases of CA-based compromise compared to good old software exploits.
snowwrestler 7y ago
I find it hard to square the paranoia about CAs with the imposed death penalty on Symantec's certificate business. If no one is watching the CA's, how did Symantec get caught and punished? And for what seemed like relatively minor infractions? I think its possible that the average web developer underestimates the degree to which the web PKI is monitored by private and government organizations. And public cert logging only makes that easier.
cryptonector 7y ago
"More CAs" == worse. I don't know what "different distribution" means. Anything that doesn't have a strong hierarchical binding to the names users understand (domainnames) is simply not going to have better security than WebPKI.

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.

cryptonector 7y ago

DNSSEC is the only true PKI we have. It has one set of roots and is workable even if we have competing roots, provided they sign roughly the same TLDs. The DNSSEC PKI is also truly hierarchical, while the WebPKI is absolutely not. The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users cannot understand x.500 naming. So the web absolutely needs a reliable way to authenticate domainnames. WebPKI is not reliable, no way, not even with CT. That leaves DNSSEC as the only remaining alternative. It's DNSSEC or WebPKI, and WebPKI is no good. So it's DNSSEC or nothing.

jcranmer 7y ago
> The web is absolutely built on naming of services that users can mostly understand -- that is, domainnames. Users don't actually understand domain names. If Google were to make the result of searching for "facebook" return a facebook.google.com that MITM'd Facebook, they could capture ¼-⅓ of Facebook's traffic without any software complaining about it. Your comments have a strong sense of "if we just made sure that the server is truly using the domain name, then everything would be hunky-dory." In fact, as far as I can tell from actual security problems, fully securing the domain name (or even authenticating the server properly in the first place) wouldn't improve security meaningfully for most people.
- comex 7y ago
  By your logic, why use HTTPS in the first place? (Or at least why care about certificate validation at all?) Hint: Because ISPs are in a position to intercept and even MitM traffic, but generally not in a position to decide what URLs you go to.
  - tialaramex 7y ago
    Only what is possible can be done. We have the technology to actually ensure that https://news.ycombinator.com/ https://news.ycombinator.com/ is really https://news.ycombinator.com/ https://news.ycombinator.com/ but we do not have technology that could ensure this is where you get when you type "Hacker News" into Bing. Part of what has to happen to civilisations around technology is that they adjust to what is possible. Different adjustments are possible, the egg washing thing is an example: in some countries you purchase eggs in the state they're laid (which means sometimes there is dirt on the shell), and you don't keep them in a refrigerator; in other countries you purchase eggs "washed" clean and they're refrigerated. Either of these approaches works fine, but mixing them up doesn't work. So, for example, teaching people to bookmark sites is an adjustment that works with our technology, whereas teaching them to get everywhere by following sponsored links on Google not so much. WebAuthn is another example. A Security Key doesn't care that you thought mybnak.example was your bank, doesn't care if you got there from a phishing email, from a bogus advert or you just can't spell when typing. It will resolutely refuse to provide mybnak.example with your mybank.example credentials because those strings are not the same. You can press the button over and over, swear, throw things, but because it's based on the URL it won't let you screw yourself.