03/06/13 03:58, an0n102968@??? wrote:
> Hi everyone!
Hi!
Thanks for your interest in contributing to Tails!
> Recently, after I forked Tails, I successfully built Tails with
> flashproxy-client installed and flashproxy implemented in bridge mode
I suppose the feature was not successfully tested?
> <https://github.com/fr0stycl34r/tails/commit/b1a847caaa561a952521f1700219efbfd41cf14c>
> ). I know that there are multiple ways to implement flashproxy in bridge
> mode, so I was wondering what the best way to do this would be (eg, I make
> "flashproxy mode" and keep it seperate from "bridge mode" at boot). I'm
> open to any ideas, so just tell me if you you have any.
In general options should be avoided since they are sources of user
confusion, code complexity and potential anonymity set distinguishers.
However, if this "flashproxy mode" is compatible with our current state
of "bridge mode" (e.g. plays nice with the "fake" bridge we add etc.)
and don't introduce any leaks, fingerprintablility or additional attack
surface, its inclusion is a no-brainer. Otherwise, depending on the
degree of violation of the above listed issues, we may want to include
it as a separate option to bridge mode, or not an option at all.
I am, admittedly, quite ignorant of the flashproxy design, but from some
quick research I learned several troubling things, at least from Tails'
perspective:
* Each flashproxy client requires a listening port on the open Internet.
That's something we've never had in Tails before, neither by default or
through some options (our firewall even blocks it). That enables
fingerprintability when scanning the ports of a Tails host, but on the
other hand bridg mode is already trivially distinguished from Tails'
normal operation (i.e. direct connections to the Tor network), so if the
flashprox transport was enabled by default in bridge mode, it wouldn't
really increase fingerprintability. But listening on a port like that
also increases the attack surface dramatically; before this, no random
host could try to attack Tails by connecting to it -- the Tails host had
to (some how) connect to them first. So, yeah, these two things are
quite contradictory re: having it merged with bridge mode or keeping it
a separate option.
* 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
support no matter if its a separate option or not.
* The flashproxy client requires a direct connection to gmail.com, which
I feel a bit uncomfortable with for a number of reasons. Currently Tails
only "speaks Tor" outwards, i.e. it communicates directly only with the
Tor network or Tor bridges (exceptions: unsafe browser (e.g. for captive
portal login, which often luckily are on the LAN) and I2P). I would be
sad to lose this property for bridge mode, which speaks in favour of a
separate option.
So, my plan was to answer your question of whether to merge this into
bridge mode, or make it available as a separate option. Given my above
points, I certainly don't see an obvious answer to this, even when
ignoring the issues with introducing yet another option that our users
must make an intelligent decisions about. In fact, the flashproxy
design, while certainly valid in other settings, seems quite problematic
in Tails' context. I am sad to say that I personally feel doubtful about
supporting flashproxies in Tails given the current state of things.
Cheers!
