On Sat, Mar 3, 2012 at 3:54 PM, Hggiu Uizzu <torbox...@yahoo.com> wrote: >. > We already learned about this in [1] and discussed it on our Dev page [2] > (and wondered why you said /29 and not /31).
some operating systems (Windows) do not support /31 host-to-host interface configurations. in which case, a /29 two host subnet achieves the same result (forcing all remote traffic through default gateway, transparent proxy port in Tor in this case. > Could you provide us with some > pointers how such an attack would work against the currebt TorBOX setup? >... the setup looks fine from a cursory check, but i would need to give it a run to know. the concern with local network access is primarily at the client. an insecure configuration would look like: client(physical) eth0 192.168.1.100 and localrouter(physical) via eth0 at 192.168.1.1 virtual torbox at 168.16.1.1 via eth1/tun0 (virtual device) and client using 168.16.1.100 virtual torbox outgoing bridged to eth0 using 192.168.1.102 using second device. in this case, even if client was routing all internet access through 168.16.1.1 virtual torbox, it could still be compelled to send TCP or UDP traffic to the 192.168.1.1 and other hosts on the network. such reflection off internal hosts can compromise your anonymity. > The "bare metal" setup would be: client - crossover or isolated LAN - > - proxy - (...) - internet. cross over / isolated LAN is the key part here. if you share same LAN between client and internal network, hosts within that internal network can be leveraged to leak. > If Tor is doing something funky with packets sent to those ports instead of > routing them through the Tor network that's a serious bug in Tor. the transparent proxy ports (TCP and DNS) work great in Tor. it is the routing configuration between the client and these ports which is of concern. _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk