Re: [tor-relays] Tor project helping to attempt to cancel Richard Stallman

[Igor Mitrofanov]

I denounce the Tor Project's political activism under the new
administration and this attempt to fuel the cancel culture.
I am signing the supporting letter for Richard Stallman and pausing my
relays. I realize that this is largely symbolic, but so is running Tor
relays in the first place. I am not going to let anyone use my resources in
support of censorship.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

[Igor Mitrofanov]

Is there anything Tor can do inside the Tor browser itself?
I would understand and support something as drastic as disabling non-HTTPS,
non-Onion connections altogether. When the user types a URL with no
protocol prefix, the browser will assume HTTPS.
This may break some websites, so a transition may be required. Such a
transition can start with a warning banner, proceed to a warning page, then
to a browser setting to enable it, and finally to disabling the capability
for good.

The above assumes there is much less benefit in running a rogue Tor exit if
the operator cannot see or alter the content it is relaying.

On Fri, Aug 14, 2020 at 1:25 PM niftybunny <
abuse-cont...@to-surf-and-protect.net> wrote:

>
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>
>
>- There are multiple indicators that suggest that the attacker still
>runs >10% of the Tor network exit capacity (as of 2020–08–08)
>
>
> And on this one: I trust nusenu who told me we still have massiv malicious
> relays.
>
>
>
> On 14. Aug 2020, at 19:12, Roger Dingledine  wrote:
>
> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>
> This shit has to stop. Why are the relays in question still online?
>
>
> Hm? The relays are not online -- we kicked them in mid June.
>
> We don't know of any relays right now that are attacking users.
>
> Or said another way, if anybody knows of relays that are doing any attacks
> on Tor users, ssl stripping or otherwise, please report them. I believe
> that we are up to date and have responded to all reports.
>
> That said, there is definitely the uncertainty of "I wonder if those
> OVH relays are attacking users -- they are run by people I don't know,
> though there is no evidence that they are." We learned from this case
> that making people list and answer an email address didn't slow them down.
>
> I still think that long term the answer is that we need to shift the
> Tor network toward a group of relay operators that know each other --
> transparency, community, relationships, all of those things that are
> costly to do but also costly to attack:
> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>
> But the short term answer is that nobody to my knowledge has shown us
> any current relays that are doing attacks.
>
> Hope that helps,
> --Roger
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay Consensus Low

[Igor Mitrofanov]

Matt, if you only have 1 host, it may be more beneficial to create 2
relays on it (or more than 2 - if you have more than 1 IPv4 address
available) using tor-instance-create. You could be hitting the limits
of what a single CPU core can do.

On Sun, May 26, 2019 at 4:07 PM Keifer Bly  wrote:
>
> Hello Matt, I recently started a new middle relay (torworld) as well, and 
> also run a PT bridge on a separate network. This is just my knowledge, but 
> tor relays are not always used to their maximum capacity, so your relay will 
> receive more traffic some days and less on other days. Different tor relays 
> are chosen for each user each time they connect, so varying amounts of 
> traffic are to be expected. As long as your relay is correctly configured, 
> you should not have much to worry about.
>
> --Keifer
>
>
> On Sat, May 25, 2019 at 4:48 PM Matt Westfall  wrote:
>>
>> My tor node: 
>> https://metrics.torproject.org/rs.html#details/B1B10104EB72A1FBBF6687B05F1915D87D00DBDE
>>
>> Doesn't ever go up above 8800 or so.
>>
>> One thing I notice in Nyx is that my connections never go above about 2000 
>> in and out connections.
>>
>> I have advertised bandwidth of just shy of a gigabit in my config.  I 
>> understand now that the "advertised bandwidth" is calculated based on 
>> observed traffic through the node, which while more reliable and avoids 
>> abuse, seems to be counter productive to a degree.
>>
>> Ultimately what do I need to do to get more traffic through my node? Cause I 
>> have a 2Gbps fiber sitting here basically doing nothing so I was giving 
>> 1Gbps to tor :)
>>
>> Config --
>> RunAsDaemon 1
>> ControlPort 9051
>> ORPort 9001
>> ORPORT [2001:559:c290::fffb]:9001
>> RelayBandwidthRate 45 MB  # Throttle traffic to 100KB/s (800Kbps)
>> RelayBandwidthBurst 50 MB # But allow bursts up to 200KB/s (1600Kbps)
>> DirPort 9030 #
>> ExitPolicy reject *:* # no exits allowed
>> ExitPolicy reject6 *:*
>>
>> Any suggestions appreciated.
>>
>>
>> Matt Westfall
>> President & CIO
>> ECAN Solutions, Inc.
>> Everything Computers and Networks
>> 804.592.1672
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor website overhaul -- who deserves punishment?

[Igor Mitrofanov]

Alison, can you please share a link to the results of 'user testing as
well as research on
usability, accessibility, and localization'? I most definitely welcome
the idea of making Tor look modern (and would like to help if I can)
but it would be good to see what standards the development team is
following to get there.

I remember the 2018 redesign of Tor Metrics that prompted similar
negative responses. Back then there was a giant quote taking up the
top 1/3rd of the screen. Now half of my screen is covered with a large
slogan that looks like a pornsite ad: "Browse privately. Explore
freely.". At the bottom there is a header called "About Us" that is
smaller than the others but the text under that header is enormous.
Clicking "Documentation" at the very top takes me to the old
white-green design. Etc.

Nobody deserves punishment by the way. You all deserve enormous kudos
for working on Tor.

On Wed, Mar 27, 2019 at 10:39 AM Alison Macrina  wrote:
>
> Ralph Seichter:
> > * Matthew Finkel:
> >
> >> Please be respectful. The tone of this message is disrespectful of the
> >> time, effort, and skill that went into launching the new website. It's
> >> unfortunate you do not appreciate or like the new site, but that does
> >> not excuse you.
> >
> > Disrespectful for you, maybe. I did not name names. Besides, I won't
> > feign to care about time and effort spent when I consider the result not
> > worth said time and effort. I don't hand out medals or diplomas for
> > trying/participating. You probably get the gist. ;-)
>
> I agree with Matthew that your email was very rude. Basic human decency
> is not "hand[ing] out medals or diplomas for trying/participating".
> Please do better. We are all working hard on Tor, many of us volunteers,
> and we should treat one another as community.
>
> >
> >> This new website is significantly better and more welcoming for the
> >> general population, rather than a small percentage of the population.
> >
> > I respect your right to have that opinion, although I disagree.  What
> > metrics you believe to support your "significantly better" I don't know.
>
> The redesign efforts were based on user testing as well as research on
> usability, accessibility, and localization. I am personally excited for
> how much easier it will be for our users to find what they're looking
> for, and how much easier it will be to translate this new site into many
> languages.
>
> >
> >> If you have suggestions for improving the new design, then please let
> >> us know.
> >
> > I suggest reverting to the previous website design. That design was,
> > IMO, "welcoming for the general population" in the sense that it treated
> > visitors as intelligent beings, capable of reading more than a few
> > buzzwords. I find it alarming that a certain school of web designers
> > these days seem to think their audience has the attention span of fruit
> > flies. From where I am standing, *that* is disrespectful.
> >
> > -Ralph
>
> Okay, you are entitled to your opinion as well. Please also be kind. And
> finally, this is a mailing list for tor-relays. Please stay on topic.
>
> Alison
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] tor-instance-create vs. /etc/tor/torrc

[Igor Mitrofanov]

Hi,

I use tor-instance-create to spawn a number of relay instances.
However, there seems to be one extra instance running - the default
one that reads /etc/tor/torrc (and not
/etc/tor/instances/INSTANCE/torrc).

How do I disable that default tor relay? It opens port 9050 and does
who else knows what by default. I can delete /etc/tor/torrc and it
seems to do the trick, however, I am not sure how permanent this
change will be with automatic package updates.

Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] hidden service performance

[Igor Mitrofanov]

I'd like to call out the apparent hidden service performance slowdown:
https://metrics.torproject.org/torperf.html?start=2017-04-23=2018-01-21=all=onion=50kb

I hope the dev team is looking into it.

Thanks,
Igor
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Setting myfamily

[Igor Mitrofanov]

Is there a way to inherit a portion of torrc (to avoid copying the
same MyFamily line into every torrc)?

On Thu, Jan 4, 2018 at 11:12 AM, John Ricketts  wrote:
> Agreed.  All of my 50 relays list all relays including itself.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Combined relay and hidden service, good idea or not?

[Igor Mitrofanov]

It is safe to assume that both relays and select hidden services are
being scanned 24/7. When your host reboots (say, as a result of an
automatic OS update), both your relay and your hidden service become
unavailable at the same time, instantly revealing the IP of the hidden
service.

On Thu, Jan 4, 2018 at 7:08 PM,   wrote:
> When operating a hidden service and a relay in one tor instance, tor
> currently warns:
>
> [warn] Tor is currently configured as a relay and a hidden service. That's
> not very secure: you should probably run your hidden service in a separate
> Tor process, at least -- see https://trac.torproject.org/8742
>
> First, that issue has been fixed and closed.
>
> Second, I had read in the past opinions stating:
>
> When operating a hidden service, running a relay helps mix traffic so that
> anyone observing traffic from the machine cannot easily run an analysis
> targeted at a hidden service that might exist on that machine.
>
> The text of the startup warning seems to contradict that belief.  Is there
> more to know, or is the warning only applicable to the now-closed
> information leak?
>
> Can someone kindly clarify the current best practice in this regard and
> address whether or not that warning should be removed from tor's startup
> diagnostics?
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] MaxMemInQueues - per host, or per instance?

[Igor Mitrofanov]

Thanks. I do have the IP space.

It is a pity multiple instances cannot watch the overall RAM
remaining. I have quite a bit of RAM left, but there are large
discrepancies in terms of how much RAM different relays are using (>3
GB for some, <1 GB for others), so it will be tricky to set
MaxMemInQueues without making it too conservative.

On Fri, Dec 22, 2017 at 11:46 AM, r1610091651 <r1610091...@telenet.be> wrote:
> It would expect it to be per instance. Instances are independent of each
> other. Further one can only run 2 instances max / ip.
>
> On Fri, 22 Dec 2017 at 20:40 Igor Mitrofanov <igor.n.mitrofa...@gmail.com>
> wrote:
>>
>> Hi,
>>
>> Is MaxMemInQueues parameter per-host (global) or per-instance?
>> Say, there are 10 relays on the same 24 GB host. Should I set
>> MaxMemInQueues to 20 GB, or 2 GB in each torrc?
>>
>> Thanks,
>> Igor
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] MaxMemInQueues - per host, or per instance?

[Igor Mitrofanov]

Hi,

Is MaxMemInQueues parameter per-host (global) or per-instance?
Say, there are 10 relays on the same 24 GB host. Should I set
MaxMemInQueues to 20 GB, or 2 GB in each torrc?

Thanks,
Igor
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Issues with faravahar?

[Igor Mitrofanov]

On Tue, Dec 12, 2017 at 1:17 PM, tor  wrote:
>>I am getting this too, I saw this the logs a few months ago and didn't think
>>anything of it.
>
>
> I wouldn't worry about it. Faravahar has a long history of misbehavior:
>
> https://lists.torproject.org/pipermail/tor-relays/2015-November/008097.html
> https://lists.torproject.org/pipermail/tor-relays/2017-January/011627.html
>
> (and other threads, I'm sure.)

Why don't you guys boot it off the network and replace it with a
better-maintained authority server?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Detecting Network Attack [re: exit synflooded]

[Igor Mitrofanov]

After reading every paper and post on sysctl.conf and iptables tuning
I could find, and reading some kernel code, I have come to a
conclusion that, while there are a few settings to tune (can share
mine, but your mileage *will* vary), most of the defaults are actually
not broken in the latest kernels, while a lot of tuning
recommendations online are outdated.

I enjoyed this guide a lot:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html-single/performance_tuning_guide/index.
It is written for Red Hat, but contains quite a few insights
applicable to all Linux distributions.

- Igor


On Sat, Nov 25, 2017 at 3:14 PM, Dhalgren Tor  wrote:
>>Well, it's still going on, and is pretty much ruining Libero :( .  Running 
>>CentOS 6, here.
>>
>>When it's happening it can look like this:
>>
>># netstat -n | grep -c SYN
>>17696
>
> I run a fast exit and can offer some advice:
>
> 1) mitigate bug #18580 (also #21394); is a DNS denial-of-service and
> could be the problem.  either upgrade to 0.3.2.4+ or edit resolve.conf
> per 
> https://trac.torproject.org/projects/tor/wiki/doc/DnsResolver#TuningeventdnscomponentofTorDaemon
>
> also check out https://arthuredelstein.net/exits/
>
> 2) if you continue to experience excessive outbound scanning SYNs,
> I've found that simply enabling connection tracking helps by
> implicitly limiting the rate a which connections can originate.  If an
> iptables "-m state --state ESTABLISHED,RELATED -j ACCEPT" rule exists
> it will turn it on or you could modprobe the module if you don't want
> to configure incoming connection rules.
>
> some useful sysctl.conf changes, run sysctl -p after or reboot
>
> # Tor Exit tuning.
> net.ipv4.ip_local_port_range = 1025 65535
> net.ipv4.tcp_synack_retries = 2
> net.ipv4.tcp_max_tw_buckets = 4194304
> net.ipv4.tcp_tw_recycle = 1
> net.ipv4.tcp_fin_timeout = 30
> net.ipv4.tcp_keepalive_time = 300
> net.ipv4.tcp_keepalive_intvl = 10
> net.ipv4.tcp_keepalive_probes = 3
> net.netfilter.nf_conntrack_tcp_timeout_established = 1000
> net.netfilter.nf_conntrack_checksum = 0
>
> you might see many messages:
>
> kernel: nf_conntrack: table full, dropping packet
>
> which indicates no connection table slots were available for an
> outbound connection and that rate limiting is effected
>
> state of connection tracking appears in /proc/net/nf_conntrack
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Atlas is now Relay Search!

[Igor Mitrofanov]

Atlas definitely looked lighter, more airy. The new UI looks dense and
dated, with that Microsoft Office style table from the 90s. Oh well,
I'll get used to it - at least it is not yet another "Web 2.0"
Bootstrap. The idea of merging Atlas into Metrics is definitely a good
one.

On Tue, Nov 14, 2017 at 8:28 AM, Guinness  wrote:
> Le Tue, Nov 14, 2017 at 12:52:27PM +, Iain R. Learmonth écrivait :
>>
>> Hi All,
>>
>> You may notice that Atlas has a new look, and is no longer called Atlas.
>> For now no URLs have changed but this is part of work to merge this tool
>> into the Tor Metrics website.
>>
>> The style is determined by the Tor Metrics Style, and modifications have
>> been made to fit this.
>>
>> The decision was made to deploy these changes before the actual
>> integration into metrics.torproject.org to allow for other issues to be
>> worked on. This was a big change and it was tricky maintaining two
>> branches of the codebase.
>>
>> Issues should still be reported on the Metrics/Atlas component in the
>> Tor trac if they arise. When we come to full integration, URLs will
>> change but there will be a period where we maintain redirects to prevent
>> any URLs from breaking while waiting for being updated.
>>
>> Thanks,
>> Iain.
>>
> Hi!
>
> Thanks for this new interface!
>
> Is it just me or is the font way bigger than it used to be with Atlas?
> I personnaly find it too big, but it is just some cosmetics :)
>
> Cheers,
> --
> Guinness
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] "Fast" flag definition

[Igor Mitrofanov]

Hi,

It looks like 94.7% of all Running relays have the "Fast" flag now. If
that percentage becomes 100%, the flag will become meaningless.
What were the reasons behind the current definition of "Fast", and are
those still valid? If not, should "Fast" become self-adjusting
("faster than 2 Mbps or 70% of all Guard relays, whichever is
greater")?

Thanks!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

>> # Only listen on loopback
>>
>> interface=lo
>> bind-interfaces
>
> What is your opinion about the config line "listen-address=127.0.0.1" advised
> in https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ?

It should have a similar effect, except that 127.0.0.1 is IPv4 only,
while "interface=lo" seems IP version agnostic (I have disabled IPv6
on my relay so I don't know this for sure).

> Interesting. Could you tell approximately what is the average Tor traffic per
> second on your relay ? Maybe I will increase the number of cached entries to
> 100 000.

I am afraid you cannot increase it without recompiling dnsmasq from
source. It has a hardcoded limit of 10k.

I believe that cache efficiency can be tuned with *ttl config
parameters, but it would take considerable time to tune it. I also bet
it depends on the Exit policy of your relay - the more ports you
allow, the more requests will miss the cache.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

Ralph, you seem to be more concerned with minimizing the number of
hosts involved in a DNS lookup, and you (correctly) believe that
running a recursive resolver yourself, as opposed to delegating it,
decreases that number. If a DNS provider like Hurrican Electric is
your main concern, then I think we are in agreement.

I assume, however, that most of these ISPs have no technical
capability or business incentives to be engaged in Tor traffic
correlation. When it comes to Tor traffic correlation, I am more
concerned with defending Tor users against the already-known
attackers.

According to the leaked documents, there is a large, but not global,
passive adversary confirmed to intercepting and analyzing IP traffic
between targeted hosts, without the capacity to control all network
links, and without the legal authority to hack the hosts themselves. I
am making an assumption that Tor relays sending DNS requests to a
large and diverse number of destinations can make practical
DNS-assisted traffic correlation prohibitively expensive.


On Sun, Oct 8, 2017 at 12:03 PM, Ralph Seichter <m16+...@monksofcool.net> wrote:
> On 08.10.17 20:48, Igor Mitrofanov wrote:
>
>> Unbound's upstream requests can be intercepted and used in traffic
>> correlation just like any other.
>
> I thought I expressed myself clearly enough, but I'll try one more time.
> Unbound, or any other resolver, can either a) perform the recursive
> lookup or b) delegate the lookup. Case a) is preferable in regards to
> profiling because it does not involve additional third-party servers
> that have nothing to do with the query. Case b) involves third-party
> servers, so it offers more points where traffic can be analysed. Looking
> up host.somedomain.tld should, if no cached data is available, only
> involve one of the root zone servers, one server for the tld zone, and
> one server for the somedomain zone. It should not involve a resolver run
> by Google or other parties that have no business in knowing that my Tor
> node just looked up host.somedomain.tld.
>
>> Yes, Unbound follows the recursive protocol and works with the
>> hierarchy from the root DNS servers down, but your ISP can still
>> observe your entire DNS activity.
>
> I have explicitly stated "If the ISP hosting the Tor node has resolvers
> for their customers, these can be used as well, *since the ISP sees all
> outgoing traffic anyway*". Are you deliberately trying to misunderstand
> me?
>
> -Ralph
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

Please see the RFC that describes the recursive resolution algorithm:
https://tools.ietf.org/html/rfc1034.

Unbound is a simple recursive resolver. If it does not know the IP, it
has to ask - there is no way around asking. The fact that you do not
know what network links Unbound relies on ("just let it do its magic")
does not make your Exit relay any more secure.

Unbound's upstream requests can be intercepted and used in traffic
correlation just like any other. Yes, Unbound follows the recursive
protocol and works with the hierarchy from the root DNS servers down,
but your ISP can still observe your entire DNS activity. This is very
similar to running dnsmasq configured to work the DNS server hosted by
the ISP (which then performs the recursive functions) - except in my
case there isn't one.

On Sun, Oct 8, 2017 at 10:59 AM, Ralph Seichter <m16+...@monksofcool.net> wrote:
> On 08.10.17 19:48, Igor Mitrofanov wrote:
>
>> My hosting provider runs no DNS servers and recommends using 8.8.x.x,
>> so I have to pick something.
>
> You don't have to pick, and this is not meant to be patronising. Install
> Unbound with the few lines of configuration I posted earlier in this
> thread, and set your /etc/resolv.conf to "nameserver 127.0.0.1". Unbound
> will contact upstream servers as required. You don't have to configure
> *any* upstream servers manually.
>
> See https://en.wikipedia.org/wiki/Domain_Name_System "Address resolution
> mechanism" for what will happen under the hood.
>
> -Ralph
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

My hosting provider runs no DNS servers and recommends using 8.8.x.x,
so I have to pick something.

On Sun, Oct 8, 2017 at 10:22 AM, Ralph Seichter <m16+...@monksofcool.net> wrote:
> On 08.10.17 18:34, Igor Mitrofanov wrote:
>
>> Unless configured otherwise, Dnsmasq chooses a server from the list
>> randomly, so the more servers the operator specifies in dnsmasq.conf,
>> the less traffic each server gets.
>
> The "proper" way, meaning the way resulting in the smallest surface for
> behavioural analysis of the node outside the ISP hosting the node, is to
> not manually configure any upstream servers at all for the caching
> resolver running on the Tor node. That way, only upstream servers that
> are actually required to resolve individual queries are contacted.
>
> If the ISP hosting the Tor node has resolvers for their customers, these
> can be used as well, since the ISP sees all outgoing traffic anyway, but
> I can't think of any reason to use third-party resolvers (especially the
> infamous Google 8.8.x.x) beyond the hosting ISP.
>
> The historic notion of "don't contact upstream resolvers directly" from
> a time where traffic was expensive is no longer valid, especially for a
> Tor node where the key goal is to make it harder for third party actors
> to analyse what the node is doing.
>
>> I have not seen any research papers that would indicate that the cost
>> of running a full DNS server on an Exit relay is worthwhile and that
>> it improves anonymity substantially more compared to a lightweight
>> cache resolver.
>
> I don't know what you call "a full DNS server"? A caching resolver
> should, by its nature, contact all upstream nameservers as required,
> including the root zone servers. There is no need for Unbound, BIND or
> similar resolver software to delegate queries only to a manually
> configured and therefore limited list of nameservers. Just let these
> resolvers do their job. From what I see on my nodes, the cost of Unbound
> is negligible, compared to what Tor itself requires.
>
> Unless you can produce research papers that show it is *not* worth
> letting my resolvers contact upstream nameservers as they consider
> necessary, I'll stick to advocating what I wrote above. ;-)
>
> -Ralph
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

Toralf, thanks for the data. Has that 10% stabilized, or is it still
growing for your node?

On Sun, Oct 8, 2017 at 9:54 AM, Toralf Förster <toralf.foers...@gmx.de> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 10/08/2017 06:34 PM, Igor Mitrofanov wrote:
>> With a large-enough cache and sufficient uptime dnsmasq effectively
>> becomes a mini-DNS server that stores IP addresses for the vast
>> majority of sites that Tor users ever visit.
>
> NAK, just 10,000 addresses can be cached.
>
> The stats of dnsmasq my exit relay shows after 6 hours :
>
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: cache size 1, 203238/1102103 cache 
> insertions re-used unexpired cache entries.
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: queries forwarded 444146, queries 
> answered locally 42117
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: DNSSEC memory in use 120768, max 
> 173280, allocated 84
>
> so just 10% of all DNS queries are cached, the vast majority is forwarded to 
> the DNS server of my ISP.
>
> - --
> Toralf
> PGP C4EACDDE 0076E94E
> -BEGIN PGP SIGNATURE-
>
> iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdpYUxccdG9yYWxmLmZv
> ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTlOlAP0RNGzXHqM7blXf/TmaAagKoWW2
> Gb2/YGRwC0yeZ+qOAAD+P7EN2GQ5bdpoVG4eBq17Hq3y6Qoegyh/CRyI5rZWQpc=
> =Yd69
> -END PGP SIGNATURE-
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

Unless configured otherwise, Dnsmasq chooses a server from the list
randomly, so the more servers the operator specifies in dnsmasq.conf,
the less traffic each server gets. This increases the diversity of DNS
requests, complicating traffic analysis for any adversary that
controls some, but not all, links between the host and the DNS
servers.

With a large-enough cache and sufficient uptime dnsmasq effectively
becomes a mini-DNS server that stores IP addresses for the vast
majority of sites that Tor users ever visit. With little to no
outgoing DNS traffic from the host, DNS-assisted correlation
("DefecTor") becomes impractical for anyone, including the hosting
provider. Combined with very low resource utilization of dnsmasq,
running it on an Exit node improves anonymity for the majority of Tor
users at almost zero cost. The only scenario where a cache does not
help is resolving rare hostnames that nobody has visited yet, but even
in this case, with multiple upstream DNS servers only an adversary
controlling the AS is guaranteed to intercept the request.

I have not seen any research papers that would indicate that the cost
of running a full DNS server on an Exit relay is worthwhile and that
it improves anonymity substantially more compared to a lightweight
cache resolver. If you know of any, please share, and I'll be happy to
change my mind.

- Igor

On Sun, Oct 8, 2017 at 1:03 AM, Ralph Seichter  wrote:
> On 08.10.17 09:47, Toralf Förster wrote:
>
>> IMO there's absolutely no advantage of using external DNS servers.
>
> "No advantage" is putting it too mildly. Manually specifying upstream
> servers runs contrary to the very reason to have a resolver on the Tor
> node in the first place, which is to only involve the necessary minimum
> set of servers for each query.
>
> -Ralph
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

[Igor Mitrofanov]

Here's what I personally recommend: 

 

1. Make sure that /etc/resolv.conf contains 127.0.0.1 only. Ensure you have no 
DNS servers specified in /etc/network/interfaces. This will ensure that all DNS 
traffic will go through dnsmasq.

2. You can start by editing /etc/dnsmasq.conf as follows:

 

# Only listen on loopback

interface=lo

bind-interfaces

 

# DNS servers

no-resolv

no-poll

no-hosts

server=8.8.4.4

server=8.26.56.26

server=74.82.42.42

server=64.6.64.6

server=8.8.8.8

server=8.20.247.20

server=64.6.65.6

 

# Performance

cache-size=1

dns-forward-max=2048

 

# No DHCP or TFTP

no-dhcp-interface=1

 

3. The value of dns-forward-max is just a rough guess for a high-capacity Exit 
relay. Please feel free to tune it.

4. Use ss or netstat to make sure that dnsmasq only opens port 53 on the 
loopback interface (lo, 127.0.0.01) and does not listen on any external network 
interfaces.

5. If you have iptables configured, please make sure you allow traffic to port 
53 from 127.0.0.1.

6. You can find the IP addresses of some public DNS servers here: 
https://www.lifewire.com/free-and-public-dns-servers-2626062.

7. Consider adding any DNS servers that your ISP may provide (ask them).

8. PLEASE exclude any DNS servers that attempt to censor/filter any web 
addresses (such as “Comodo Secure DNS”).

9. I recommend picking DNS servers with the lowest ping latency to your Tor 
relay (i.e. try pinging them manually).

 

Thanks for running a Tor relay!

- Igor

 

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
jpmvtd...@laposte.net
Sent: Saturday, October 7, 2017 10:39 AM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] dnsmasq configuration for an exit relay (Debian)

 

Hello,

 

I am looking for instructions on how to configure dnsmasq on a Debian exit 
relay (in order to cache DNS queries).

 

It looks like this package could introduce vulnerabilities if not handled 
properly, because it provides more than just local DNS cache.

 

If I had to install it without any advice, I would do this :

 

 

1) Install dnsmaq package with the command  "aptitude install dnsmask" .

 

2) Make sure that the first line of the file /etc/resolv.conf is  "nameserver 
127.0.0.1"  (see  <https://wiki.debian.org/HowTo/dnsmasq#Local_Caching> 
https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ).

 

3) Make sure that the file /etc/dnsmasq.conf contains the line  
"listen-address=127.0.0.1"  (to restrict dnsmasq to the local system).

 

4) Set the cache size to 1 by adding or editing this line  
"cache-size=1"  in the file /etc/dnsmasq.conf  (as suggested by Igor 
Mitrofanov here  
<https://lists.torproject.org/pipermail/tor-relays/2017-August/012708.html> 
https://lists.torproject.org/pipermail/tor-relays/2017-August/012708.html ).

 

5) Reboot (is it necessary ?).

 

 

Does anyone think that this procedure could start a daemon listening on a port 
of my server ? Or is it safe to do this on my exit relay ?

 

Regards

___

tor-relays mailing list

 <mailto:tor-relays@lists.torproject.org> tor-relays@lists.torproject.org

 <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> 
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH brute force attempts to connect to my Middle Relay IP address

[Igor Mitrofanov]

The instance I use for administrative purposes (SSH and APT) is a separate
one, client-only.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf
Of teor
Sent: Wednesday, October 4, 2017 5:49 AM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] SSH brute force attempts to connect to my Middle
Relay IP address


> On 4 Oct 2017, at 02:26, Igor Mitrofanov <igor.n.mitrofa...@gmail.com>
wrote:
> 
> I have setup a (private, key-based) Tor hidden service for SSH
administration. It works well and leaves no extra open ports to attack.
> 
> If you also take advantage of package updates over Tor (via the local 
> SOCKS5 proxy that any Tor instance provides)

We don't recommend that you run a client and hidden service on the same tor
instance. It makes traffic correlation easier, because your traffic all goes
through the same guard. (There are probably some other reasons,
too.)

Depending on your threat model, this might not be an issue for you.

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n



___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] SSH brute force attempts to connect to my Middle Relay IP address

[Igor Mitrofanov]

I have setup a (private, key-based) Tor hidden service for SSH administration. 
It works well and leaves no extra open ports to attack.

If you also take advantage of package updates over Tor (via the local SOCKS5 
proxy that any Tor instance provides) the only non-OR incoming traffic you need 
to allow is an occasional NTP (UDP) time sync, plus ICMP 3/4 (fragmentation 
required). If you drop everything else, fail2ban becomes unnecessary.

The botnet can still flood the host with SYN requests, ORPort connections, etc. 
but brute-force attacks on SSH are no longer a risk.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Fr33d0m4all
Sent: Tuesday, October 3, 2017 11:03 PM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] SSH brute force attempts to connect to my Middle Relay IP 
address

Hi,
My Tor middle relay public IP address is victim of SSH brute force connections’ 
attempts and the attack is going on since two weeks ago. It’s not a problem, 
the server that is listening with SSH on the same IP address than my Tor relay 
blocks the connections and bans the IP addresses (with Fail2Ban) but I just 
wanted to know if there is some campaign of attacks carried against Tor 
relays.. are you experiencing the same? The attacks are carried on with a 
botnet given the large amount of different IP addresses that I see in the logs.

Best regards,
   Fr33d0m4All
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Igor Mitrofanov]

If it's important enough to do on a single relay, it's important
enough to do it across the entire network. I bet there are, and will
always be, plenty of exit node operators not reading this email list,
or not planning to do anything, or not configuring everything
properly, etc.

On Tue, Sep 12, 2017 at 5:25 PM, Scott Bennett  wrote:
> Ralph Seichter  wrote:
>
>> On 12.09.17 23:43, Roman Mamedov wrote:
>>
>> > > I take it you're being ironic?
>> >
>> > Guess I failed at doing that well, if you had to clarify. (Or maybe
>> > you didn't read my entire message.)
>>
>> I did read it. Just the pitfalls of non-verbal communication, and I'm
>> also not a native English speaker. ;-)
>>
>> > Running your own authoritative nameservers is laudable as well, but the
>> > current discussion is about recursive resolvers. You know, the likes of
>> > 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic".
>>
>> If you read *my* messages in this thread, you'll find that I am fully
>> aware of this. I even mentioned Google's infamous resolver by IP. :-)
>> I came across one ISP so far which does not provide resolvers for their
>> customers but points resolv.conf to Google's servers. Not good.
>>
>> > Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed
>> > set of a few upstream DNS resolvers; you need 'unbound' which IS a full
>> > independent DNS resolver itself.
>>
>> Yeah, I use Unbound and BIND myself, with the former of course being
>> much more frugal in terms of resource requirements. Easy to set up, too.
>>
>  I'd like to add a note here for FreeBSD users.  In addition to unbound
> or any of the other resolvers available in the ports tree, DNS queries for
> name-to-address resolution can be further reduced by a small caching utility
> that is in the base system, called nscd(8).  Check the man pages for
> nscd.conf(5) and nsswitch.conf(5) to see how easily you can configure its use.
> nscd can also cache other, non-DNS queries' results as well (e.g., NIS).
> After setting up nsswitch.conf and nscd.conf (just a few lines each), remember
> to add a line that says, "nscd_enable=YES", to /etc/rc.conf and then (as root)
> give the following command.
>
> # service nscd start
>
> Note that the rc.conf entry will take care of starting nscd(8) after a reboot.
> The command shown above is only necessary when starting nscd at other times.
> nscd's caching service gets inserted between the resolver(3) and its queries
> of local DNS caches or distant name servers, and it is quite fast, but it
> serves only the machine it runs on.  Further, it maintains per-user caches for
> each type of data.  Any user can flush his cache of one type of data or all
> types of data.  root also has the option of flushing all of the per-user
> caches by type of data or all types of data.
>  Here is an example of an nscd configuration (nscd.conf).
>
> threads 4
> enable-cache passwd yes
> # enable-cache group yes
> enable-cache hosts yes
> enable-cache services yes
> enable-cache protocols yes
> enable-cache rpc yes
> enable-cache networks yes
> suggested-size hosts 2111
> keep-hot-count hosts 4096
> positive-policy hosts lfu
> suggested-size services 1123
>
> And here is nsswitch.conf to go with the above.
>
> group: files
> group_compat: nis
> hosts: cache files dns
> networks: cache files
> passwd: cache files
> passwd_compat: nis
> shells: cache files
> services: compat
> services_compat: nis
> protocols: cache files
> rpc: cache files
>
> Note that the only lines in each that pertain to the current discussion
> are the lines that refer to hosts.  The rest are for caches of other data.
> As you can see, configuring this high-speed, local-service-only caching
> daemon is trivially easy and brief and requires installation of *no* other
> software.  It can be used with or without a caching name server or other
> caching resolver software.
>
>   Scott Bennett, Comm. ASMELG, CFIAG
> **
> * Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
> **
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."   *
> *-- Gov. John Hancock, New York Journal, 28 January 1790 *
> **
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Igor Mitrofanov]

I wonder if these are all half-measures, and Tor needs a first-class solution 
to the DNS weakness.

Every Tor relay can have a simple resolver built-in, and/or perhaps all Tor 
relays could be running a DHT-style global DNS cache.
In case of a cache miss, the exit relay could build a circuit to another relay 
and ask it to query core DNS servers on its behalf.

Alternatively, the Tor community could run our own DNS servers, and every exit 
node would use those by default.

...I have seen some papers discussing DNS-assisted traffic correlation attacks, 
but I still don't know how serious that threat is.
I am basically not sure if DNS is a high-priority vulnerability right now, or 
just a distraction.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
Ralph Seichter
Sent: Tuesday, September 12, 2017 1:25 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

On 12.09.17 22:11, jpmvtd...@laposte.net wrote:

> My idea is designed to protect the exit node against a DNS attack from 
> the owner of the DNS server. Not from the ISP or an attacker 
> monitoring the traffic going in and out of the ISP data center.

I'm not certain what you consider a "DNS attack".

Many exit node operators run a caching DNS resolver on their exits, which is 
easily done. Lacking that, you can use the resolvers run by your ISP, who can 
monitor all outbound traffic anyway, as I mentioned.

-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] What causes circuits to collapse?

[Igor Mitrofanov]

Hi,

I have configured a Tor bridge to go through a particular Tor guard
relay (that I also own), as an experiment.
Upon initialization I am getting this warning:

"Your guard [fingerprint] is failing an extremely large amount of
circuits. This could indicate a route manipulation attack, extreme
network overload, or a bug. Success counts are 52/275. Use counts are
67/67. 268 circuits completed, 0 were unusable, 217 collapsed and 1
timed out. For reference, your timeout cutoff is 60 seconds".

Both relays are running Tor 3.0.10.

I have never received this warning before. How do I interpret the
numbers above, and debug the issue?

The guard is far from saturating its network bandwidth. It has 98%
idle CPU and plenty of free memory. I am not running any attacks
against it. It does use a tuned-up sysctl.conf but I have never had
any problems with it. "tcpdump icmp" does not show anything
interesting. There are no warnings in the guard's log.

Thanks,
Igor
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Igor Mitrofanov]

The DNS issue is in the "long tail" - rare/unique websites are unlikely to be 
cached, yet they likely represent the most interesting targets.
I do agree that running dnsmasq (or a similar caching resolver) is probably 
sufficient to make DNS attacks too unreliable to invest in. I am not sure why 
this is not an officially-recommended privacy-enhancing practice.

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
eric gisse
Sent: Monday, August 7, 2017 12:56 PM
To: tor-relays@lists.torproject.org
Subject: Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

...and what is dnscrypt supposed to do for a relay? where are the DNS queries 
themselves supposed to come out?

i'm yet to hear why a big caching nameserver is insufficient. i'm doing 30mb/s 
on an exit node. here's my rndc stats:

[View: internal]
86635983 IPv6 queries sent
76987085 IPv6 responses received
 4075735 NXDOMAIN received
 1085798 SERVFAIL received
   17517 EDNS(0) query failures
 5684046 truncated responses received
16097299 query retries
 9670300 query timeouts
69955769 DNSSEC validation attempted
33207889 DNSSEC validation succeeded
36673375 DNSSEC NX validation succeeded
   52281 DNSSEC validation failed
 6114026 queries with RTT < 10ms
37261728 queries with RTT 10-100ms
31296765 queries with RTT 100-500ms
 1128740 queries with RTT 500-800ms
 1159610 queries with RTT 800-1600ms
   26152 queries with RTT > 1600ms
  86 active fetches
  31 bucket size
 279 REFUSED received
53264941 COOKIE send with client cookie only
  340790 spilled due to server quota

first off, look at the RAW AMOUNT OF QUERIES. i last restarted the nameserver 
on July 28th for a maintenance reason. do you see the scale of busy i am 
talking about now?

[View: internal (Cache: internal)]
   820788430 cache hits
   102325730 cache misses
   15224 cache hits (from query)
   232971711 cache misses (from query)
   0 cache records deleted due to memory exhaustion
57238152 cache records deleted due to TTL expiration

now, look at the cache rate. the hit rate is currently about 87%. i don't think 
my internal projects are even a rounding error on nearly a billion DNS queries 
in not even two weeks.

nearly 90% of a tor user's dns queries will never leave the exit node.

i strongly feel you guys are overcomplicating this. worrying about too many 
queries going to the same AS, dnscrypt, christ on a crutch.

if you are going to advocate for a more complex, failure prone, difficult to 
maintain solution then you need to articulate the benefits of it. the solutions 
i am seeing are.silly, to put it mildly. there's standardized and robust 
tools people can use. use them.






On Mon, Aug 7, 2017 at 12:04 PM, Chuck McAndrew  
wrote:
> I was wondering about how beneficial DNS Crypt or DNS Privacy would be 
> for relays. Is anyone using any kind of encryption for their DNS 
> queries on their relay?
>
> https://networkfilter.blogspot.com/2017/04/be-your-own-vpn-provider-wi
> th-openbsd-v2.html#dns shows how to set up multiple dnscrypt proxies 
> on openbsd for redundancy (with a local instance of unbound as well). 
> Any benefit to doing something like this?
>
> Regards
> Chuck
>
> On 08/06/2017 10:47 PM, Philipp Winter wrote:
>> On Sun, Aug 06, 2017 at 04:03:53PM -0400, Dennis Emory Hannon wrote:
>>> Guide is meant for debian/linux users 
>>> http://backplanedns.org/TOR_exit_dns_resolver_howto.htm
>>
>> I think the solution to Google seeing so many DNS requests is more 
>> nuanced.  A single organisation seeing that many request is certainly 
>> problematic but so is random ASs on the Internet seeing the same 
>> requests -- which is what happens when you resolve a domain name on 
>> the exit relay.  We also want low query latency and integrity, which 
>> Google's resolver happens to be good at.
>>
>> While we can quantify all these properties, there is no easy way to 
>> compare them against each other.  Do you prefer an exit relay that 
>> uses Google or one that exposes your queries to numerous ASs, and is 
>> also more likely to be poisoned?
>>
>> On a more optimistic note, the DNS privacy project is doing some 
>> promising work that exit relays may benefit from:
>> 
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> 

Re: [tor-relays] ORSN DNS servers vs OpenNic

[Igor Mitrofanov]

Check this list and choose the ones with the lowest ping from your node:
https://www.lifewire.com/free-and-public-dns-servers-2626062

Make sure to avoid DNS servers marketed as "secure" (for example, do
NOT use "Comodo Secure DNS") since they perform arbitrary
censorship/redirection. Also, do not use Google as it already sees
>30% of all Tor exit traffic.

On your node, run dnsmasq with a large (1) cache as a fast and
secure alternative to running a full DNS server. That can prevent some
DNS-based timing attacks.


On Fri, Aug 4, 2017 at 7:29 AM, niftybunny
 wrote:
> I got lots of  "[WARN] eventdns: All nameservers have failed" with my own
> DNS server. With the 4 DNS servers I posted here a few minutes ago, I never
> saw this warning again.
>
> niftybunny
>
> “Cheery was aware that Commander Vimes didn't like the phrase 'The innocent
> have nothing to fear', believing the innocent had everything to fear, mostly
> from the guilty but in the longer term even more from those who say things
> like 'The innocent have nothing to fear'.”
>
> ― Terry Pratchett, Snuff
>
> On 4. Aug 2017, at 16:23, Matt Traudt  wrote:
>
>
>
> On 8/4/17 10:11, Chuck McAndrew wrote:
>
> What are the best DNS servers to use for Privacy? I have been using
> OpenNic Project servers which don't do logging, but recently found out
> about the Open Root Server Network (ORSN) and have been considering
> using them as well. Does anyone have any thoughts, positive or negative,
> about either of these? Are there better public DNS servers to use?
> Thanks
> Chuck
>
>
> If I remember the following paper correctly, the best case scenario
> would be for each exit to run its own DNS resolver. You should read it
> and make sure I remember correctly ;)
>
> https://freedom-to-tinker.com/2016/09/29/the-effect-of-dns-on-tors-anonymity/
>
> https://nymity.ch/tor-dns/tor-dns.pdf
>
> Matt
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit flag and port 6667 vs 6697

[Igor Mitrofanov]

> Port numbers and TLS ore orthogonal: port 443 can be used for cleartext,
> and port 80 for encrypted traffic. In the case of IRC, it's quite common
> for 6667 to be used with TLS.

When a relay operator uses exit policies, I believe they express an
intent to block certain types of applications, and not just ports
those applications typically run on. They mean to block HTTP when they
block port 80, and they mean to allow HTTPS when they allow port 443.
Exit relay who use anything but "accept *:*" engage in
application-level traffic censorship to balance their risk with their
contribution (if this is not a form of censorship, what are exit
policies really for?).

Both port-based exit policies, designed when ports meant much more
than they do today, and the definition of the exit flag, seem
obsolete. Ports no longer allow Tor users or relay operators to manage
their risks well, and the exit flag policy does not allow the Tor
community to protect the network against P2P abuse and optimize it in
any meaningful way.

For example, as a Tor user, how can I express my desire to only use
exit nodes that refuse to see any plaintext traffic - where's that
checkbox in the Tor browser? As an exit relay operator, how can I
minimize the abuse risks often associated with insecure protocols? As
a member of the Tor community, how can I understand why making
_historically_-plaintext traffic on port 6667 (as opposed to usually
encrypted traffic on ports 993, 995, 587, 6697) part of the minimum
contribution is optimal for the network?

Long-term, I believe that Tor will need to move away from port-based
policies to standard / verified / signed deep-packet-inspection
plugins. I do have a short-term proposal though (below).

> The current Exit flag requires 2 ports out of [80, 443, 6667].
> Can you clarify what the two options are that you are suggesting here?

For starters, I would propose making it possible to run an Exit node
without relaying traffic to ports designed to carry insecure
protocols. That would mean a change as simple as "two ports from [80,
443, 6667-OR-6697]". Later, I would ask the Tor project to study the
traffic (by port numbers) and re-examine the port-based exit policy
system in general.

> And the Exit operator would need to set up DNSCrypt or similar.
> Otherwise Exit DNS requests are trivially monitorable.

I am using dnsmasq with a large (65536) cache and several 1ms-latency
upstream DNS servers it randomly picks from. I believe it should be
sufficient to complicate the DNS-assisted timing attacks that I am
aware of.

Thanks
- Igor

> Message: 4
> Date: Wed, 5 Jul 2017 08:08:25 +1000
> From: teor 
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] Exit flag and port 6667 vs 6697
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
>
>> On 5 Jul 2017, at 05:29, grarpamp  wrote:
>>
 ...

 My current, rather paranoid, list of accepted ports looks like this:
 20-21, 53, 443, 993, 995, 6667. I am not sure how useful this is to
 Tor, and whether I will actually avoid complaints, but I guess I can
 only wait and see.
>>>
>>> Most Tor traffic is HTTP or HTTPS, and the HTTPS proportion is growing.
>>> So this is useful.
>>>
 My question is about 6667 - should Tor's 'Exit flag policy' allow 6697
 (IRC encrypted over SSL) as an alternative to 6667? I would rather
 support people using 6697, if I had the choice.
>>>
>>> Some IRC services allow or require SSL on 6667, others require it on
>>> 6697. Why not enable both?
>
> I really do think this is a good way to tackle this issue:
> we should encourage relay operators to enable *both* 6667 and 6697.
>
> The flag minimum requirement really is a minimum.
>
>>> So I can't see a strong case for switching to 6697, given that the Exit
>>> flag is only a hint to relay operators about the minimum useful ports.
>>
>> 6667 cleartext is there because tor is old... it was widely prevailing then.
>> 6697 TLS became widespread much later, especially post Snowden.
>>
>> What does survey of IRC nets regarding TLS capabilities look like today?
>> Do users have some need to connect, out via exit, to [any particular]
>> cleartext IRC services, for something that TLS IRC services do not provide?
>> Do we continue endorsing cleartext upon operators who seek minimums
>> and/or proffer to carry non-monitorable e2e traffic to avoid legal issues?
>
> Port numbers and TLS ore orthogonal: port 443 can be used for cleartext,
> and port 80 for encrypted traffic. In the case of IRC, it's quite common
> for 6667 to be used with TLS.
>
> And the Exit operator would need to set up DNSCrypt or similar.
> Otherwise Exit DNS requests are trivially monitorable.
>
>> Does cleartext insistance therein funnel users into choosing possibly
>> harmful cleartext transports due to better speed / latency / probability of
>> successful exit paths?
>> What are