Live data from Hacker News

Google warns of unauthorized TLS certificates trusted by almost all OSes

arstechnica.com

11–20 of 76 posts

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

#11
post #8

Earlier quoted context omitted.

> Certificate Transparency is a solution CT would not have prevented these attacks. Google would be exactly where they are right now: knowing who issued cert, and that's it. Short form: https://github.com/okTurtles/dnschain/blob/master/docs/Compa... Long form: https://blog.okturtles.com/2014/09/the-trouble-with-certific... (EDIT: How about an honest discussion instead of a downvote? If you disagree, you are welcome t…

Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. That sounds difficult to implement reliably and quickly enough for a MITM to work. (Not to men…

> Not to mention that most off-the-shelf MITM proxies will intentionally not implement this

To add on to this: the certificate was generated from a Palo Alto Networks device.

https://groups.google.com/forum/#!topic/mozilla.dev.security...

If Palo Alto aren't willing to implement CT, which I'm pretty sure they aren't because they're a legitimate company whose business isn't driven by people who abuse globally-valid certificates, then (regardless of whether SCTs can be forged in theory) that alone would have prevented the attack.

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

#12
post #8

Earlier quoted context omitted.

Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. That sounds difficult to implement reliably and quickly enough for a MITM to work. (Not to men…

> Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. 1. Certs don't need to include SCTs, so, end of story. 2. Even if that was a requirement, th…

> Doesn't matter to me if it bores them. If that's a problem maybe they shouldn't downvote in the first place?

Perhaps the downvotes are because it bores them? I guess it shouldn't matter to you that you get downvoted, either.

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

#13
post #12

Earlier quoted context omitted.

> Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. 1. Certs don't need to include SCTs, so, end of story. 2. Even if that was a requirement, th…

> Doesn't matter to me if it bores them. If that's a problem maybe they shouldn't downvote in the first place? Perhaps the downvotes are because it bores them? I guess it shouldn't matter to you that you get downvoted, either.

> 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.

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

#14

The fact that it's CNNIC that has issued these dangerous certificates is not exactly relevant to the problem at hand; More than one root authority has made mistakes in delegation, and several have made the mistake of not checking the delegation bit and allowing third-parties to request intermediate certificates. Still, it bears repeating that CNNIC, which is effectively a branch of the chinese government, has a root…

My gut agrees with you, but I found Ryan Sleevi's arguments on this thread interesting (the proposal at hand is to require, effectively, a *.cn name constraint on CNNIC):

https://groups.google.com/forum/#!topic/mozilla.dev.security...

"Another reason is it encourages the trust store to be used for regional or arbitrary distinctions ('not designed to be served by that CA'). This amounts to naught more than recognizing borders on the Internet, a somewhat problematic practice, for sure. That is, for every 'constrained' CA that you can imagine that ONLY wants to issue for a .ccTLD, you can also imagine the inverse, where ONLY a given CA is allowed to issue for that .ccTLD. The reasoning behind the two are identical, but the implications of the latter - to online trust - are far more devastating. [...]

"As it relates to online trust ecosystem, we can see these government CAs have either botched things quite spectacularly (India CCA) or been highly controversial (CNNIC). The arguments for CNNIC aren't 'Well, if they're only MITMing .cn users, that's OK', it's 'Well, they could MITM'. [...]

"Name constraints, as presented, give tacit approval to the CAs constrained to botch things, as long as they do so only in their little fiefdoms. But when these fiefdoms easily represent millions-to-billions of Internet users, especially in emerging markets, do we really believe that their needs are being served?

"That is, in essence, why I think a change like this is so dangerous. It strives to draw borders around the (secure) Internet, and to acknowledge that what you do in your own borders, to your own users, is an issue between you and them. I don't think that's a good state for anyone to be in."

This doesn't directly address your proposal, that individual internet users remove CNNIC from their personal trust stores. But if we, the internet community, really believe that a branch of the Chinese government has no place in root stores, then we shouldn't allow the "weary giants of flesh and steel" to make that any different for those internet users who have the misfortune of living within or doing business within the borders of China.

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

#15

Action is really needed. A system that can be breached just by any CA company that is more interested in money than in security (also at least one big CAs has a bad history concerning security) is plainly broken. There should at least be a kind of overseer that has the ability to intervene when bad behavior is reported. In the current situation, it is impossible to trust this "system of trust". It just sounds similar…

> Action is really needed. Lot of good people taking action on this. There are solutions that totally solve this problem. Talk about them here though, you'll get downvoted (just see my comments). It means either: people want security theater, or they're completely ignorant about the topic.

I think people have different definitions of "solutions that totally solve this problem". If your solution totally solves this problem technically, but is unlikely to be deployed in the real world, it is not a solution that totally solves this problem in my book. Although I wouldn't downvote such claims, I can understand people downvoting "total solution" claims if the solution clearly is not (according to the above definition).

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

#16
post #8

Earlier quoted context omitted.

Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. That sounds difficult to implement reliably and quickly enough for a MITM to work. (Not to men…

> Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. 1. Certs don't need to include SCTs, so, end of story. 2. Even if that was a requirement, th…

2. Even if that was a requirement, they can be faked just like the certificate.

Huh?

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

#19
post #4

Earlier quoted context omitted.

Certificate Transparency is a solution. It's not my favorite solution, but it's far and away my favorite solution that stands a chance of working. http://www.certificate-transparency.org/ This particular bad behavior, like entirely too many other breaches, was (probably) noticed because Google's own browser saw illegitimate but valid Google certificates, and alerted Google through its own channels. CT extends that to…

> Certificate Transparency is a solution CT would not have prevented these attacks. Google would be exactly where they are right now: knowing who issued cert, and that's it. Short form: https://github.com/okTurtles/dnschain/blob/master/docs/Compa... Long form: https://blog.okturtles.com/2014/09/the-trouble-with-certific... (EDIT: How about an honest discussion instead of a downvote? If you disagree, you are welcome t…

It is not downvoted (gray) any more.

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

#20
post #16

Earlier quoted context omitted.

> Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty that it wouldn't have prevented this attack. Every time you want to MITM a new site, you need to contact some number of auditors before you can complete the connection. 1. Certs don't need to include SCTs, so, end of story. 2. Even if that was a requirement, th…

2. Even if that was a requirement, they can be faked just like the certificate. Huh?

> Huh?

Read the post, it's all there: https://blog.okturtles.com/2014/09/the-trouble-with-certific...

Post reply on HN