-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 the below text was posted to pastebin.com (see original e-mail to the full-disclosure list at the end of this message).
- ----- BEGIN PASTEBIN ----- Tor LOL: directory authorities are the point of contact for clients to locate relays/exit nodes/guard nodes/etc. This is determined by a consensus document that goes through an elaborate process to ensure its integrity and cause bad directory authorities to be identified also via consensus. However, Tor developers are not the quickest lot, and this is basically the only document that they serve that has integrity control on it. Most interestingly, the public keys for every other node in the network is served without any form of signature or other form of integrity control. As such, a rogue directory authority, which anyone can be simply with a configuration option and an IP, can introduce path bias and other such tricks by serving the wrong keys for relays/guards/exits that it doesnt control. This can result in essentially directing clients through the network by causing decryption failures, thereby allowing determination of the source and end-point of a given tor connection with little more than a couple relays and some rogue directory authorities. Moreover, it can use the simple-minded metrics made to identify rogue guard nodes and couple that together with the behavior of public key cryptography to actually cause legitimate guard nodes to be flagged as having excessive extend cell failures causing it ultimately to be marked as bad. As such, this entirely mitigates the half-witted fixes guard nodes were intended to fix, by introducing rogue guards that work in conjunction with rogue directory authorities, whom serve bad public keys for all nodes except for their own giving them the ability to cause clients to reconnect to guard nodes at their leisure. These are design flaws in tor. Don't outsource your security, especially if its to people like appelbaum and other incompetents. The fact is the US government doesn't need to backdoor Tor, they just get to let the dunces think their competent. - ----- END PASTEBIN ----- - -chl - -- cool hand luke > From: Neel Rowhoiser <neel.rowhoi...@outlook.com> > To: "full-disclos...@lists.grok.org.uk" <full-disclos...@lists.grok.org.uk> > Date: Fri, 28 Jun 2013 23:37:45 -0400 > Subject: [Full-disclosure] tor vulnerabilities? > > I just stumbled across this and despite its sort of half-assed write > up, I think its possibly an advisory? If I am understanding it > correctly, they're saying that you can use a directory authority that > hands out invalid/wrong RSA keys for other relays, you can cause > decryption to fail and thus introduce path bias to nodes of the > directory authorities choosing by selectively handing out valid RSA > keys? > > If the bit towards the end about guard nodes is correct, it would seem > to indicate that they can use the semantics for detecting when a guard > is causing too many extend relay cells to fail to cause valid guards > to be marked invalid, and their rogue guards to succeed essentially > using tor's semantics against them and causing the odds that you-re > ingress point to the tor network is rogue to approach 1. > > Why aren't the tor relay keys signed? And what other myriad of > documents do directory authorities serve that also don't have > integrity controls? This sort of makes me question the tor projects > ability to deliver on any of the promises they make, as it would seem > that a person needs like 3 or 4 rogue nodes before they could start > de-anonymizing users, and the more of them they introduced the more of > the network they could capture? > > What I ran across (pastebin-- source unknown) http://pastebin.com/pRiMx0CW > > Cheers, > Neel Rowhoiser > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQF8BAEBCgBmBQJRz0cHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RUE3NjY3OTY3NTE0RjAyMDgyRTNBQzAy QkE2NTVENTVDODgzNUVCAAoJECumVdVciDXruN4H/R83xaCN7Jq5NyMRP9wMR7nA n5Pzp+fqI9+bQF0lOYHfGPRR3hmK7z+VyazK/xwShFHh6olBbPIHhA1P1Z/Imw6V IKQNSDOLRZhUX0MkIHQaTfG4b/bz+j16m49wtXNaigxs6p/bxF7/4OvB5EOMunrX CTj2XTJ+QyERWwCO7U0CRWoz531sFAVt2Ao5D6daUlQuNmouOVB7alZskHzHLikY tpBEh6JyB+kZE4oM6uWdkEB9k7fUTJu2YCBOok2dUTif1+W57teCKsYaY9rD8MID /Z8Z20e1kIy523dOCXItX3mmxU/KBwptieUKNV06DsGkouipJ1BeLfS9TGie6QU= =ReQ7 -----END PGP SIGNATURE----- _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
