tor-relays June 2016

tor-relays@lists.torproject.org

59 participants
40 discussions

Re: [tor-relays] [tor-talk] Unrecommended old 0.2.4.x and 0.2.5.x versions
by nusenu 30 Jun '16

30 Jun '16

(replying on a (more) public list) Roger Dingledine wrote: > I just removed > "0.2.4.23,0.2.4.24,0.2.4.25,0.2.5.8-rc,0.2.5.9-rc,0.2.5.10" > from the set of Tor versions that moria1 recommends as acceptable. glad to see this move and looking forward to the day where 0.2.4.x relays (currently at 7.8% cw) will no longer be included in consensus and all these short lived "default" windows bots disappear with it http://article.gmane.org/gmane.network.onion-routing.ornetradar/1452 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1449

1 0

Usability Improvements for Atlas (was Re: Globe is now retired)
by Iain R. Learmonth 30 Jun '16

30 Jun '16

Hi All, On 29/06/16 09:56, Karsten Loesing wrote: > tl;dr: Globe is now retired in favor of an improved Atlas. Atlas is improved, but I'd like to improve it further. I've been tackling #6787 looking to improve the homepage and make Atlas easier to use for someone that isn't already a Tor expert. The changes I'm proposing in my fix for #6787 [1] do make some noticeable UI changes and I just want to gather some opinions on whether or not Atlas users feel that this is taking it in the right direction. The "Top 10 Relays" page was added to Atlas in order to make sure that functionality was not lost when shutting down globe. (See #5430 [2]) In my proposed patch, I'm also adding an "Authorities" page and adding text to both of these pages to explain what you're seeing. These are linked from the homepage, and from the top navbar. I'm also moving the introduction and explanation of the Atlas features from the About page to the homepage and introducing a new Help page that explains the details that are found in the relay details pages. You can find a live example of this patch at: https://irl.github.io/atlas/#/ and a full list of changes are detailed in #6787. Please let me know if you can see any reason to not merge this, or if you have any suggestions for small changes before merging. Thanks, Iain. [1]: https://trac.torproject.org/projects/tor/ticket/5430 [2]: https://trac.torproject.org/projects/tor/ticket/6787

5 14

Bridge torrc custom + socks
by Petrusko 29 Jun '16

29 Jun '16

Hey, Starting to set up some Bridges behind some routers, if possible at several locations. Since last time, I've found some useful informations, but I'm not 100% sure if torrc config is ok. So the goal is : - bridge - obsfproxy to help censored people - SOCKS available for LAN computers, to redirect traffic to Tor Here the torrc file I've tuned : ####START#### SocksPort 192.168.1.10:9050 #LAN IP SocksPolicy accept 192.168.1.0/24 #Socks available for LAN computers SocksPolicy accept 127.0.0.1 #Socks available for localhost too SocksPolicy reject * Log notice file /var/log/tor/notices.log ORPort 10000 Address x.x.x.x #WAN IP Nickname Test01 #name of the bridge node ContactInfo me(a)mail.com DirPort 10001 ExitPolicy reject *:* BridgeRelay 1 PublishServerDescriptor bridge AuthoritativeDirectory 1 BridgeAuthoritativeDir 1 ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed ServerTransportListenAddr obfs3 0.0.0.0:10002 ExtORPort auto ####END#### In the router/box, I'll open/forward those 3 TCP ports from the WAN to the LAN server IP : ORPort : 10000 DirPort : 10001 Obfs : 10002 Test with a LAN client Firefox connecting with Socks is ok, IP seen is a Tor exit... Torcheck says the current browser is using Tor. But how to know if censored people can use this bridge ? (I'll test it from an open wifi hotspot in future...) Is this one is available in the list at bridges.torproject.org ? I see some log lines about stats files... where will it possible to check this bridge utilization ? If someone wants to correct this torrc file, please don't hesitate ! Is there something to add, to remove ?! Another eye is always cool to be sure ! Many thx for your lights :) -- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

2 3

If you get weird crashes, that might be why
by pa011 26 Jun '16

26 Jun '16

On start-up my Exit (Linux 3.16.0-4-amd64) Tor 0.2.7.6 creates this log message: [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 100010bf: Op$bf: OpenSSL 1.0.1k 8 Jan 2015; running with 1000114f: OpenSSL 1.0.1t 3 May 2016). Unfortunately it really crashes ones a day. This seems to be an ongoing problem for years now? Could anyone please give some help - or is there none? Thanks Paul

4 4

Re: [tor-relays] Tor Weather has been discontinued
by l3thal.injecti0n＠gmail.com 24 Jun '16

24 Jun '16

If tor weather isn't running, and tshirt emails aren't being sent out, is someone doing this manually then? How can I help get the show on the road? Not gonna lie, I was really looking forward to the tshirt email as my relay definitely should have earned one about 2 weeks ago. haha. Actually I just donated $100... maybe now I can get a tshirt? https://atlas.torproject.org/#details/1F45542A24A61BF9408F1C05E0DCE4E29F2CB…

8 15

Multiple fingerprints for same IP:Port combo
by simon 22 Jun '16

22 Jun '16

Hi, Is it possible to have multiple Tor-nodes (with different keypair and fingerprint) at the same IP-Port combination? Or does that not work with the Directory implementation? The idea would be to have nodes under an anycast IP, because the anycast network has a lot of unused capacity. Another possibilty is to replicate the same node and re-use the same keypair in multiple physical locations for the same anycast IP, but I'm not sure this is a good idea. Simon

2 1

Opt-In Trial: Fallback Directory Mirrors
by Nick Mathewson 22 Jun '16

22 Jun '16

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in! We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities. Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports. For more information about fallbacks, see: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load. We want relays that expect to be stable for the next 2 years, with: good uptime, the same IP address(es) and port, the same relay identity key, good bandwidth and network connectivity. In December 2015, we created a list of ~400 candidate fallbacks. https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_d… If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.) For the initial fallback release, we will only add your relay if you opt in. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.) all best wishes, & thanks for running Tor!

19 29

Relay Fingerprint Changed After Updates
by Brian Kroll 21 Jun '16

21 Jun '16

Hi All, I had a weird event happen where the fingerprint of my relay changed after updates to the OS. The host is running Debian 8.3 and the Tor version was at 0.2.7.6 at the time of update. Apt was used to update packages and the following packages were installed/upgraded. libapt-inst1.5:amd64 (1.0.9.8.3) libssl1.0.0:amd64 (1.0.1t-1+deb8u2) libidn11:amd64 (1.29-1+deb8u1) libtasn1-6:amd64 (4.2-3+deb8u2) libxml2:amd64 (2.9.1+dfsg1-5+deb8u2) libcairo2:amd64 (1.14.0-2.1+deb8u1) libexpat1:amd64 (2.1.0-6+deb8u3) libglib2.0-0:amd64 (2.42.1-1+b1) libgdk-pixbuf2.0-common (2.31.1-2+deb8u5) libgdk-pixbuf2.0-0:amd64 (2.31.1-2+deb8u5) libgtk2.0-common (2.24.25-3+deb8u1) libgtk2.0-0:amd64 (2.24.25-3+deb8u1) libgtk2.0-bin (2.24.25-3+deb8u1) libnettle4:amd64 (2.7.1-5+deb8u1) libhogweed2:amd64 (2.7.1-5+deb8u1) libksba8:amd64 (1.3.2-1+deb8u1) apt-utils (1.0.9.8.3) libxapian22 (1.2.19-1+deb8u1) locales (2.19-18+deb8u4) openssh-client (1:6.7p1-5+deb8u2) openssh-sftp-server (1:6.7p1-5+deb8u2) openssh-server (1:6.7p1-5+deb8u2) openssl (1.0.1t-1+deb8u2) After the updates completed I checked on the status of the relay and noticed that it was not running and started the Tor process again. After starting the process the fingerprint changed. My relay BrownLine was 9504CB22EEB25D344DE63CB7A6F2C46F895C3686 and now after updates is 9C8A123081EFBE022EF795630F447839DDFDDDEC. I have looked through Tor logs and can find nothing of value but heartbeat notices. I have also reviewed system logs and can find nothing out of the ordinary. Any thoughts on this? Any help would be appreciated. I will also open a bug report if needed. Thanks! //Brian

2 1

Handling abuse - like to get your help please
by pa011 21 Jun '16

21 Jun '16

As I am new to this business could somebody please give me a hint how to best handle such an abuse complain - possibly stop it? Thanks, Regards and a nice weekend. we have detected abuse from the IP address xxx.xxx.xxx,xxx, which according to a whois lookup is on your network. We would appreciate if you would investigate and take action as appropriate. Log lines are given below, but please ask if you require any further information. If you are not the correct person to contact about this please accept our apologies - your e-mail address was extracted from the whois record by an automated process. This mail was automatically generated. Note: Local timezone is +0200 (CEST) /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:50 +0200] "POST /cgi-bin/php-cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:51 +0200] "POST /cgi-bin/php.cgi?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 293 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" /var/log/apache2/access.log:xxx.xxx.xxx.xxx - - [17/Jun/2016:09:25:52 +0200] "POST /cgi-bin/php4?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 404 290 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25"

13 18

[warn] eventdns: All nameservers have failed
by pa011 20 Jun '16

20 Jun '16

Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour. The /etc/resolv.conf contains # Generated by SolusVM nameserver 8.8.8.8 nameserver 8.8.4.4 Is it really best to set only one DNS like specified here https://trac.torproject.org/projects/tor/ticket/11600 ? Or are there better working solutions?

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays June 2016