Opened 6 years ago

Closed 7 months ago

#7553 closed enhancement (wontfix)

[simple patch] Expose ISO_STREAM via isolation flag config option

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.3.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, small-feature, maybe-bad-idea, needs-debate, review-group-34
Cc: adrelanos@…, arma, benjaminlincoln@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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?

  1. It's quite useful for managing a pool of long running connections, etc.
  2. 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.
  3. 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.

Child Tickets

Attachments (1)

IsolateStream.patch (1.4 KB) - added by cypherpunks 6 years ago.

Download all attachments as: .zip

Change History (20)

Changed 6 years ago by cypherpunks

Attachment: IsolateStream.patch added

comment:1 Changed 6 years ago by nickm

Keywords: tor-client added
Milestone: Tor: unspecified

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?

comment:2 Changed 6 years ago by proper

Cc: adrelanos@… added

Speaking 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.

comment:3 Changed 6 years ago by cypherpunks

Regarding 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.

comment:4 Changed 6 years ago by nickm

Cc: arma added

Hm. You might be right there. I think I should call in a second opinion. Roger, what do you think here?

comment:5 Changed 6 years ago by nickm

Status: newneeds_review

comment:6 Changed 6 years ago by nickm

Keywords: small-feature added
Milestone: Tor: unspecifiedTor: 0.2.4.x-final

comment:7 in reply to:  3 Changed 6 years ago by rransom

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.

comment:8 Changed 6 years ago by benjaminlincoln

Cc: benjaminlincoln@… added

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?

comment:9 Changed 6 years ago by cypherpunks

I 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.

comment:10 Changed 6 years ago by 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.

comment:11 in reply to:  10 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

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.

comment:12 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:13 Changed 2 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:14 Changed 22 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:15 Changed 17 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:16 Changed 17 months ago by nickm

Keywords: maybe-bad-idea needs-debate added
Severity: Normal

comment:17 Changed 8 months ago by teor

Milestone: Tor: unspecifiedTor: 0.3.4.x-final

Move all needs_review tickets without a release to 0.3.4

comment:18 Changed 8 months ago by nickm

Keywords: review-group-34 added

comment:19 Changed 7 months ago by dgoulet

Resolution: wontfix
Status: needs_reviewclosed

Seems consensus is: Bad idea and 5 years ago. If you disagree, open a new ticket.

Note: See TracTickets for help on using tickets.