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

Re: [tor-talk] Risk with transparent proxy mode [was Re:Operating system updates / software installation behind Tor Transparent Proxy]




>coderman wrote:
>On Sat, Mar 3, 2012 at 12:33 AM,  <proper@xxxxxxxxxxxxxxx> wrote:
>>...
>> Application level leaks are problematic. We have a page which describes many of these problems i>ncluding with workarounds (we recommend Tor Browser etc.).

>these are significant if you are mixing tor and non-tor access on the
>same system. much of this is covered in the thread, and the particular
>risks are very specific to context and nature of use, as discussed.

Precisely why we don't do allow (try at least) any communication from the system to 
bypass Tor.


>> The transparently proxied operating system does not know it's real external
>> IP, only it's Tor exit IP. >>And can therefore never leak it's real external
>> IP. ... DNS / UDP leaks are impossible. Real IP may also not leak, the 
>>operating system doesn't have a way to find it out.

>this is not true; you must also prevent all local subnet access when
>in this mode. this may entail removing IPv6 interfaces, changing the
>default route to a /31 or /30 path, etc.

>otherwise there are attacks which reflect or bounce traffic on the
>local network to obtain public IP address or leak endpoint to an
>attacker.

We already learned about this in [1] and discussed it on our Dev page [2]
(and wondered why you said /29 and not /31). Could you provide us with some
pointers how such an attack would work against the currebt TorBOX setup?

To quickly outline TorBOX:
Client is connected to Proxy through a virtual "internal" network. No dhcp, no
IPv6, no route to physical devices or the internet. It got a static IP, no firewall 
active. The Proxy has two NICs, the external one is managed by VirtualBox dhcp
and NAT. Firewall can be found at [3]. All allowed traffic from the client is
redirected either to TransPort or to DNSPort. 

The "bare metal" setup would be: client - crossover or isolated LAN -
- proxy  - (...) - internet.

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. If iptables is
doing something funky with tcp packets to 169.254.0.0/16,
that's a serious bug in netfilter. What am I missing?

[1] http://archives.seul.org/or/talk/Jul-2010/msg00012.html
[2] http://archives.seul.org/or/talk/Jul-2010/msg00012.html
[3] https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/ShellScript
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk