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 <[email protected]>: > 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 > [email protected] > _______________________________________________ > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > To unsubscribe, email: [email protected] >
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
