Re: [tor-dev] reproducible builds for Android tor daemon

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Fri, Sep 13, 2019 at 7:51 AM Hans-Christoph Steiner
<hans@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>
>
> teor:
> > Hi,
> >
> >> On 12 Sep 2019, at 20:50, Hans-Christoph Steiner <hans@xxxxxxxxxxxxxxxxxxxx> 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.txt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev