[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-talk] Fwd: [Full-disclosure] tor vulnerabilities?



-----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.rowhoiser@xxxxxxxxxxx>
> To: "full-disclosure@xxxxxxxxxxxxxxxxx" <full-disclosure@xxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk