Ideas/Topics related to chaining Pluggable Transports / flashproxy

As of yet the framework that allows users to arbitrarily combine pluggable transport combinations to circumvent DPI features, is still a work in progress. This page lists all the transports and the progress made on them, makes for an interesting read:

Meanwhile we can discuss and tackle some of the pitfalls for using some of these transports should the time come when they are ready to be used in the way suggested above.

Flashproxy on its own doesn’t prevent protocol fingerprinting, but it makes bridge connections covert and could foil the harvesting process of bridge lists carried out by intelligence agencies :

First off lets look at the issues listed here:
https://www.whonix.org/wiki/Dev/Flash_Proxy

* Each flashproxy client requires a listening port on the open Internet. That's something we've never had in Whonix before, neither by default or through some options (our firewall even blocks it). That enables fingerprintability when scanning the ports of a Whonix host.
  • Listening on a port like that also increases the attack surface dramatically; before this, no random host could try to attack Whonix by connecting to it – the Whonix host had to (some how) connect to them first. So, yeah, these two things are quite contradictory.

  • The above point also raises some practical issues: in order to listen on an Internet-exposed port, the user must either use IPv6 (which isn’t served by all ISPs, and is unsupported/disabled by default in many routers in use) or, in the case of IPv4, set up port-forwarding (since most people are behind NAT). This limits the usefulness of flashproxy.

  • The flashproxy client requires a direct connection to gmail.com, which I feel a bit uncomfortable with for a number of reasons. Currently Whonix only “speaks Tor” outwards, i.e. it communicates directly only with the Tor network or Tor bridges (exceptions: unsafe user on Whonix-Gateawy (e.g. for physical isolation users and captive portal login).

  1. If a firewall is enabled on the host shouldn’t it block portscanners from being able to see if there is a port listening on the host? If this is still fingerprintable anyway, then perhaps we should avoid enabling it be default. And/or advise users to use some random port number manually.

  2. Not dramatically, its probably no different than when running Tor in relay mode. They already manage great since their code is of highest quality. From the page linked to at the beginning, its clear that the transports accepted by the Tor project and promoted by them go through a vetting process. Memory safe languages are promoted, with careful exceptions for ones coded in C.

Tor has added seccomp support which it should use automatically. Pluggable transports can follow suit and have Apparmor profiles added for them too. I don’t know if Whonix’s version of Debian has seccomp backported yet.

  1. Almost all off the shelf, run of the mill home routers have UPNP enabled. A problem I see if its used from behind a corporate/organization router which has it disabled - and a user can’t access.

  2. They have taken care of that hard requirement by now, allowing other services to be used. Whether they are using an alternative now, I can’t say and its a question best asked on the Tor mailinglist.

Although I can see conceptually how uneasy this would make us, the messages themselves are encrypted which should leave no room for MITM. Also think of gmail as no different than the many untrusted nodes that we traverse in any transaction over the network anyway.

Important Notes:

KVM guests such as the Gateway in our use case, are using the default NAT network. To configure port-forwarding from the host there is a script they provide on the libvirt wiki which we can adapt to our uses and distribute with the image in the future when transport chaining becomes a reality. one of them is for a single machine, the other can port forward to many - which is useful for multi-Gateway scenarios:

And here’s another dynamic port forwarding script for NAT guests for KVM:

https://mailman.boum.org/pipermail/tails-dev/2013-June/003127.html

I think its better if we look for alternatives to Flashproxy as its security implications, may be troubling after all. If there is anything with similar properties, its best to use that instead to avoid portforwarding problems if nothing else.

The bridgeless meek transport comes to mind perhaps

Thank you for this interesting discussion!

Pushing forward better circumvention support in Whonix is a fine thing to better support censored users. However, the threat model you originally had in mind (that I understand as “protect people from ending up in databases as extremists because they are connecting to known Tor servers by combining pluggable transports”), most likely won’t be improved.

Se this quote.

Quote Hide Tor use from the Internet Service Provider

Using private and obfuscated bridges alone doesn't provide strong guarantees of hiding the fact you are using Tor from your ISP. Quote (https://mailman.boum.org/pipermail/tails-dev/2013-April/002950.html http://www.webcitation.org/6G67ltL45) Jacob Appelbaum:

[quote] Some pluggable transports may seek to obfuscate traffic or to morph it. However, they do not claim to hide that you are using Tor in all cases but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing.[/quote]

Pluggable transports are an arms race against censors. Unfortunately, by concept it can not reliably hide Tor for everyone from passive eavesdroppers.

So even if they are unable to enumerate all bridges and we are able to trick them now, they’ll log all traffic and reclassify it as soon as they can detect, that pluggable transports have been used in past.

Also this only forwards the problem of ending up in a database marked as extremist from the user to someone else - to the one who hosts the bridge - because the bridge will connect to the public Tor network - and therefore will end up in a database marked as extremist.

The approach in countries who do not dare to ban the Tor network for everyone as censored countries do should be better an offensive one - get more people protest their constitutional right to privacy and marked as Tor users and extremists until the word extremist is so weak, that everyone is marked as one. I don’t see how the other approach “everyone or most should hide they are Tor users” is technically possible. For what you have in mind, the best concept might be friend to friend networks such as retroshare. Using friend to friend networks on top of the internet, we could end up with a net, that can reliably keep out eavesdroppers. However, it is a different approach than Tor. Both approaches are valuable and worthwhile.

In my opinion, the flashproxy concept is flawed. Censors can simply say “no open/incoming [server] ports for customer connections” + “open ports only for people who can provide a valid reason to require one”.

1. If a firewall is enabled on the host shouldn't it block portscanners from being able to see if there is a port listening on the host?
Usually firewall block all incoming ports by default. This further complicates flash proxy. Obstacles are host firewalls and/or home routers (due to NAT).
If this is still fingerprintable anyway, then perhaps we should avoid enabling it be default. And/or advise users to use some random port number manually.
I've sent a mail to the creator of flash proxy (David) to get an answer to that question.
I don't know if Whonix's version of Debian has seccomp backported yet.
It's in seccomp wheezy-backports. I don't know about seccomp. Is it enough to install the package and all applications making use of it will benefit from it?
3. Almost all off the shelf, run of the mill home routers have UPNP enabled.
But Tor's UPNP support is still broken and no one working on it?
4. They have taken care of that hard requirement by now, allowing other services to be used. Whether they are using an alternative now, I can't say and its a question best asked on the Tor mailinglist.

Although I can see conceptually how uneasy this would make us, the messages themselves are encrypted which should leave no room for MITM. Also think of gmail as no different than the many untrusted nodes that we traverse in any transaction over the network anyway.


Ok.

[quote]If this is still fingerprintable anyway, then perhaps we should avoid enabling it be default. And/or advise users to use some random port number manually.[/quote] I've sent a mail to the creator of flash proxy (David) to get an answer to that question.
I got permission to publish it here. Thanks, David!

me:

when flash proxy listens on a random open port, will censors be able to fingerprint that port by doing a port scan / probe?

David Fifield:

Yes, I'm sure it's fingerprintable, because it's just the normal Python BaseHTTPServer.

When we implement WebRTC, I think it won’t be possible to scan for client any more.

You can also link to
AChildsGardenOfPluggableTransports · Wiki · Legacy / Trac · GitLab .
It shows exactly how it looks when a flash proxy connects to a client.

Thanks for investigating. That is good news because we can assume it solves the security problems of port forwarding and fingerprinting.

By fingerprinting I mean ports, the Flashproxy protocol itself is easily fingerprintable but thats what obfsproxy is for.

Pushing forward better circumvention support in Whonix is a fine thing to better support censored users. However, the threat model you originally had in mind (that I understand as "protect people from ending up in databases as extremists because they are connecting to known Tor servers by combining pluggable transports"), most likely won't be improved.

Good points. With millions of users who are using it now and ever visited and used the site, the stuff they gather about visitors and users is useless noise which is about as useful as saying ‘this person has an internet connection’. The sheer number and diversity of users makes any censoring have huge collateral damage with an effect similar to cutting off the internet. The meek plugin I was talking about last post, makes use of major US webservices as rendezvous points to relays, censoring access to them is very unprobable in Western countries.

Worthwhile reasons:

  • To counter censorship in event of any Western society going full turn and deploying a Great Firewall on its people. NSA may have the whole network but I don’t think they will want to be doing active censoring attacks in other countries’ networks.

  • From the leaked documents, I think its clear that the Tor protocol used in bridge obfuscation is reaching a point of no return for DPI detection. It may be an arms race but there will be a point where there is little any of them can do to find out when a Tor client is being used in the future vs looking up that an ‘extremist’ used Tor in the past.

  • It will confuse the distinction between whether this is a Bridge or someone running a Tor client and also communicating with someone else on the clearnet with a normal looking protocol.

Seccomp discussion moved here:

flashproxy-client is now installable from Debian.

https://packages.debian.org/jessie/flashproxy-client

I think we should install it by default in Whonix 13. Even if we do not encourage using it, it simplifies the setup for those who wish to use it. Done in git master.

Updated the wiki:
Configure (Private) (Obfuscated) Tor Bridges

1 Like

Flashproxy has been removed from TBB. Therefore it can be considered deprecated.

We should remove Flashproxy from Tor Browser as it basically has zero
users. dcf and yawning are fine with that (see discussion in #16756 for more details).

I must admit, I am not unhappy about it. The project name and the requirement for an incoming connection (port forwarding) was a mess.


Snowflake - Soon to replace flashproxy. It uses WebRTC peers to solve NAT connection problems.

1 Like