Discussion:
Options for Signal circumvention
(too old to reply)
Nathan of Guardian
2016-12-21 15:12:46 UTC
Permalink
Raw Message
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
***@guardianproject.info
Jon Camfield (jcamfield@INTERNEWS.ORG)
2016-12-21 18:58:07 UTC
Permalink
Raw Message
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This might be a useful time to note that there is movement on
obfuscated UDP via the pluggable transports model - this would not
route over Tor, but could help (depending on the specific blocking
methodology - DNS/IP or traffic) the circumvention side; and could
leverage a lot of the ongoing hard work Tor and many others are
putting in to building obfuscation models.

cc'ing in Brandon from Operator Foundation; who's building client and
server side implementations of this (plus much more!) in Go:
https://github.com/OperatorFoundation/shapeshifter-dispatcher , based
on rough consensus around a next-generation pluggable transports spec
here: https://www.pluggabletransports.info/assets/PTSpecV2Draft1.pdf

If the blocking is IP/DNS based, meek would seem appropriate, if
protocol based, obfs4? The benefit of adopting a system that can work
with the PT model is that if this changes, it becomes easier to swap
in alternative obfuscation models that are likely already deployed and
working in other contexts.

Signal was already on the top of our list to ping once we had UDP PTs
out, but it seems reality is a bit ahead of the game here. :/

Cheers,
Jon
Post by Nathan of Guardian
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
- --
Jon Camfield | Director and Senior Technologist, Internet Initiatives
***@internews.org
PGP: D776 2A79 A1AE F000 7F53 A127 B46A 01C3 270C 17F1
Mobile/Skype/Signal/XMPP on request

INTERNEWS | Local Voices. Global Change.
www.internews.org | @internews

Loading...