[guardian-dev] Options for Signal circumvention

arrase arrase at gmail.com
Tue Dec 27 10:34:42 EST 2016

In general terms I do not like the idea of building Tor in the application,
but it is the simplest option for users, and it is the most reasonable if
IOS is supported.

2016-12-21 16:12 GMT+01:00 Nathan of Guardian <nathan at guardianproject.info>:

> I wanted to get feedback on two potential paths for adding network
> filtering circumvention into Signal. I know OWS devs are exploring their
> own ideas, but I hope this might push them towards some existing,
> available solutions.
> I want to point out that supporting circumvention for TCP traffic
> between the Signal client and server is the most easiest step to take.
> This would enable text and media messaging to work, but not voice calls.
> It may turn out that proxying TCP traffic is enough, since perhaps the
> UDP streams are not being targeted by firewalls anyhow.
> The first option then, is to build Tor into Signal, as ChatSecure iOS
> and Briar apps have done. This makes the user experience simple, and
> provides the full benefits of Tor to Signal. The downside is that the
> Tor binary alone is quite large, adding ~5MB to the Signal binary. The
> overhead in traffic and battery life is negligible. There is a Tor Onion
> Proxy Library[0] available from Microsoft Research that makes this easy
> on Android, and the Tor.framework on iOS[1].
> The second option, available only on Android, would be to implement the
> NetCipher[2] library, which detects if Orbot (Tor for Android) is
> installed, and then provides the necessary information to setup SOCKS or
> HTTP proxying through the local Tor instance. NetCipher is a small
> library, easily integrated through a gradle dependency and a few lines
> of code. Again, you could just enable this for TCP/HTTP traffic in the
> app, and not UDP. Also, you could have the option only appear if Orbot
> is installed. This is what Facebook for Android does today.
> The third option would be to use a Pluggable Transport provides such as
> Meek or Obfs4 in order to support your own Signal-specific single hop
> obfuscating proxy. The benefits of these are that they are harder to
> block, and in the case of Meek, require the adversary to block an entire
> cloud service such as Amazon, Azure or Google. Implementation of
> Pluggable Transports is similar to bundling Tor, and available through
> libraries such as PLUTO[3] and iObfs[4]
> I, and the others behind these libraries and frameworks, are ready to
> assist and advise as needed. I think this is a very important capability
> for Signal, as we are only going to see this kind of targeted filtering
> and blocking increase, and not decrease.
> Best,
>   +n
> [0] https://github.com/thaliproject/Tor_Onion_Proxy_Library
> [1] https://github.com/iCepa/Tor.framework
> [2] https://github.com/guardianproject/netcipher
> [3] https://github.com/guardianproject/PLUTO
> [4] https://github.com/mtigas/iObfs
> --
>   Nathan of Guardian
>   nathan at guardianproject.info
> _______________________________________________
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20161227/767d9c23/attachment.html>

More information about the guardian-dev mailing list