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
