4 ms·
> certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time. In what sense is this true? They're
by cjbprime 7y ago
> certificate transparency logs appear to be completely ineffective in catching CA-related name hijack events in real time.
In what sense is this true? They're effective because browsers only accept certs which can first prove that they were submitted to a CT log, and it's easy to search the CT logs for e.g. gmail.com to find potential misissuance events.
This is the first time I've heard CT described as ineffective. What gives?
- tptacek 7y agoHuston has re-set the bar at "real-time", and implies that DANE would provide such real-time assurance, when in fact even DANE advocates acknowledge that, were DANE to see wide use, we'd need to develop a DANE equivalent of CT.
- cjbprime 7y agoI guess I don't even buy that CT is ineffective in real-time. If attacks don't happen because of the knowledge that misissuance would necessarily be publicly noticed and then severely punished, then it seems your users have been protected against real-time attacks, even if that's an emergent social phenomenon rather than a protocol guarantee.
- agwa 7y agoIt's unclear what Huston means by "real time", but in the comments section he cites the fact that it took 6 months for the misissued Symantec certificates for example.com to be noticed. That's because the owner of example.com wasn't monitoring CT. Had they been monitoring, they would have been alerted quite quickly. As a case in point, when Certinomis misissued a certificate for test.com, my monitor notified me 16 minutes after issuance, I filed a report with Mozilla two hours after issuance, and a representative of Mozilla responded less than 3.5 hours after issuance.[1] That's pretty fast. And now Mozilla is kicking Certinomis out, providing yet another example of how CT is improving the Web PKI. CT works. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1496088 https://bugzilla.mozilla.org/show_bug.cgi?id=1496088
- rurounijones 7y agoThat was really interesting to read. As a relative layment in this area. Do you have any recommendations on reading material in this area? How is your monitoring setup?
- tialaramex 7y agoAn earlier edit of your post seems like you didn't understand enough about how X.500 Distinguished Names work to search the DNs (presumably in crt.sh) so learning about that might not be time wasted if you care what's inside a certificate other than domain names. Be warned that although the CAs are required by CA/B rules to get most of those other details right when they're included there is limited appetite for enforcing such a rule. There are Google Groups (because a lot of this is a Google project or spins out of Google projects) for a lot of this, including mozilla.dev.security.policy (the public discussion of Mozilla's root trust store policy), certificate-transparency (general discussion of CT) and crtsh (discussion of Rob's crt.sh monitor database and site). They're all usually quiet enough that you could read back a few months and/or subscribe and have them in your background.
- rurounijones 7y agoYes, sorry abut the edit, I thught I was quick enough to ermove it before anyone read it as I figured out what I was doing wrong. Thank you very much for the links.
- agwa 7y agohttps://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/ https://blog.cloudflare.com/introducing-certificate-transpar... is a very good overview of Certificate Transparency. I've written my own Certificate Transparency monitor called Cert Spotter. I use both the standalone open source version (https://github.com/SSLMate/certspotter https://github.com/SSLMate/certspotter) and the hosted service (https://sslmate.com/certspotter https://sslmate.com/certspotter) to monitor my own domains as well as several test/example domains (example.com, test.com, etc.).
- hannob 7y agoHe doesn't understand what CT does. Yeah, it's technically true that CT isn't designed to directly prevent most attacks. THe largest effect of CT is that CAs get pressured to get their stuff in order. It has been a major milestone in improving the ecosystem, particularly because it also led to many real distrusts, including of one of the largest CAs at all (Symantec). Yes, CT doesn't try to prevent most attacks directly. It tries to create an ecosystem where CAs fear getting distrusted when they don't prevent attacks in the first place. And it works very well.
- pjf 7y agoIn practice I found new certs being available for download from CT logs hours after they've been issued. This is more than enough to perform an attack. Another point is that CTs alone won't prevent the attacks nor inform you about a problem - they need a monitoring system. (yes I know that's not the problem with CT - it's great, just trying to justify a strong opinion of "it doesn't work")