On Fri, Sep 13, 2019 at 7:51 AM Hans-Christoph Steiner hans@guardianproject.info wrote:
teor:
Hi,
On 12 Sep 2019, at 20:50, Hans-Christoph Steiner hans@guardianproject.info wrote:
Then that work will hopefully be extended into sharing tor between apps, e.g. letting Briar, Tor Browser, etc share the tor SOCKS proxy to other apps that want to use it. That would happen via Android mechanisms like Intents to manage the discovery of SOCKS ports.
It's not always safe to have apps share Tor: a malicious website in one app can use various caches to discover activity in other apps. And there may be similar data leaks in other shared data structures or network connections.
How do these data leaks affect your use cases?
Is there some documentation of these leaks somewhere so I can dive into it? Like what kind of caches? Browser caches? We're mostly talking about apps that are not browsers, like messaging, nextcloud, etc.
I have a half-baked (and half-written) proposal for this. I'll try to finish it within the next few weeks.
The summary of it is that in an ideal situation every application should run its own tor client. If two applications share a tor client, and they both use the control port, then they both learn information about connections requested by the other - maybe that is onion service addresses only one app should use, or it leaks user behavior.
Even in the case where multiple apps don't have control port access, they can potentially use the same circuits if their proxy settings are misconfigured (which leaks timing information locally and possibly leaks information about applications and the user on the network).
Instead of every tor client wasting mobile data with duplicate downloads, I'm imagining having a Tor gateway (for lack of a better word). This essentially is a local Tor bridge relay that provides a single point of entry into and exit from the device. This solves most of the problems and it can be setup today except this completely breaks the assumptions within Tor that a Bridge is an external first-hop. In a configuration like this, the Tor gateway is a local hop, so it reduces a three-hop circuit to two-hops. And, to make matters worse, every second-hop would continue to be selected randomly, so the connection into the Tor network would be a random node and not a Guard. And, third, a client loses the ability to configure an actual bridge (with or without a pluggable transport) for its connection into the network.
With this being said, something like Bridge Guards [0] would solve these problems. Unfortunately, Bridge Guards are still an open question. I was hoping to look into this in the near future.
This setup would probably require some synchronization between tor node if, for example, multiple applications should use the same onion service, but this can happen outside of tor.
[0] https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.t...