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

Matthew Glennon matthew at glennon.online
Fri Aug 31 22:12:11 UTC 2018


What's the chances of switching to a mailing list system that doesn't
expose your email address to everyone on the list when you reply?

On Fri, Aug 31, 2018, 18:06 Gary <jaffacakemonster53 at gmail.com> wrote:

> Hi,
>
> Yes I too got messages from Cynthia every few hours (wanting to meet)
> until I blocked the email address.
>
> Thanks
>
> On Fri, 31 Aug 2018, 22:52 Matthew Glennon, <matthew at glennon.online>
> wrote:
>
>> Anyone else getting nude photos and random links from Cynthia Coleman <
>> cynthiacoleman843756 at ru.irzum.com> attached to this (and other thread(s)
>> lately? Spam obviously, but ugh.
>>
>> Matthew Glennon
>>
>> Want to make sure only I can read your message? Use PGP!
>> (Then paste the encrypted text into an email for me to receive!)
>> https://keybase.io/crazysane/
>> https://pgp.key-server.io/pks/lookup?op=get&search=0x92E43A8A9EF85EB4
>>
>>
>> On Fri, Aug 31, 2018 at 5:01 PM Conrad Rockenhaus <conrad at rockenhaus.com>
>> wrote:
>>
>>> Good God every conversation, now. Anyway.
>>>
>>> This exit isn’t bad exit material. Turkey has been known to block Tor
>>> though, I’m actually proud of this guy for having the cajones (also known
>>> as balls to those of you who don’t habla espanol) to operate an exit in
>>> country such as Turkey, which absolutely hates freedom inducing
>>> technologies such as Tor. Let’s give this guy (or gal) the atto-boy by
>>> marking the exit as a bad-exit just because stuff gets blocked in
>>> autocratic regimes that this operator has no control over. None, absolutely
>>> none. They screw with the DNS servers over there, that’s why during the
>>> last uprising they were tagging “8.8.8.8” on the walls.
>>>
>>> Now they’re doing things a little more sophisticated. Either way, this
>>> guy gives us a window to see what is blocked and what isn’t blocked within
>>> the Turkish thunderdome.
>>>
>>> -Conrad
>>>
>>> > On Aug 30, 2018, at 9:24 PM, Nathaniel Suchy <me at lunorian.is> wrote:
>>> >
>>> > 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
>>> >>
>>> > --
>>> > tor-talk mailing list - tor-talk at lists.torproject.org
>>> > To unsubscribe or change other settings go to
>>> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>>
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> _______________________________________________
> 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/20180831/98886147/attachment-0001.html>


More information about the tor-relays mailing list