Stream isolation of different apps in Orbot VPN mode

[e3b]

It appears that Orbot (at least when running in Apps VPN mode) does not isolate the traffic of apps, i.e. relaying it to different exit nodes; multiple (even all?) have the same public IP address . At the same time Orbot obviously can do stream isolation when an app is properly configured (like Orfox) and the traffic of each app can be handled separately by the VPN.

Am I correct? What needs to be done to implement per-app stream isolation in Orbot?

[n8fr8]

I rhink if you enable the "IsolateDestAddr" feature in torrc, this would create unique streams per destination address. If we expect apps to connect to unique back end addresses, this would achieve your gal.

https://www.torproject.org/docs/tor-manual.html.en

"IsolateDestAddr Don’t share circuits with streams targeting a different destination address."

[e3b]

Thanks, I will try it out. But I believe IsolateDestAddr is enabled by default. And that would depend on apps having unique IP addresses. I doubt that is the case. Sorry, I misread.

I tried to add SocksPort 127.0.0.1:9050 IsolateDestAddr, but then Orbot wouldn't connect.

But even if it did work: https://tails.boum.org/contribute/design/stream_isolation/

[n8fr8]

I tried to add SocksPort 127.0.0.1:9050 IsolateDestAddr, but then Orbot wouldn't connect. Perhaps, because that conflicts with the existing default socks port. You can change the default socks port in the Orbot settings, and then try again with yours.

As for the TAILS link, yes there is performance impact... every app going through the VPN will have its own circuit.

[ghost]

Mr. Freitas and Orbot collaborators. I have no doubt you're very busy with plenty, but I must advise that you consider this to be a privacy vulnerability.

The Tails link provided by e3b references the notion that when different kinds of network traffic go through the same circuit together, they can be correlated.

Let us take a look at the Tor browser design documents to get an idea of how they might want this situation handled: http://jqyzxhjk6psc6ul5jnfwloamhtyh7si74b4743k2qgpskwwxrzhsxmad.onion/projects/torbrowser/design/index.html.en (#identifier-linkability and #philosophy) From "Tor circuit and HTTP connection linkability," the authors and engineers of the Tor project write,

Design Goal: Tor circuits and HTTP connections from a third party in one URL bar origin MUST NOT be reused for that same third party in another URL bar origin.

Implementation Status: The isolation functionality is provided by a Torbutton component that sets the SOCKS username and password for each request. The Tor client has logic to prevent connections with different SOCKS usernames and passwords from using the same Tor circuit. Firefox has existing logic to ensure that connections with SOCKS proxies do not re-use existing HTTP Keep-Alive connections unless the proxy settings match. We extended this logic to cover SOCKS username and password authentication, providing us with HTTP Keep-Alive unlinkability.

They write a series of bullet points referencing items that they isolate "in scope to the first party URL bar domain." We see that the authors and engineers of the Tor project understand that linkability and correlation of network activity is threat to user privacy that they would want handled. In response, they designed their system to intentionally split into circuits by a meaningful barrier they had present: url bar domain / referer.

Another application example: torsocks. torsocks -i /bin/application; will isolate based on the PID.

Orbot currently doesn't offer by app isolation.

If we expect apps to connect to unique back end addresses, this would achieve your goal.

This is an unreasonable expectation.

Consider the following: A user uses an Android OS that does not use google play store and google play services. Maybe it only connects to Google via DNS (8.8.8.8) and to update the time. The user is running Orbot with isolation based on address and port. The user installed Aurora store. The user installed a few apps and used them. Many apps may use development SDKs, including code from Google, Facebook, advertisers, and others. Such applications will most definitely make connections to Google or Facebook or to various advertisers or to any providers of a login provider (example: "Login with Google").

Although the apps aren't sharing data through IPC to cross correlate your identities across each application, said smartphone is now at risk of having the entire device being correlated with the data from all of the apps, because we now have network connections for {time, app 1, app 2, ...} all joined together.

If you consider this to not be an unreasonable threat, then we should implement this isolation. Perhaps even by default, with a flag to disable it.

The Android APIs allow us to determine which application has sent a request, and thus we could apply a different SOCKS username and password for each. I believe that this should involve the package ID if possible.

To help, I could search torsocks and the Tor browser to identify how they generate socks usernames and passwords that are unique but unguessable.

[n8fr8]

We understand this concern. In general, we don't recommend any Android VPN for the level of anonymity you are expecting to have. TAILS and Tor Browser are different in this regard. With Android, and especially VPNs, we cannot control all the variables that you can at the operating system or browser level.

However, the feature we do allow is for you to only selectively proxy specific apps over the Orbot VPN. This reduces the attack surface quite a bit.

I agree, it would be a great feature to have, to isolate traffic by package id, and if someone implements it, we would be happy to review and merge. I also believe the future "official" Tor VPN for Android under development will support this.

[ghost]

I had intended to implement it if I could when I find the time to participate here. It's good to hear that the guardianproject would be receptive to said feature.