So, what do you suggest we do? I mean, should we wait for flashproxy's development to mature, or should we meet on IRC and discuss our options further?
Best regards,
cl34r
anonym <anonym@???> wrote:
>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!
>
>_______________________________________________
>tails-dev mailing list
>tails-dev@???
>https://mailman.boum.org/listinfo/tails-dev
