[simple patch] Expose ISO_STREAM via isolation flag config option
This patch exposes ISO_STREAM as a torrc isolation flag IsolateStream, along with what I think is a very convincing warning in the manpage against general use. So why this option?
- It's quite useful for managing a pool of long running connections, etc.
- I remember some project (a part of Tails? Whonix? not sure) rigging up something inferior by generating unique Socks credentials for each request, which is messy and doesn't work for TransPort.
- Since ISO_STREAM is already used internally, nothing beyond adding the config option was needed for this super simple patch.
Testing with wget check.tpo showed it to work as expected here.
Activity
changed milestone to %Tor: 0.3.4.x-final
Trac:
IsolateStream.patch
Interesting!
I am worried about increased load on the relays if many people start using this. (What do Tails/whonix/whoever actually use this for? If it's something that a lot of people actually use, they might be DOSing the network.)
Right now, the load for circuit creation requests is pretty high, and that's actually making success rate seems to be less than we'd like. I wonder if it would make sense to take some action to try to mitigate that problem here, either by having this feature be off by default, and need to get enabled at compile-time ; or to rate-limit the number of circuits it would create.
That said, it does have applications, and I'd like to see it go in if we can come up with a good answer here. Would you prefer credit as "cypherpunks" or some other name?
Trac:
Keywords: N/A deleted, tor-client added
Milestone: N/A to Tor: unspecifiedSpeaking for Whonix:
Applications are stream isolated. If they are not used, there will be no traffic.
rigging up something inferior by generating unique Socks credentials for each request
Only per application and some SocksPorts with reasonable IsolateDestAddr and/or IsolateDestPort options.
Sources: Whonix torrc; source code; stream isolation design
Not speaking for Tails, but linking:
https://tails.boum.org/todo/separate_Tor_streams/
Don't ask me for the related Tails git commit.
rigging up something inferior by generating unique Socks credentials for each request
I don't think they do that either.
My general option about this feature:
Nice, if the network can handle the load. Those are pretty geeky options, I don't think users bother with it and the abusers can already hack together their own ISO_STREAM feature so not adding the feature isn't a protection either. The Gini Is Out Of The Bottle.
I wouldn't activate it in Whonix for anyone else by default.
Trac:
Cc: N/A to adrelanos@riseup.netRegarding who exactly it was that randomizes Socks credentials: After converting the last 12 months of tor-talk to maildir and grepping like the wind, can't say i've found it so far :\
The only way I can think of this turning into a DDOS of the Tor network is if lots of people inexplicably start using it for their browsing, but the speed alone should deter anyone right away. I just phrased the manpage warning so harshly to err on the side of caution.
Rate limiting, if it's really necessary, would have to take into consideration that the very use of this feature (well, one use case) is spawning, in parallel, a dozen or so independent low-throughput TCP connections that stay open for a long time. There are probably a few geeks out there already making do with something to the effect of
for x in ... dostuff & newnym
where, if they're also doing their browsing on the same tor instance, the newnym will waste perfectly fine circuits. IsolateStreams would actually be easier on the network here.
A compile time flag, well I see your reasoning, but isn't there the chance it turns a homely feature into the forbidden fruit for a certain type of person? It's not quite like tor2web-mode where the number of people with a legit use for it is in the single digits.
Re credit, any or none is fine.
-
Hm. You might be right there. I think I should call in a second opinion. Roger, what do you think here?
Trac:
Cc: adrelanos@riseup.net to adrelanos@riseup.net, arma Replying to cypherpunks:
A compile time flag, well I see your reasoning, but isn't there the chance it turns a homely feature into the forbidden fruit for a certain type of person? It's not quite like tor2web-mode where the number of people with a legit use for it is in the single digits.
The tor2web mode feature can only harm people who use it. This ‘feature’ is an attack on the Tor network.
Discussion of this topic at tor-dev:
https://lists.torproject.org/pipermail/tor-dev/2013-January/004355.html
cypherpunks, could you please comment over there?
Trac:
Username: benjaminlincoln
Cc: adrelanos@riseup.net, arma to adrelanos@riseup.net, arma, benjaminlincoln@lavabit.comI don't know, I feel like everything has been said. I disagree on the probability of this feature being used to slow down the network, especially with the severe manpage warning, but the maintainers are in a better position to judge that.
For me it makes little difference, I use a source-based distribution with the diff dropped into my package manager's patches/ directory, so that every time I install a new version of tor, it's included automatically. For what it's worth, it's working exactly like it should. But of course I'd love it if this two-liner contribution was included in the main code of Tor, my favorite open source project.
-
Replying to arma:
I admit that I'm not cheerful about this one. It's true that people can hack it into their Tor. But if we don't want anybody doing it, we should leave it out of the default Tor. At least until the Tor network doesn't suffer so much from circuit creation overload.
Okay; bumping this from 0.2.4, for reconsideration in 0.2.5 once we see how the circuit creation load stuff looks then.
Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final moved to tpo/core/tor#7553 (closed)
