Live data from Hacker News

Google warns of unauthorized TLS certificates trusted by almost all OSes

arstechnica.com

41–50 of 76 posts

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#41
post #33

Earlier quoted context omitted.

I am confident that if DNSChain is such an obviously good solution, it will be evangelized by at least one person who doesn't complain about being downvoted, or claim that people clearly don't want security. Are you Tao Effect? I've seen you on messaging@moderncrypto, and you have trouble staying on topic. I'd have been more inclined to give you the benefit of the doubt if you were some second person in the world who…

When you run out of legitimate arguments resort to personal attacks, got it. The number of people on Earth who've spent the time studying Certificate Transparency in depth could probably be counted on two hands. You and I are two of them. That leaves ~8 other people (who are probably not reading these threads) to comment. I'm grateful to everyone who's taken the time to support DNSChain, Namecoin, and related project…

I'm surprised you find that a personal attack.

I think that it's important that we find a solution to the CA problem. That's why I'm engaging you as earnestly as I can about CT and DNSChain in another subthread. (And please call me out if you think I'm being less than earnest or unnecessarily dismissive.) If CT is in fact flawed the way that you're saying, then it's important for not only me to understand that, but for everyone to understand that. If DNSChain is in fact a good solution, or even close to a good solution, it deserves the enthusiastic attention of way more than 10 people.

Therefore it's important to me that you not get downvoted. So I'm trying to help you get listened to, by telling you why I find myself wanting to reach for the downvote button—but the things you say are important enough that they deserve being engaged with, even if the manner in which you say it is frustrating.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#42
post #33

Earlier quoted context omitted.

> Perhaps the downvotes are because it bores them? I guess it shouldn't matter to you that you get downvoted, either. Either folks want this problem to be solved, or they don't.

I am confident that if DNSChain is such an obviously good solution, it will be evangelized by at least one person who doesn't complain about being downvoted, or claim that people clearly don't want security. Are you Tao Effect? I've seen you on messaging@moderncrypto, and you have trouble staying on topic. I'd have been more inclined to give you the benefit of the doubt if you were some second person in the world who…

FWIW: yes, that's Greg Slepak.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#43
post #24

Earlier quoted context omitted.

I'm on FF 36.0 on Kubuntu 14.10 - I removed the certs for CNNIC and then to test went to the CNNIC website and rewrote the address as https. Website still shows the lock symbol and still shows the cert verified by the CNNIC root CA?!? Seems the removal is slightly glitchy somehow, third time worked. 2 things I notice: 1) there are a lot of default trusted suppliers, seems that this should perhaps be selected on insta…

I'm not thinking very hard about it, but that second bullet sounds like a really good idea.

Looks like Mozilla has this data in aggregate, if I'm understanding this web page right:

http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VAL...

Ignore the graph and match up the table below with this C array:

https://dxr.mozilla.org/mozilla-central/source/security/mana...

If I'm understanding the meaning of "Bin Number" right, not all of the 0s are surprising. But some are. For instance, the AOL CA hasn't been used to sign any certs that have been seen. (I guess, in a sense, that's not really surprising...)

I'd be cool if someone better at front-end than I could present the data with useful labels, and also mark each CA by whether it's in the non-Mozilla roots.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#44
post #36

Earlier quoted context omitted.

Looks like a complex attack, and "not all CAs will necessarily have their own log." and same for the converse too.

Legitimate SCTs can be used in attacks just as well (this will probably be the common case), as explained here: https://news.ycombinator.com/item?id=9254713

Yes, CT would only allow detection. Revocation would be a different problem.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#45
post #3

http://googleonlinesecurity.blogspot.com/2015/03/maintaining... is a better URL. (For potential future reference, the current URL is http://arstechnica.com/security/2015/03/google-warns-of-unau... )

I disagree, in this case the direct link is not a better URL. The Ars Technica article (as many issues as I have with them) correlates not only the Google alert, but also followup conversations on Twitter and from Mozilla. This kind of correlation (and analysis) is the very definition of adding value added.

It also clearly links to the Google blog, so it's hard to accuse them of trying to co-opt Google's content as their own.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#46
Just revoking the intermediates is not enough. This tells the main culprits that it's ok to issue intermediates to do whatever and then deny responsibility as it gets detected.

The only possible course of action is to hold the root responsible and to remove them from the trust store.

The CA system is fragile enough as it is and only the prospects of immediately going out of business can be any deterrent for CAs not to start doing shady stuff.

Yes. Revoking the root is annoying for customers of that root, but I'm sure other CAs will gladly offer a free or really cheap replacement program. And if the affected root is REALLY big, then just pre-announce the revocation for a year or two. Just like what Google is doing with the sha1 certs.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#47
post #40

Earlier quoted context omitted.

> I don't understand what being a CA (either by actually being a CA, or by hacking into one) is supposed to gain you here. CT is designed to protect against CA misbehavior. If the argument is that it doesn't prevent a MITM, it just permits one to be detected, then yes, but that isn't faking an SCT. I'm happy to argue about whether detection vs. prevention is useful, but I just want to be clear that that's a different…

> These attacks might be "detectable" after they've happened, but so what? So was this one. Damage will have been done. Well, in this particular case, there was presumably an intention to conduct the MITM long term. Buying a Palo Alto Networks device, paying for a (fairly expensive!) unconstrained intermediate, and being able to MITM a connection for a few hours is not very useful. There are certainly attackers who w…

> I don't see why the CA wouldn't immediately query logs for all certificates that chain off of their intermediates, to verify that intermediates are only used in the way that people said they'd be used.

That's unlikely to happen (I suspect) because the amount of data that would need to be processed would be significant. Each CA would have to effectively mirror all of the logs out there, and the logs impose rate limits on queries. It would be interesting also to see what happens when a log gets DDoS'ed (we know OCSP servers aren't useful because of that problem).

> Is it possible to configure the browser to fail closed if it hasn't reached its update server within some period of time?

Sure.

> Is this something that CT can/should do? Can we standardize something like Chrome's CRLsets, and make the browsers require they be able to reach CRLsets somehow, either through the vendor or through a CT log?

Can? Yes. Should? Well, I suspect this would be yet another user experience nightmare that would therefore lead to little support for the idea.

> What's DNSChain's solution here? Can a MITM pretend that the blockchain hasn't moved in a few weeks?

Are you referring to the connection between clients and DNSChain or a blockchain and its network?

If the former, then a MITM's only option is to block connection to DNSChain, which would be treated as a MITM attack (appropriately).

If the latter, yes, a MITM could do that, and if PoW is being used by the blockchain this attack would be detectable instantly due to an immediate and significant drop in block difficulty. Even if it somehow wasn't detected, it still wouldn't allow the MITM to issue fraudulent certificates.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#48
FWIW, here's what I just did on my (Arch) Linux machine:

  $ for f in /etc/ssl/certs/*.pem; do sudo ln -sfn "$f" /etc/ca-certificates/trust-source/blacklist/; done
  $ sudo update-ca-trust
This will block all currently installed CAs (as well as double-block some, but that doesn't really matter). You then need to add them back in.

Restart your browser, and go to websites you access frequently (change them to https:// if necessary). Click the (broken) padlock and read off what CA they used; remove the corresponding .pem file from the blacklist directory. Some might be signed by intermediate certs and thus hard to find, but SSL Hopper has a great chain inspection tool at https://www.sslshopper.com/ssl-checker.html you can use to identify the topmost CA cert you need to whitelist.

After you're done, run "sudo update-ca-trust" again, and restart your browser. All normal sites should work, and you've gotten rid of ~160 root certs.

If it's of interest to anyone, here are the ones I whitelisted to get all sites I bothered to try up an running:

  $ sudo rm DigiCert_* GeoTrust_* Go_Daddy_* GlobalSign_* VeriSign_* StartCom_Certification_Authority* Comodo_* AddTrust_* Thawte_* thawte_Primary_Root_CA* Baltimore_CyberTrust_Root.pem UTN_USERFirst_Hardware_Root_CA.pem Visa_eCommerce_Root.pem
  $ ls /etc/ssl/certs/*.pem | wc -l
  206
  $ ls /etc/ca-certificates/trust-source/blacklist/
  163
EDIT: Note that this is not a perfect solution; the CAs you've whitelisted could still go bad, and you'll need to blacklist any new CA certs that are added with subsequent ca-certificates updates. But it's a start.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#49
post #43
post #24

Earlier quoted context omitted.

I'm not thinking very hard about it, but that second bullet sounds like a really good idea.

Looks like Mozilla has this data in aggregate, if I'm understanding this web page right: http://telemetry.mozilla.org/#filter=nightly%2F39%2FCERT_VAL... Ignore the graph and match up the table below with this C array: https://dxr.mozilla.org/mozilla-central/source/security/mana... If I'm understanding the meaning of "Bin Number" right, not all of the 0s are surprising. But some are. For instance, the AOL CA hasn't be…

You can look at the local telemetry for your current Firefox session, including this variable, by going to about:telemetry, which sort of gets you what pbhjpbhj was looking for, albeit in an inconvenient and limited fashion.

Re: Google warns of unauthorized TLS certificates trusted by almost all OSes

#50
post #41

Earlier quoted context omitted.

When you run out of legitimate arguments resort to personal attacks, got it. The number of people on Earth who've spent the time studying Certificate Transparency in depth could probably be counted on two hands. You and I are two of them. That leaves ~8 other people (who are probably not reading these threads) to comment. I'm grateful to everyone who's taken the time to support DNSChain, Namecoin, and related project…

I'm surprised you find that a personal attack. I think that it's important that we find a solution to the CA problem. That's why I'm engaging you as earnestly as I can about CT and DNSChain in another subthread. (And please call me out if you think I'm being less than earnest or unnecessarily dismissive.) If CT is in fact flawed the way that you're saying, then it's important for not only me to understand that, but f…

> Therefore it's important to me that you not get downvoted. So I'm trying to help you get listened to, by telling you why I find myself wanting to reach for the downvote button—but the things you say are important enough that they deserve being engaged with, even if the manner in which you say it is frustrating.

Well, I appreciate that, thanks. I also appreciate that you decided to engage in actual honest discussion.

Post reply on HN