Tails

#1 Updated by anonym 2015-03-31 14:49:24

> Does our current circuit isolation setup allow us to safely do the same globally?

Let’s look at our current configuration:

## Defaulut SocksPort
SocksPort 127.0.0.1:9050 IsolateDestAddr IsolateDestPort
## SocksPort for the MUA
SocksPort 127.0.0.1:9061 IsolateDestAddr
## SocksPort for Tails-specific applications
SocksPort 127.0.0.1:9062 IsolateDestAddr IsolateDestPort
## SocksPort for the default web browser
SocksPort 127.0.0.1:9150

So, let’s assume that the Tor Browser people have correctly analysed the implications of raising MaxCircuitDirtiness like that for Tor Browser 4.5, and then try to argue that our stream isolation configuration is at least as strong, or something like that. So, Tor Browser 4.5 “isolate[s] all requests from the same url domain”, which is strikingly similar to IsolateDestAddr. The key thing is to determine how they relate to each other (also versus their respective contexts, i.e. only in the browser vs. for all applications), but for now, let’s assume they are the same. Then we’re fine, except for 9150, but only users that explicitly configure some application to use this SocksPort would be affected. We could document that it shouldn’t be done, but I doubt it would be read. I think we’ll have to live with that risk until we run the browser as a separate user, and then we can solve it with iptables/netfilter rules.

Next I’d like to make the point that any attempt at identity separation for accounts on the same service based on the lifetime of Tor’s circuits is very weak. The default of ten minutes is already plenty for users to screw up if they don’t take precautions and e.g. force a new identity through Torbutton or Vidalia (or restart Tails, as I believe we recommend). I doubt bumping the MaxCircuitDirtiness above ten minutes has much implications for this — a user that has ignored our docs is impatient and should be expected to switch identity without delay (or even use them concurrently). Actually, I don’t think any technical solution will be effective for this problem; perhaps I’m going too theoretical, but the pattern of logging in for a while to some account A, and then logging in to an account B (same service) with a new Tor circuit gets pretty obvious over time.

Am I missing something here? Why do we want short circuit lifetimes? On the face of it, longer circuit lifetime => fewer circuits are used in total => lower chance to use a compromised circuit, which is a good thing.

Any way, I still think there’s value in comparing the “isolate all requests from the same url domain” in the Tor Browser context with IsolateDestAddr in all applications’ context. To me they look the same. Any other opinions? Otherwise I’d say we might go for it.

#2 Updated by intrigeri 2015-04-01 12:34:58

As said to anonym already, there’s been more discussion upstream:

• https://trac.torproject.org/projects/tor/ticket/13766
• https://trac.torproject.org/projects/tor/ticket/15482
• the https://lists.torproject.org/pipermail/tor-dev/2015-March/008548.html thread

… and as anonym noted then, apparently they’re going with patching little-t-tor :(

#3 Updated by intrigeri 2015-04-25 05:52:32

Tor Browser 4.5 is almost out of the door, and AIUI it indeed patches little-t-tor. I think this should be treated with high priority now.

#5 Updated by anonym 2015-04-28 11:31:46

anonym wrote:
> I’ve built such a patched Tor and uploaded it to the feature branch, and I’m gonna run the relevant parts of the automated test suite. To be continued…

For my manual tests of the expected new behaviour of Tor with this patch applied, I ran this silly code:

while true; do
  curl --socks4 127.0.0.1:9150 --proxy-user $USER:$PASSWORD https://check.torproject.org 2>/dev/null | \
    sed -n 's,^.*Your IP address appears to be:  <strong>\([0-9\.]*\)</strong>.*,\1,p' || \
    echo "fail"
  sleep 60
done

I ran two instances, one with --proxy-user and one without, and the results were as expected; the one with it reported the same exit node (and hence very likely the same circuit — I only verified that the exact same circuit was used at the start and end of my test) for the full hour I was running the test, and the one without switched every 10 minutes.

As for automated tests, I ran tor*.feature successfully except that the bridge and gobby tests fail, as expected.

#6 Updated by intrigeri 2015-04-29 07:19:02

> The biggest issue is that it applies this new behaviour whenever a SOCKS username and/or password is set to all SocksPorts, not just the browser’s SocksPort. OTOH, we do not use stream isolation based on SOCKS username/password ourselves,

I hope we don’t have to use SOCKS user+password ourselves in the future. If we do, then we should lobby for the upcoming Tor option to be available as an isolation flag (that we could enable for our dedicated Tor Browser SOCKS port only), rather than as a global torrc option.

> so we’d only have to worry about users that actually know about this rather arcane Tor stream isolation feature and configures it for some application.

Users… and applications! Note that things like parcimonie may soon start using SOCKS user+password, so they’ll be affected too. However, they’ll be using it to force new circuits, so there should be no problem in practice.

> and I fail to see why that would be a problem (see my reasoning in Feature #9114#note-1).

I wasn’t convinced when reading it initially (if a longer default circuit lifetime was that innocuous, why isn’t tor setting the default to a higher value?), but it seems to be a detail given where we’re heading to, so I won’t spend more time on it now. We’ll come back to it if we really have to.

> (Spoiler: I think we should apply bug15482.patch to our Tor.)

After reading https://trac.torproject.org/projects/tor/ticket/15482 and corresponding discussion on tor-talk, I fully agree… especially given an upstream solution is being worked on, and has good chances (I guess) to land some day.

#10 Updated by intrigeri 2015-04-30 08:09:14

> Interesting post about this made by Roger: https://lists.torproject.org/pipermail/tor-talk/2014-October/035219.html

Indeed, that’s interesting. The “ten minutes is probably way too long” point probably doesn’t affect us much, given our circuit isolation configuration.