- tor-relays - lists.torproject.org

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
by jpmvtd261＠laposte.net 12 Sep '17

12 Sep '17

On 12/09/2017 20:25, Ralph Seichter wrote: > 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. > An attacker can try to find what websites a Tor user has visited, by comparing : - the timing of Tor user home connection traffic and - the timing of DNS queries happening on DNS servers controlled by the attacker On this webpage, the author talks about "correlation" attack : https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dns/

2 1

Email suggesting to send DNS requests to a specific open DNS
by jpmvtd261＠laposte.net 12 Sep '17

12 Sep '17

Hello, Recently, I installed a new Tor exit node. A few days later, I received an email on the address given in the node contact information. This email suggests to change the DNS server my node use, and gives me a specific IP address to use. Here is the mail (obfuscated with sharps) : EMAIL BEGIN *********************************** * Sender : info AT backplanedns DOT org * Subject : Your TOR node * Body : ** ** Hello, ** ** I came across your TOR relay on atlas. I run a few relays myself ** along with a bunch of DNS resolvers which are a part of the Open ** Root Server network (ORSN.org) - aimed to fight internet ** censorship and circumvent government surveillance programs ** (ie. prism). ** ** I hope you may be interested in using our anonymous open DNS ** resolvers on your relays. ** ** https://BackplaneDNS.org ** ** Resolver - 172.98.193.4# ** ** Resolver - 162.248.241.9# ** ** ------------------------------------------------------ ** ** Hostmaster@: ** Mr. D##### E#### H##### ** ** Phone: ** +1 (###) ###-#### ** ** E-Mail: ** info AT backplanedns DOT org ** abuse DOT backplanedns DOT org ** ** Linkedin: ** http://linkedin.com/in/d####-######-#########/ *********************************** EMAIL END I think it could be an attack. If this person send this email to every new exit node operators, there may be a small percentage of rookie operators who will make the change. I found this webpage about Tor exit nodes and DNS : https://nakedsecurity.sophos.com/2016/10/05/unmasking-tor-users-with-dns/ What do you think about this email ?

3 2

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
by jpmvtd261＠laposte.net 12 Sep '17

12 Sep '17

On August 7, 2017 20:07:05 UTC, Igor Mitrofanov <igor.n.mitrofanov at gmail.com> wrote: > 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 have an idea to improve the efficiency of this solution (DNS cache). My idea is to make more DNS queries than necessary, in order to hide the useful DNS queries among useless DNS queries. What do you think about this ? A basic implementation of that improvement would be a script run as a daemon that fetches the IP of a random domain name at a random time. The domain name being built from random characters or chosen from a list of valid (rarely visited) domain names. The average number of dummy DNS queries per day being equal to the number of useful DNS queries the exit node has to do per day (it doubles the DNS traffic). The list of valid (rarely visited) domain names needs to be changed over time (one entry at a time). A more advanced implementation of that improvement is to only allow the exit node to perform DNS queries by bunch of three. Of the three queries, two are dummy and random, one is useful. The position of the useful query in the bunch (position 1, position 2, or position 3) is chosen randomly.

2 1

Re: [tor-relays] Email suggesting to send DNS requests to a specific open DNS
by jpmvtd261＠laposte.net 12 Sep '17

12 Sep '17

Thanks. I should have look for previous discussion about this. On 12/09/2017 16:24, Tyler Johnson wrote: > This guy sure is persistent! > > Check out this recent thread: > https://lists.torproject.org/pipermail/tor-relays/2017-September/012934.html

1 0

Re: [tor-relays] Would you also like to have family-level atlas pages?
by Tyler Johnson 12 Sep '17

12 Sep '17

I realize now why I don't tend to voice my opinion on these lists... I'm an idiot :( After seeing the below example, I think it's a great idea. Sorry for the noise On Sep 11, 2017 21:37, "John Ricketts" <john(a)quintex.com> wrote: Roger, The kind folks at Nos Oignons gave me the code. I still have it if you can't find it. https://nos-oignons.net/Services/index.en.html is an example. John On Sep 11, 2017, at 20:55, Roger Dingledine <arma(a)mit.edu> wrote: On Mon, Sep 11, 2017 at 10:10:00PM +0000, nusenu wrote: I suggested family-level pages where an operator of more than one relay can see all the relays of his family including aggregated (stacked) graphs for the graphs that are already available on a per-relay level. Good idea. The Nos Oignons folks had some scripts you can hack together to measure and visualize your group of relays, but I spent a while hunting and I couldn't find it now. While we're doing feature requests, once the "per family" view exists, I would want to use the same view on other groups of relays, like "per country" and "per AS". I can fake some of that with Compass: https://compass.torproject.org/ but it would be great to have it in a site that's maintained. :) Thanks! --Roger _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Would you also like to have family-level atlas pages?
by Tyler Johnson 12 Sep '17

12 Sep '17

Hey everyone, I haven't been a relay operator for very long, so please pardon my ignorance, but doesn't Atlas already link to all family members, where you can click on each and view that relays statistics? I can see the suggested benefit of having all that info on one landing page (so to speak), but I really appreciate the simplicity of the site in its current form. My vote would be for a top 100 (or higher) option in the drop down menu that actually works. Overall, I think the site is great, keep up the great work tor project! Thanks, Tyler On Sep 11, 2017 17:11, "nusenu" <nusenu-lists(a)riseup.net> wrote: Hi, Iain - the atlas maintainer - asked on twitter if relay operators at the relay operators meetup in Montreal have feature requests for atlas [1]. I suggested family-level pages where an operator of more than one relay can see all the relays of his family including aggregated (stacked) graphs for the graphs that are already available on a per-relay level. Before filing this as a trac ticket - as Iain - suggested, I wanted to ask around if others would find that useful as well because it probably makes only sense to implement it if there are more people actually finding it useful. So let us know if you do. thanks, nusenu [1] https://twitter.com/iainlearmonth/status/907003817434271746 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Fwd: Your TOR [sic] node
by Dennis Emory Hannon 10 Sep '17

10 Sep '17

So let me get this straight - Because you don't agree with the way I'm marketing my network I must be malicious and this must be a "social engineering" attack? Seriously guys, put away the tin foil hats. I truly DON'T want to know what people on tor are browsing. If you 'd like to waste your time on baseless assumptions go right ahead. -Dennis

4 3

Fwd: Your TOR [sic] node
by Matt Traudt 09 Sep '17

09 Sep '17

I just got this guy's spam too. It doesn't look like anything anyone said to him last month[0] stuck. His intentions are now very suspicious to me too. I will definitely not be pointing anything at his servers. Matt [0]: https://lists.torproject.org/pipermail/tor-relays/2017-August/012735.html -------- Forwarded Message -------- Subject: Your TOR node Date: Fri, 8 Sep 2017 21:36:14 -0400 From: Dennis Emory Hannon <info(a)backplanedns.org> To: Dennis Emory Hannon <info(a)backplanedns.org> Hello, I came across your TOR relay on atlas. I run a few relays myself along with a bunch of DNS resolvers which are a part of the Open Root Server network (ORSN.org) - aimed to fight internet censorship and circumvent government surveillance programs (ie. prism). I hope you may be interested in using our anonymous open DNS resolvers on your relays. https://BackplaneDNS.org Resolver - 172.98.193.42 Resolver - 162.248.241.94 ------------------------------------------------------ Hostmaster@: Mr. Dennis Emory Hannon Phone: +1 (716) 348-0064 E-Mail: info(a)backplanedns.org abuse(a)backplanedns.org Linkedin: http://linkedin.com/in/dennis-hannon-52236019/

3 2

Rate setting in tor
by r1610091651 08 Sep '17

08 Sep '17

Hi I've a question regarding the rate setting in torrc and tor honoring it. I've set up a tor relay with following rate settings: RelayBandwidthRate 2048 KBytes RelayBandwidthBurst 2048 KBytes But using arm, I'm seeing that tor is not honoring these settings, with bursts frequently exceeding the value. The average rate control seems to be working fine though. [image: image.png] What am I missing? I'm running 0.3.0.10 on Linux. Thanks

6 7

Force OpenSSL AES-NI usage on a VPS without the AES CPU flag passthrough
by Roman Mamedov 06 Sep '17

06 Sep '17

Hello, Today I found that it is possible to force OpenSSL enable the use of CPU AES acceleration even if it doesn't detect the "aes" CPU flag. Many VPS hosts configure their hypervisors in a way that does not have the flag passed through into VPSes, even though all their host nodes surely have CPUs with support for AES-NI. In my experience hosts have not been forthcoming in reconfiguring their systems to include that flag passthrough. But it turns out we can force OpenSSL to believe AES is supported, even if the CPU does not report it. This can be done with the "OPENSSL_ia32cap" environment variable. Searching around, all I found was scenarios to use it for disabling AES-NI (for testing), e.g.: https://mjanja.ch/2013/11/disabling-aes-ni-on-linux-openssl/ I believe the syntax used there applies "xor" over the real flag values, e.g. OPENSSL_ia32cap="~0x200000200000000" to disable AES. But what if you need to force-enable it. Turns out the syntax working for that is simply: OPENSSL_ia32cap="+0x200000200000000" Let's take one VPS box with the aforementioned problem. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : QEMU Virtual CPU version 1.5.3 stepping : 3 microcode : 0x1 cpu MHz : 1695.729 cache size : 4096 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 4 wp : yes flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl eagerfpu pni cx16 hypervisor lahf_lm bugs : bogomips : 3391.45 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: As you can see "aes" is not present. Testing OpenSSL speed in the default configuration. # openssl speed -elapsed -evp aes-128-gcm ... type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-gcm 32332.17k 40365.80k 42265.77k 42376.19k 43196.42k 43401.22k And now we force AES hardware acceleration usage: # OPENSSL_ia32cap="+0x200000200000000" openssl speed -elapsed -evp aes-128-gcm ... type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-gcm 59047.07k 104467.39k 141712.21k 151093.93k 158321.32k 156827.65k Almost 4 times faster! For Tor this leads to higher bandwidth utilization and lower CPU usage (which will actually make your VPS host happier :) But how to apply that to Tor? Well, for some initial testing I just chose to add the following line to /etc/init.d/tor (not using systemd here), right after "#! /bin/bash": export OPENSSL_ia32cap="+0x200000200000000" (but this will get overwritten and removed by the next Tor version upgrade). Seems to work just fine, my CPU usage is half of what it was before, at similar bandwidth levels. So now it has headroom to ramp up further. A word of caution, firstly always test as shown above to verify that it works. I believe if the underlying CPU actually doesn't support AES, all programs trying to use it, including "openssl speed", will crash outright, with an incorrect instruction error, or somesuch. So there is no risk to jeopardize encryption strength or security of Tor. Also even if it works now, it may stop working down the line if the host migrates your VPS to a node with older CPU, one which doesn't support AES. But migrations of customers between do not happen very often, and in fact all CPUs used today in a hosting environment should support AES, as that's been implemented in server (and even desktop) CPUs a very very long time ago. (Apologies for double-post, I realized tor-relays should have been the better place to post). -- With respect, Roman

5 4