Re: [Tails-dev] Flashproxy Questions

Hi,
Thanks a lot for sharing this. This is one of the reasons why I strongly believe that there should be some sort of flashproxy implementation in Tails.

Best regards,
cl34r

hadi <hadirezaei@???> wrote:

>
>Hello
>
>I would like to add, that currently flashproxy is the *only* way to
>defeat internet censorship and keep up with the Anonymity in those
>countries who are using a very very great firewall, like Iran, which i
>currently live.
>Iran managed to defeat tor, even obfsproxies, hense we can't connect to
>tor at all.
>I'm an internet user in iran since 2005, and in 2012-2013, iran blocked
>all protocols of vpn connections, and managed to also blocked users to
>connect to tor.
>But still, flashproxy remains the best and most secured way to get away
>from the censorship and keep up your privecy
>I couldn't manage to configure a flashproxy, maybe a preconfigged one
>in tail would help us, and those who are in such countries.
>
>Cheers
>-Hadi
>On 6/3/2013 8:47 PM, Cl34r wrote:
>> 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
>> _______________________________________________
>> 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