Also, regarding firewalls and NAT, maybe we could join in on <
https://trac.torproject.org/projects/tor/ticket/5578>
Best regards,
cl34r
Cl34r <an0n102968@???> wrote:
>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
>_______________________________________________
>tails-dev mailing list
>tails-dev@???
>https://mailman.boum.org/listinfo/tails-dev
