On 2012-03-01, proper proper <pro...@secure-mail.biz> wrote: > I was told, to ask this question here. [3] > > Tor's transparent proxy feature is at the moment a bit complicated to take > advantage off and therefore unpopular. That might change in the future, > because a) documentation improves [1]; b) in the future (depending on the > outcome of this bug) there might be per-configured, ready-to-use packages; > c) you discussed to give TorRouter such a feature #3453 [2] as well.
Jacob Appelbaum is the one that wanted a transparent-proxy client feature in the ‘Torouter’ (and enabled by default for an unsecured wireless network). He gave at least three reasons for it: * It would allow/encourage people who buy the ‘Torouter’ (or whatever name it would have ended up with) to provide a public wireless access point, even if their ISP would not permit them to do so or would punish them for their neighbors' misbehaviour. (This reason was not met with enthusiasm.) * It would allow people who own a Torouter and some other special-purpose device which cannot run a Tor client itself (he gave the Chromebook as an example) to route their traffic through Tor. * It would protect people who own a Torouter and route their traffic through it against traffic logging by their ISP. None of these uses are able or intended to anonymize user traffic, but the latter two do justify the existence of a transparent-proxy client feature. > You ask the user not to use Bittorrent over Tor, as the network can not > handle the load. BitTorrent clients ‘seed’ over Tor, too. That eats rather more bandwidth than just downloading a file over Tor. But it's not just bandwidth load. BitTorrent clients open many TCP connections, and frequently close them to switch to another destination; the open TCP connections chew up TCP port numbers on your exit node, and switching to new TCP connections will spread the traffic load over many Tor circuits, so you'll break what little rate-limiting the Tor network can impose *and* hose more relays and exits with traffic and TCP connections. And the jerks who use Tor for copyright-infringing torrent traffic (or even just to connect to the tracker for a copyright-infringing torrent) get their exit nodes' hosting providers flooded by fake-DMCA-notice spambots. That can get exit nodes shut down, thereby reducing the Tor network's capacity significantly. > What about operating system updates behind a Transparent Tor Proxy? The same > goes for the installation of legitimate software. No warez. "apt-get install > gnome" GPG sucks, so apt sucks too. apt-get has the decency to only download over a small number of parallel connections, and not upload, so it shouldn't eat as much bandwidth as BitTorrent. I'm more worried about the risks to user anonymity. It sucks to be the user reading about some sensitive subject when your apt cron job decides to poke every package source you install from. “Oh, that guy who keeps reading about Foozer's Disease must be in the Antarctica/McMurdo time zone!” > The transparent proxy feature is great, it offers to reduce the risk of > leaks and offers an anonymous torified operating system. Operating system > updates behind Tor are a dilemma. It's several hundred of megabytes. It's probably not anonymous. Tor's goal is to provide unlinkability between the source of a connection and its destination. Tor Browser Bundle and Tails aim to provide unlinkability at destinations between connections from a single source. Anonymity requires the latter property. Of course, if you want to link your connections together, you certainly can -- I log into GMail over Tor using a username and password linked to my real name and to a location where I live. I'm not anonymous, nor even pseudonymous, but Tor still prevents GMail from determining my current location. An operating-system installation which was set up without Tor, then stuck behind a Tor transparent proxy, receives location privacy from Tor. If the person who set up that system was careful to turn off all the automatic network operations that could otherwise make a system's traffic identifiable, the system could even be anonymous. You aren't likely to get there from a Debian or FreeBSD system without serious effort. I don't think it's possible at all with Windows. > Once users have an anonymous torified operating system, they use > "apt-get upgrade", they won't bother with offline updates, as they > are complicated and possible leaks (creates signature). ‘apt-get upgrade’ should be fairly well-behaved for a bulk-download client. Sucks that ‘apt-get upgrade’ tells your exit node what Debian mirror you installed from and what updates you want to install. Sucks that the apt cron job told the exit node that you were reading about an embarassing medical condition through what Debian mirror you installed from and what time zone your VM is set for. Anonymity is hard! Let's do crypto. > So what do you suppose to do with the Transparent Proxy feature? How do you > want to solve the operating system update dilemma? Can the Tor network > handle the load? > > Resolutions possible: > a) Propose a solution. (That sounds like politician-speak.) Use Tor 0.2.3.x-alpha, give the user 10 or more SocksPorts and 10 or more DNSPorts to point things which really need to be anonymous at, and no TransPort. In the VM you're trying to ‘anonymize’, run 10 or more transparent-proxy-through-SOCKS stubs (one for each user ID in which you run a non-SOCKS-friendly application that you want to ‘anonymize’), and set up iptables rules. > b) Leave it complicated, a nice addon for power users only. Using a SocksPort safely is complicated. If you couldn't bother to SOCKSify an application's source code properly, did you audit it for all the possible information leaks that could nuke what little anonymity you had left after the cron jobs? > c) Encourage people to extensively use it. Let's not. It's bad enough that the GlobaLeaks clowns are telling people to point a Windows application SOCKSifier at their feet and pull the trigger. > d) Leave the situation as it is. Tell me, not to release a easy > per-configured package for an anonymous torified operating system. s/anonymous // You can prevent a system from making non-Torified connections without having to mash all of its traffic into the same Tor ‘identity’ with a single transparent proxy. > e) Remove the TransPort feature, make it even more complicated to use. So we > have to use transsocks again if we really want. Sounds like a good piece to split into a separate program, but splitting Tor's link protocols into separate processes is more immediately important. > f) Propose more, better solutions. (That sounds like politician-speak, too.) I'm all for auditing more applications, and then SOCKSifying them properly, so no one will need a transparent proxy. > rransomsaid [3]: >> Operating system updates over Tor are the main reason that >> transparent proxying is not recommended -- automatic update >> installers are likely to leak information about the software they >> are trying to update, whether due to malicious design or due to >> lack of consideration for users' location privacy. > > proper: This is the reason why we want to make them over Tor. Those > information would stay anonymous. The reason not to do them over Tor is the > network load as described above. No. See above, and see my reply to Andrew's message. > rransom said [3]: >> Also, this is not a ‘defect’, ‘critical’, or an issue to be addressed by >> changing ‘Tor Client’. Try tor-talk or IRC. > > proper: I think it is. Solution e) would be handled by Tor > Client. That ticket was a user support question, and did not belong in Trac. It was not a ticket about removing Tor's built-in transparent proxy support (or splitting it into a separate process). (I think it's too early to file such a ticket.) > If someone were to promote an easy-to-use per-configured > anonymous torified operating system, this could (I don't know, > that's why I ask here.) overload the network. This someone could be > me. I won't do it if you tell me not to do it, because I don't want > to kill the network I use. And someone else is probable not up to > it. The demand for such as thing is there, but no one started > working on it for years. Most of the people who were ‘up to it’ considered other tasks more important than developing an easy-to-misuse transparent proxy kit, and/or did not consider themselves qualified to make a transparent-proxied system (other than possibly Tails) ‘anonymous’. (I no longer think I'm capable of setting up an anonymous Debian system using a transparent proxy. Fortunately, I never got around to that back when I did think I was capable of it.) Robert Ransom _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk