31–40 of 76 posts
I've always had the suspicion that my pc had some sketchy certs installed.. what do ya expect from buying a pc with an OS installed from an electronics retailer..right?
Earlier quoted context omitted.
In my opinion, web browser extensions are not a viable way to deploy the solution to this problem. As far as I can tell, DNSChain has no buy in from web browser vendors. That makes it undeployable. It is irrelevant (or not very relevant) that it would take less effort than CT for Google. What is relevant is that Google is willing to implement CT, and not willing to implement DNSChain. Yes, this has nothing to do with…
> In my opinion, web browser extensions are not a viable way to deploy the solution to this problem. As far as I can tell, DNSChain has no buy in from web browser vendors. That makes it undeployable. One of the reasons why browser vendors are having a tough time actually fixing this problem is because CAs make a lot of money off of selling SSL certificates. We're working to remove obstacles out of their way by making…
Earlier quoted context omitted.
> 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.
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 thought DNSChain was a good idea, but I've only ever seen one person evangelize this concept (in email, on the website, and now in HN comments). As general advice, if you try a bit harder to respect the conventions of the fora you use to evangelize things, no matter how reasonable or unreasonable you think the conventions are, you're likely to win more hearts and minds.
And you do want to win hearts and minds, don't you? Either you want this problem to be solved (and you have the perfect solution, if only people would listen), or you don't.
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. I'm trying to understand how this works. (If they can be faked, then yes, that's fatal for CT, but I don't think the CT proponents acknowledge that, so either someone is very wrong, or the truth is subtler than that.) The okTurtles blogpost, in the section about the first "inaccurate" claim, says, "The SCT (signed certificate timestamp)…
Being a CA (that has a log) allows you to have two different merkle trees (one for secret MITM, the other for ordinary uses), as explained in the post. That is where even detection gets questionable.
But as also mentioned further down in the post, the attack will probably be simpler than that (identical to today's attacks). These attacks might be "detectable" after they've happened, but so what? So was this one. Damage will have been done.
> In particular, CT would have completely prevented this attack.
No, it wouldn't have, not even if SCTs were mandatory.
All the attacker has to do is send the cert to a log, and all CA-signed certs are accepted, so they would have gotten their SCT without any trouble at all. After some time, Google might query the log that it was sent to and discover the SCT and raise the alarm, but again, damage will have been done, and it's even possible that the MITM will prevent any fixes from making their way to the victims.
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…
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 projects by writing about them, podcasting, tweeting, blogging, contributing code, etc.
https://github.com/okTurtles/dnschain#community
This certainly requires community support.
Earlier quoted context omitted.
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...
Earlier quoted context omitted.
> Huh? Read the post, it's all there: https://blog.okturtles.com/2014/09/the-trouble-with-certific...
Looks like a complex attack, and "not all CAs will necessarily have their own log." and same for the converse too.
Earlier quoted context omitted.
In my opinion, web browser extensions are not a viable way to deploy the solution to this problem. As far as I can tell, DNSChain has no buy in from web browser vendors. That makes it undeployable. It is irrelevant (or not very relevant) that it would take less effort than CT for Google. What is relevant is that Google is willing to implement CT, and not willing to implement DNSChain. Yes, this has nothing to do with…
> In my opinion, web browser extensions are not a viable way to deploy the solution to this problem. As far as I can tell, DNSChain has no buy in from web browser vendors. That makes it undeployable. One of the reasons why browser vendors are having a tough time actually fixing this problem is because CAs make a lot of money off of selling SSL certificates. We're working to remove obstacles out of their way by making…
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…
1) list the root auths I have installed per browser
2) give me an idea of where they are relevant
3) let me deauthorize them?
Earlier quoted context omitted.
> 2. Even if that was a requirement, they can be faked just like the certificate. I'm trying to understand how this works. (If they can be faked, then yes, that's fatal for CT, but I don't think the CT proponents acknowledge that, so either someone is very wrong, or the truth is subtler than that.) The okTurtles blogpost, in the section about the first "inaccurate" claim, says, "The SCT (signed certificate timestamp)…
> 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…
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 want to MITM a specific site for a specific user for a short period of time, and CT may not solve that. It may be the case that no certificate-based system can solve that, because those attackers will prefer spear-phishing the user into downloading malware to reconfigure their browser. But this particular attack was not such a case.
What went (somewhat) wrong here is that the attacker believed that they could get away with it for quite some time, because the mechanism by which Chrome tattles on illegitimate certificates is proprietary and not well-understood as a part of the system. I suspect that if the attacker knew that this would not work for more than, say, a day, then they would have chosen a different, less-attacky route to solve their actual problem.
(Besides, the Palo Alto device would not have actually sent certs to a log. The attacker would have had to write their own MITM proxy, which is a tricky business. That rules out some but not all actual attacks, and if our metric is what actual attacks are prevented, then that counts for something.)
> All the attacker has to do is send the cert to a log, and all CA-signed certs are accepted, so they would have gotten their SCT without any trouble at all.
I concede that that is true; I implied otherwise because I didn't think hard about that part. Thanks.
> After some time, Google might query the log that it was sent to and discover the SCT and raise the alarm
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. (Remember that in this case, the customer lied to the CA and said it would only be used for sites the customer had control over.) I could easily imagine that, in a SCTs-are-mandatory world, it's also mandatory for CAs to run this little shell script if they want to be allowed to sell intermediates. It's just a technical formalization of something that's already in the Baseline Requirements.
> it's even possible that the MITM will prevent any fixes from making their way to the victims.
That's certainly an interesting problem and I haven't seen much discussion of it.
Is it possible to configure the browser to fail closed if it hasn't reached its update server within some period of time? 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?
What's DNSChain's solution here? Can a MITM pretend that the blockchain hasn't moved in a few weeks?