|
|
|
== Sharing One Tor Process Among Many Applications ==
|
|
|
|
|
|
|
|
These notes are from a session that took place during the Berlin Tor Dev Meeting on the afternoon of 29-Sept-2015 (Tuesday).
|
|
|
|
|
|
|
|
Note that solutions may be system/OS dependent, e.g., what makes sense on iOS may not work for Android or the desktop. Due to competing sessions, not much mobile expertise was present, so we mostly discussed desktop issues.
|
|
|
|
|
|
|
|
=== The current situation: ===
|
|
|
|
* Most applications either:
|
|
|
|
1. Ship their own copy of tor (e.g., Tor Browser, Ricochet)
|
|
|
|
2. Have a dependency on another application (e.g., Tor Birdy asks users to start Tor Browser and leave it running).
|
|
|
|
* Sophisticated users can configure all applications to use a single, system provided tor.
|
|
|
|
* Application developers generally bundle a tor because they want to provide a simple "out of the box" experience.
|
|
|
|
* We do not expect this practice to stop, at least for desktop applications.
|
|
|
|
* Orbot does provide "tor as a service" via APIs on Android (several apps developed by the Guardian Project depend on Orbot for their tor).
|
|
|
|
|
|
|
|
=== What problems occur when there are many tor processes? ===
|
|
|
|
* Users need to configure each tor separately, which can be complicated (e.g., when bridges are used).
|
|
|
|
* There is more than one guard per system, which is not necessarily desirable.
|
|
|
|
* Redundant consensus downloads.
|
|
|
|
* Some applications may use an out-of-date version of tor.
|
|
|
|
* More system resources (CPU, memory, etc.) will be used, which is bad (especially on embedded and mobile platforms).
|
|
|
|
* [Added by Roger post-meeting: applications that launch their own Tor miss out on system-Tor features like running as a separate user or starting with more file descriptors than a normal user can have. For example, Tor Browser on Linux will never be able to turn its Tor into a useful relay, with the current design.]
|
|
|
|
|
|
|
|
=== Possible Solutions for Desktop Systems ===
|
|
|
|
==== System Tor ====
|
|
|
|
* Centrally installed, configured, and managed (like Tails).
|
|
|
|
* Needs to be discoverable.
|
|
|
|
* Do we assume a standard TCP port or path for a UNIX domain socket (or the Windows equivalent)?
|
|
|
|
* Access control:
|
|
|
|
* Systems may use a control port filtering proxy to limit what each application can do (Tails has one and Yawning also wrote one).
|
|
|
|
* Applications could probe via the control port to ensure that the system tor will meet their needs, e.g., Ricochet needs to be able to create hidden services but Tor Messenger may only need Tor-based communication / client access.
|
|
|
|
* If the system tor does not provide what an application needs, it could start its own bundled tor daemon.
|
|
|
|
* The system tor approach is already being used in Tails and is probably what systems like Debian would prefer.
|
|
|
|
==== Shared Tor ====
|
|
|
|
* Each application bundles a tor.
|
|
|
|
* Applications do some probing to determine if a tor they can use is already running.
|
|
|
|
* Well known control port (or UNIX domain socket path) and cookie auth file path.
|
|
|
|
* We could use a system-wide shared mutex that would only be present if a tor is already running.
|
|
|
|
* If a suitable tor is found, use it. If not, start a bundled tor.
|
|
|
|
* Issues:
|
|
|
|
* The tor "owning controller" concept makes it difficult for Application B to use a tor that was started by and is therefore owned by Application A because tor will exit when Application A exits.
|
|
|
|
* Sometimes applications patch tor (Tor Browser has a history of doing this).
|
|
|
|
* Meek requires a Tor Browser, which means that applications that want to support a meek pluggable transport will have a dependency on Tor Browser anyway.
|
|
|
|
|
|
|
|
==== Other Ideas ====
|
|
|
|
* It might be possible to avoid some of the problems associated with having more than one tor by modifying the tor daemon to allow sharing of some state information (e.g., consensus and guard info).
|
|
|
|
* It may make sense to take an inventory of what control port access is needed by the applications that we know about, e.g., SETCONF, NEWNYM, ADD_ONION.
|
|
|
|
|
|
|
|
=== Next Steps ===
|
|
|
|
* More discussion among application developers (including iOS/Android) and with core tor developers.
|
|
|
|
* Brainstorm possible architectures.
|
|
|
|
* Brainstorm solutions to challenging problems (e.g., Tor Browser-specific tor patches, the owning controller issue).
|
|
|
|
* Document best practices. |
|
|
\ No newline at end of file |
