5 ms·
> Given the operational difficulty of implementing a transparently-MITMing proxy in a Certificate Transparency regime, I'm not sure you can say with certainty t
by itistoday2 12y ago
> 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, they can be faked just like the certificate.
> In any case, it is certainly not a perfect solution. But it is a solution.
It doesn't prevent MITM attacks (even Google acknowledges that), so it's not a solution (if preventing attacks is what you want).
> But the okTurtles scheme is much worse: if a certificate gets compromised, the only recourse is to pick a new website name.
Certificates are not associated with the key to modify the blockchain entry. So if a certificate gets compromised, you can immediately fix it by updating the blockchain entry.
> BTW: "Resist commenting about being downvoted. It never does any good, and it makes boring reading."
If people downvote me for no good reason, I'll point it out to them. Doesn't matter to me if it bores them. If that's a problem maybe they shouldn't downvote in the first place? :P
- skj 12y ago> 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.
- itistoday2 12y ago> 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.
- geofft 12y agoI 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 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.
- itistoday2 12y agoWhen 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 projects by writing about them, podcasting, tweeting, blogging, contributing code, etc. https://github.com/okTurtles/dnschain#community https://github.com/okTurtles/dnschain#community This certainly requires community support.
- geofft 12y agoI'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.
- itistoday2 12y ago> 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.
- tptacek 12y agoFWIW: yes, that's Greg Slepak.
- yuhong 12y ago2. Even if that was a requirement, they can be faked just like the certificate. Huh?
- itistoday2 12y ago> Huh? Read the post, it's all there: https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/ https://blog.okturtles.com/2014/09/the-trouble-with-certific...
- yuhong 12y agoLooks like a complex attack, and "not all CAs will necessarily have their own log." and same for the converse too.
- itistoday2 12y agoLegitimate 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 https://news.ycombinator.com/item?id=9254713
- yuhong 12y agoYes, CT would only allow detection. Revocation would be a different problem.
- geofft 12y ago> 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) is pretty much irrelevant in this type of attack since the MITM either can order CA/log combos to do what they want, or they own and operate one of the 1200+ CAs out there (in a clandestine operation), or they’ve hacked their way into obtaining the CA/log private keys they need to conduct mass-surveillance on any website they want (undetected)." The words "can order" are linked to a page about national security letters. It's true that CT does not protect you against an arbitrarily misbehaving hegemonic government, but if that's in your threat model, a lot of security analyses fly out the door. In this particular case, though, the malicious actor was not a government, so we can rule that one out. (Much as the Chinese government is an attractive target of blame, in this case, it seems like the misissuance was from a private corporation in Egypt. CNNIC voluntarily reported the issue to Mozilla; though it's unclear if Google alerted them first, clearly there was no governmental intention to MITM here.) 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 argument. So that leaves "they’ve hacked their way into obtaining the CA/log private keys they need to conduct mass-surveillance on any website they want (undetected)". Assuming we're talking about "log" here out of "CA/log", then, first, this significantly raises the bar to an attack. This particular attack was done because a non-CA entity asked a CA to sign an intermediate, and lied to the CA about how it would be used. No hacking was involved. In order to conduct the same attack in a CT world, the entity would also have to set up their own log and get it trusted (who would trust it?), or ask the CA for the CA's private key (which would be a "no, and please stop being our customer"), or hack into the CA. Second, that presupposes that the CT site's claim that log misbehavior is detectable is untrue in a fairly major way. (This is a reasonable claim to make, I'm just trying to figure out if that's the claim you're making.) In any case, I don't see an argument that it can be faked just like the certificate. It's significantly more work, and involves suborning a legitimate log. Faking a certificate merely involves abusing an intermediate, which is a product that (unfortunately) gets sold for legitimate use, on trust. That trust cannot be abused to generate an SCT the way it can be abused to generate a signed certificate. > It doesn't prevent MITM attacks (even Google acknowledges that), so it's not a solution (if preventing attacks is what you want). It prevents some MITM attacks, by disincentivizing them or making them logistically complicated. It does not prevent all of them. It is not a perfect solution, but it is a partial and pretty good solution. I said in my initial post that it's not my favorite solution, but it's my favorite realistic solution. In particular, CT would have completely prevented this attack.