[tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship

Nathaniel Suchy me at lunorian.is
Fri Aug 31 02:24:26 UTC 2018


What if a Tor Bridge blocked connections to the tor network to selective
client IPs? Would we keep it in BridgeDB because its sometimes useful?

On Thu, Aug 30, 2018 at 10:02 PM arisbe <arisbe at cni.net> wrote:

> Children should be seen and not herd.  The opposite goes for Tor relays.
> Arisbe
>
>
> On 8/30/2018 2:11 PM, Nathaniel Suchy wrote:
>
> So this exit node is censored by Turkey. That means any site blocked in
> Turkey is blocked on the exit. What about an exit node in China or Syria or
> Iraq? They censor, should exits there be allowed? I don't think they
> should. Make them relay only, (and yes that means no Guard or HSDir flags
> too) situation A could happen. The odds might not be in your favor. Don't
> risk that!
>
> Cordially,
> Nathaniel Suchy
>
> On Thu, Aug 30, 2018 at 3:25 PM grarpamp <grarpamp at gmail.com> wrote:
>
>> This particular case receiving mentions for at least a few months...
>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114
>>
>> The relay won't [likely] be badexited because neither it nor its upstream
>> is
>> shown to be doing anything malicious. Simple censorship isn't enough.
>> And except for such limited censorship, the nodes are otherwise fully
>> useful, and provide a valuable presence inside such regions / networks.
>>
>> Users, in such censoring regimes, that have sucessfully connected
>> to tor, already have free choice of whatever exits they wish, therefore
>> such censorship is moot for them.
>>
>> For everyone else, and them, workarounds exist such as,,,
>> https://onion.torproject.org/
>> http://yz7lpwfhhzcdyc5y.onion/
>> search engines, sigs, vpns, mirrors, etc
>>
>> Further, whatever gets added to static exitpolicy's might move out
>> from underneath them or the censor, the censor may quit, or the exit
>> may fail to maintain the exitpolicy's. None of which are true
>> representation
>> of the net, and are effectively censorship as result of operator action
>> even though unintentional / delayed.
>>
>> Currently many regimes do limited censorship like this,
>> so you'd lose all those exits too for no good reason, see...
>> https://ooni.torproject.org/
>>
>> https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country
>>
>> And arbitrarily hamper spirits, tactics, and success of volunteer
>> resistance communities and operators in, and fighting, such regimes
>> around the world.
>>
>> And if the net goes chaotic, majority of exits will have limited
>> visibility,
>> for which exitpolicy / badexit are hardly manageable solutions either,
>> and would end up footshooting out many partly useful yet needed
>> exits as well.
>>
>>
>> If this situation bothers users, they can use... SIGNAL NEWNYM,
>> New Identity, or ExcludeExitNodes.
>>
>> They can also create, maintain and publish lists of whatever such
>> classes of nodes they wish to determine, including various levels
>> of trust, contactability, verification, ouija, etc... such that others
>> can subscribe to them and Exclude at will.
>> They can further publish patches to make tor automatically
>> read such lists, including some modes that might narrowly exclude
>> and route stream requests around just those lists of censored
>> destination:exit pairings.
>>
>> Ref also...
>> https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit
>> https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit
>>
>>
>> In the subect situations, you'd want to show that it is in fact
>> the exit itself, not its upstream, that is doing the censorship.
>>
>> Or that if fault can't be determined to the upstream or exit, what
>> would be the plausible malicious benefit for an exit / upstream
>> to block a given destination such that a badexit is warranted...
>>
>> a) Frustrate and divert off 0.001% of Turk users smart enough to
>> use tor, chancing through tor client random exit selection of your
>> blocking exit, off to one of the workarounds that you're equally
>> unlikely to control and have ranked, through your exit vs one
>> of the others tor has open?
>>
>> b) Prop up weird or otherwise secretly bad nodes on the net,
>> like the hundreds of other ones out there, for which no badexit
>> or diverse subscription services yet exist to qualify them?
>>
>> c) ???
>>
>> Or that some large number of topsites were censored via
>> singular or small numbers of exits / upstreams so as to be
>> exceedingly annoying to the network users as a whole, where
>> no other environment of such / chaotic widespread annoyance
>> is known to exist at the same time.
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
> _______________________________________________
> tor-relays mailing listtor-relays at lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> --
> One person's moral compass is another person's face in the dirt.
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180830/e7ea44d3/attachment.html>


More information about the tor-relays mailing list