[guardian-dev] Options for Signal circumvention
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 available from Microsoft Research that makes this easy
> on Android, and the Tor.framework on iOS.
> The second option, available only on Android, would be to implement the
> NetCipher 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 and iObfs
> 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.
>  https://github.com/thaliproject/Tor_Onion_Proxy_Library
>  https://github.com/iCepa/Tor.framework
>  https://github.com/guardianproject/netcipher
>  https://github.com/guardianproject/PLUTO
>  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...
More information about the guardian-dev