Nathan of Guardian
2016-12-21 15:12:46 UTC
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
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
***@guardianproject.info
Nathan of Guardian
***@guardianproject.info