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:
* 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).
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.
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.
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.
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.
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: