- tor-relays - lists.torproject.org

Unable to get Tor exit relay to run - Ubuntu 16.04
by King Queen 28 Jul '17

28 Jul '17

I'd really appreciate some clueful suggestions or help please - thank you. I'm not new to Tor; I have an existing relay I run, https://atlas.torproject.org/#details/ECC3599DDCFE44C3F28AE0C9DC5DE92847D36… , but I am unable to get a new Tor relay up and running on an entirely different VPS. I am running on Ubuntu 16.04 Server on a VPS on https://box.cock.li/ . On first attempt I couldn't get a Tor relay running, so I started again from scratch, getting the VPS administrator to reprovision the VPS from scratch, to no avail. I SSHed in as root, created a user and made it a sudoer, added public key etc. and disabled root admin. Then I SSHed in as the user, installed ntp and ufw, added ports 80 and 443 to ufw, added the Tor respository and key as per https://www.torproject.org/docs/debian.html.en#ubuntu. I installed tor, deb.torproject.org-keyring and arm, and edited torrc such that it reads: SOCKSPort 0 RunAsDaemon 1 ORPort 443 Nickname kingqueencock ContactInfo ROT13 <xvatdhrra(a)ybirf.qvpxvauvfna.hf> DirPort 80 # what port to advertise for directory connections DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily ECC3599DDCFE44C3F28AE0C9DC5DE92847D3602B then the "alternative Reduced-Reduced ExitPolicy" from https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy then sudo service tor restart. For all I can gather, Tor isn't running. There are no files in /var/tor/log. ps aux | grep tor returns nothing other than the grep command. arm shows the "Welcome to the Tor network!" initial relay configuration screen, as does sudo -u debian-tor arm. sudo service tor status ● tor.service - Anonymizing overlay network for TCP (multi-instance-master) Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2017-07-27 19:36:41 UTC; 3s ago Process: 9781 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 9781 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 512) CGroup: /system.slice/tor.service Jul 27 19:36:41 localhost systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Jul 27 19:36:41 localhost systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). root@localhost:/var/log/tor# ls -al total 8 drwxr-s--- 2 debian-tor adm 4096 Jul 27 19:29 . drwxr-xr-x 7 root root 4096 Jul 27 19:29 .. The odd thing is if I reboot my VPS by sudo shutdown -r now and do ps aux | grep tor there is tor running as a root user. root 435 0.0 0.5 44760 5716 ? Ss 19:40 0:00 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config I don't know where that has come from, or if it's a problem. I have had a poke around in init.d and systemd but I am not an expert in those. I am beginning to wonder or suspect the Ubuntu installation image on the VPS may not be entirely clean... If I try to run arm as root, the "new relay" configuration wizard appears and when I quit the tor process isn't running. I'm stuck. Any help very gratefully received. Cheers Doug

3 6

Best practices to move a Tor node?
by Isaac Grover, Aileron I.T. 28 Jul '17

28 Jul '17

Good morning from Wisconsin, What are the best practices with regards to moving a Tor node to a new server in a different country? Is it as simple as securely transferring files to the new server and restarting the Tor service, or are there other procedures to be followed? Thank you in advance. Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

4 6

The Onion Box v4.0.0rc1
by theonionbox＠gmx.com 26 Jul '17

26 Jul '17

1 0

Tor fuzzying with AFL - issues with virt mem
by Toralf Förster 25 Jul '17

25 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do fuzz test the Tor sources with AFL using the script in [1]. Today I was faced with the afl message : - - The current memory limit (47.7 TB) is too restrictive, causing the ... Therefore I re-run this: torproject@mr-fox ~ $ cd ~; for i in ./tor/src/test/fuzz/fuzz-*; do echo $(./recidivm-0.1.1/recidivm -v $i 2>&1 | tail -n 1) $i ; done | sort -n 140647294041983 ./tor/src/test/fuzz/fuzz-hsdescv2 210556434775808 ./tor/src/test/fuzz/fuzz-descriptor 211071855558638 ./tor/src/test/fuzz/fuzz-microdesc 230618232257983 ./tor/src/test/fuzz/fuzz-consensus 272676600806400 ./tor/src/test/fuzz/fuzz-http 275960232411072 ./tor/src/test/fuzz/fuzz-diff-apply 280371168541696 ./tor/src/test/fuzz/fuzz-vrs 281200098803455 ./tor/src/test/fuzz/fuzz-iptsv2 281298748667644 ./tor/src/test/fuzz/fuzz-extrainfo 281456722575360 ./tor/src/test/fuzz/fuzz-diff and was wondering about the bug numbers - a previous run few weeks ago gave me the numbers as seen in [1]: # 40880663 ./tor/src/test/fuzz/fuzz-iptsv2 # 40880757 ./tor/src/test/fuzz/fuzz-consensus # 40880890 ./tor/src/test/fuzz/fuzz-extrainfo # 40885159 ./tor/src/test/fuzz/fuzz-hsdescv2 # 40885224 ./tor/src/test/fuzz/fuzz-http # 40888156 ./tor/src/test/fuzz/fuzz-descriptor # 40897371 ./tor/src/test/fuzz/fuzz-microdesc # 40955570 ./tor/src/test/fuzz/fuzz-vrs Now I do wonder, if the new linux kernel, a new AFL (changed from 2.39b to 2.46b recently) or what else is causing this issue ? [1] https://github.com/toralf/torutils/blob/master/fuzz.sh - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWXT0GhccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTiIAAP9ELskbZFoCyr7Ph/unDdPscZtg YTPdO3S3Z/mLWFemUgD/a+zVQd2BV3ZTY+x92/WAQ741VN8h4DO9ee95X+hu3+w= =pFI9 -----END PGP SIGNATURE-----

2 2

PSA: Run a Tor node, lose access to Chinese IPs
by neel＠neelc.org 23 Jul '17

23 Jul '17

Today, I wanted to try to see how the Internet looks behind the Great Firewall of China. I used a public HTTP proxy list (http://spys.ru/free-proxy-list/CN/) listing Chinese proxy servers (meaning getting into Chinese censorship from the US, not bypassing it in China), and guess what? I was already blocked. Why? I suspect that I was running a Tor relay from my home connection (https://atlas.torproject.org/#details/A20840A16CB658024B0D3A0E3F19A9C0E34C8…) Some Chinese websites do load, but many of those who do usually have a CDN outside the Chinese firewall. For example, I can visit AliExpress from my home computer without Tor, but I can't visit 163.com or 2345.com. While I don't care at all for Chinese websites, there are people who do. If you want to access Chinese websites AND run a Tor relay on the same IP address, you may be screwed. Surprisingly, I can sometimes visit Chinese websites over Tor, but it's about as reliable as having Comcast as your home ISP. Proof: telnet 2345.com Optimum Online 100/35 in Westchester County, NY, home computer on same connection as Tor middle node (https://atlas.torproject.org/#details/A20840A16CB658024B0D3A0E3F19A9C0E34C8…) neel@megora:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@megora:~ % Verizon FiOS 50/50 in Brooklyn, NY, Tor middle node (https://atlas.torproject.org/#details/D5B8C38539C509380767D4DE20DE84CF84EE8…) (this connection isn't exclusive to Tor, it's used when I am in Brooklyn as well): neel@kat:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@kat:~ % Total Server Solutions in Los Angeles, CA (via an ITL VPS), Tor exit node (https://atlas.torproject.org/#details/0D8211D34F29F51D690303E319766E1B7C28B…) neel@us-west:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@us-west:~ % Vultr VPS in New Jersey, non-Tor IP used for this website: neel@newwww:~ % telnet 2345.com 80 Trying 42.62.30.180... Connected to 2345.com. Escape character is '^]'. ^] telnet> quit Connection closed. neel@newwww:~ % It seems that IP addresses used for Tor nodes are blocked by the Chinese firewall, even if the same IP address used for a Tor node is accessing a Chinese website outside of Tor. And the little bit of the Chinese Internet which can be accessed on the same IP address as a Tor node is usually on a CDN outside of the Great Firewall. Keep in mind that this article is also available on my website at this URL: https://www.neelc.org/psa-if-youre-running-a-tor-relay-and-are-accessing-a-… (https://www.neelc.org/psa-if-youre-running-a-tor-relay-and-are-accessing-a-…)

2 1

Traffic Confimration Attacks/ Bad Relays
by Kenan Sulayman 22 Jul '17

22 Jul '17

Thanks for your input, Tim. You are correct that I have not taken into account the IPs which are not in the consensus. My exit nodes are regularly attacked -- what caught my attention was not the fact that an extra gigabit of traffic was flowing in, but rather the way it was (*and still is*, on one node) flowing in. The patterns of the traffic seem unusual, because they are precisely timed windows of traffic: 30 seconds of a about gigabit of traffic, 5 minutes (exactly 302 ± 3 seconds, that is) pause, 15 seconds of a about gigabit of traffic, 3 minutes (181 ± 1 seconds) pause, 60 seconds of a gigabit of traffic, 10 minutes (604 ± 2 seconds). This went on for 8 hours on apx1, apx2 is seeing this still. I'm very sure that there is a reasonable explanation for this, but I can't see the reason any client would behave like this. -- Kenan > > On 22 Jul 2017, at 08:00, Matt Traudt <sirmatt at ksu.edu> wrote: > > > > Now, to my observations and the post that was referred to: > > > > /I clearly failed to clarify/ that the "suspicious" traffic which caught > > my interest was about non-Tor IPs entering the network through my exits. > How do you work out what a non-Tor IP is? > > As pastly nicely put it: /> will never be used as a guard by > > well-behaved tor clients./ > Exits won't be used as long-term Guards, but they will be used as > Entry nodes (or receive connections that look like client connections) > from: > * clients via bridges > * clients with UseEntryGuards disabled, including: > * Single Onion Services (to intro and rend nodes) > * Tor2web (to HSDir, intro and rend nodes) > * clients using them as directory guards or fallback directory mirrors, > * bandwidth authorities, > * Tor relays that aren't in the consensus(es) you're using to work out > what a "non-Tor IP" is, > * Tor relays that have an OutboundBindAddress* option, or a route, that > binds to an IP address they're not advertising in their descriptor. > (Some of these categories might be excluded by position weights, I > haven't checked them all in detail.) > > My observations were made using a utility I built using nDPI and sysdig > > (kernel module). > > > > That is, I have observed about a gigabit of traffic entering my exit > > nodes originating /from non-Tor IPs/, causing connections to be > > initiated to middle nodes. > The most likely scenarios responsible for this volume of traffic are: > * clients with UseEntryGuards disabled, including: > * Tor2web (to a rend node using Tor2webRendezvousPoints) > * Tor relays that aren't in the consensus(es) you're using to work out > what a "non-Tor IP" is, > * Tor relays that have an OutboundBindAddress* option, or a route, that > binds to an IP address they're not advertising in their descriptor. > > I have not claimed evidence to "prove" confirmation attacks. I have > > merely observed nearly a gigabit (on multiple nodes, that is) of inbound > > traffic entering the network through my exit nodes, which does not seem > > very reasonable to do unless the goal is attack hidden services. > Proving an attack would be hard: we'd have to rule out all the > exceptional cases I listed above one-by-one. And check the process used > to identify Tor and non-Tor IPs. > T > -- > Tim Wilson-Brown (teor) > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------

1 0

Traffic Confimration Attacks/ Bad Relays
by 0dayshoppingspree＠tutanota.com 22 Jul '17

22 Jul '17

Hello A few users have detected suspicious activity around certain Relays in the network. There could be Time Confirmation Attacks happening currently on the Live Tor Network. If any Tor dev see this, Please Start Checking The US Relays in the network. -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com

3 3

Re: [tor-relays] tor-relays Digest, Vol 78, Issue 20
by Charlie Luna 22 Jul '17

22 Jul '17

what you feel is wrong are the U.S. Feds (FBI, NSA, etc.) enacting their influence on the Tor network and trying to capture all traffic because the DOJ just announced the take down of AlphaBay on Tor. It's not a good time for anything right now. > On Jul 21, 2017, at 5:17 PM, tor-relays-request(a)lists.torproject.org wrote: > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Re: tor-relays Digest, Vol 78, Issue 19 > (0dayshoppingspree(a)tutanota.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 22 Jul 2017 02:17:07 +0200 (CEST) > From: <0dayshoppingspree(a)tutanota.com> > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] tor-relays Digest, Vol 78, Issue 19 > Message-ID: <KpbduUO--3-0(a)tutanota.com> > Content-Type: text/plain; charset="utf-8" > > Hello. > > I apologize for leaving some of the relevant information out on the 1st email. The relay operator did contact me but im not him. > > Ive seen it from the client side, where all my relays starting with a US bridge automatically connects to 1 or both other nodes which are also in the US. Ive had all 3 of them, Guard Middle and Exit All US Ips over and over and over again. > > Changing bridges only works if the bridge is changed to a non-US IP. As soon as i change the bridge to 1 that hits a US Ip it automatically gives me a middle or exit or both in the US. > > Later in the day i was contacted by a HS operator who said they had also witness strange relay behavior in the last 2 or 3 days. He subsequently has shut down his HS. > > Ive studied Tor for the last 5 years and have been an active penetration tester in the community for the last 2 years. Something feels wrong but i just cant put my finger on it. > > Thank You For Your Time > 0Day > > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com > > 21. Jul 2017 18:00 by tor-relays-request(a)lists.torproject.org: > > >> Send tor-relays mailing list submissions to >> > tor-relays(a)lists.torproject.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> or, via email, send a message with subject or body 'help' to >> > tor-relays-request(a)lists.torproject.org >> >> You can reach the person managing the list at >> > tor-relays-owner(a)lists.torproject.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of tor-relays digest..." >> >> >> Today's Topics: >> >> 1. Traffic Confimration Attacks/ Bad Relays >> (> 0dayshoppingspree(a)tutanota.com> ) >> 2. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) >> 3. Re: 100K circuit request per minute for hours killed my relay >> (Arisbe) >> 4. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Fri, 21 Jul 2017 18:12:25 +0200 (CEST) >> From: <> 0dayshoppingspree(a)tutanota.com> > >> To: <> tor-relays(a)lists.torproject.org> > >> Subject: [tor-relays] Traffic Confimration Attacks/ Bad Relays >> Message-ID: <> Kp_uyMv--3-0(a)tutanota.com> > >> Content-Type: text/plain; charset="utf-8" >> >> Hello >> >> A few users have detected suspicious activity around certain Relays in the network. There could be Time Confirmation Attacks happening currently on the Live Tor Network. >> >> If any Tor dev see this, Please Start Checking The US Relays in the network. >> -- >> Securely sent with Tutanota. Claim your encrypted mailbox today! >> https://tutanota.com >>

1 0

Re: [tor-relays] tor-relays Digest, Vol 78, Issue 19
by 0dayshoppingspree＠tutanota.com 22 Jul '17

22 Jul '17

Hello. I apologize for leaving some of the relevant information out on the 1st email. The relay operator did contact me but im not him. Ive seen it from the client side, where all my relays starting with a US bridge automatically connects to 1 or both other nodes which are also in the US. Ive had all 3 of them, Guard Middle and Exit All US Ips over and over and over again. Changing bridges only works if the bridge is changed to a non-US IP. As soon as i change the bridge to 1 that hits a US Ip it automatically gives me a middle or exit or both in the US. Later in the day i was contacted by a HS operator who said they had also witness strange relay behavior in the last 2 or 3 days. He subsequently has shut down his HS. Ive studied Tor for the last 5 years and have been an active penetration tester in the community for the last 2 years. Something feels wrong but i just cant put my finger on it. Thank You For Your Time 0Day -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 21. Jul 2017 18:00 by tor-relays-request(a)lists.torproject.org: > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Traffic Confimration Attacks/ Bad Relays > (> 0dayshoppingspree(a)tutanota.com> ) > 2. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) > 3. Re: 100K circuit request per minute for hours killed my relay > (Arisbe) > 4. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Jul 2017 18:12:25 +0200 (CEST) > From: <> 0dayshoppingspree(a)tutanota.com> > > To: <> tor-relays(a)lists.torproject.org> > > Subject: [tor-relays] Traffic Confimration Attacks/ Bad Relays > Message-ID: <> Kp_uyMv--3-0(a)tutanota.com> > > Content-Type: text/plain; charset="utf-8" > > Hello > > A few users have detected suspicious activity around certain Relays in the network. There could be Time Confirmation Attacks happening currently on the Live Tor Network. > > If any Tor dev see this, Please Start Checking The US Relays in the network. > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com >

1 0

Necto.onion relays (Necto4 etc)
by Geoff Down 21 Jul '17

21 Jul '17

Dear operator of relays Necto4 etc. Please remove OpenDNS filtering of any sort from your exit relays. Note that abuse-team(a)necto.onion (as per your port 80 page) is not a routeable email address. GD -- http://www.fastmail.com - IMAP accessible web-mail

1 0

*.old files in ./keys are too new
by Toralf Förster 19 Jul '17

19 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do wonder, why the *.old files are newer than their counterparts: - -rw------- 1 tor tor 887 Jul 15 21:51 secret_onion_key - -rw------- 1 tor tor 96 Jul 15 21:51 secret_onion_key_ntor - -rw------- 1 tor tor 96 Jun 17 21:30 secret_onion_key_ntor.old - -rw------- 1 tor tor 887 Jun 17 21:30 secret_onion_key.old - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWW+pNRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTsBLAP91Hst68PmoK3y6e5v3xBrKqNjD CW0a9Qn6vDj7O0EsFQD8DmPvK2xgIO6N4G2vsR+Beb5Py+CZoX93PtPBz/xVxNM= =nECn -----END PGP SIGNATURE-----

4 3

Strange log in a middle relay "Gateway Time-out"
by Petrusko 18 Jul '17

18 Jul '17

Hey! Got a strange log from outer space, on a middle relay... :s [log] Jul 17 04:31:24.000 [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.175.225:80' while fetching "/tor/server/d/679188844BFECBF0491F10692096A90C13C1EDD8+6A5F00758269A51C369C46480B82FD43F70A438+6D27FA6BC18185DFAFBABF72161BC9B5B851AE8F+6E4E9C532DF6B0B0A90A7259E77E963B4241F2D3+6E91C50C8222867DEE1638656CFC463A6A3B8A37+6E9421537D55BD56CC2A268B8478CBD1415ADE6+6F4D319593BFB0C06B14EB61478AF5BFCD8B442E+70B0CF367CF467C9562FC3A0C83EA3DA84659CDB+70ED5E2B880DB1A7C7F234AC28A1A78A9E40EA10+7133723103B5A9F9D77241A5F803C294A4B67185+71652BA723790D0C5000FEFC845D52A26C9BADC+7260088E17EA292064FBAD874BC0423C8AB925FB+74A5A26A2B41A347DE302DB9EF62AD018D6787FA+74C48EFF7EC8E9D49CB3C38F14B5BD96EAFD51B4+75075F3519ACB31171C02A3E70451878A0C01730+75269D293DB040608C694109B0A8B729FA94D12+75E63DB58F643AEFAF6E17CA38A77494FC45DF5D+75E95EAA24B11F59B8F06837F0B38743C7ED58A3+76F12392DA75F704E1759C8A9FA76007C4F2D82C+77B8B0538AD339DCB296E6C2A4DDA048E24F346+77BF48E4B80803041FD1357B7BB836B6394F55A4+78634FB9C7A08DCEFB3C5423C23A5F962FEB9B4A+7CE7931B070AAC9687696CEDD3CFDF822A8279D4+7D00BFC08346E223B58E3774BED6B1C9D118F5E0+7D886BE5360A86BE3AF6D6BDE95C64CD640E522+7F09C91D218339A6E07328D64429E7E30747EB6A+7FFDFBFFE767FC758A6D29ADAA84D11D908F344B+80B4E3A317A16EC89C1525D6838E7A619DBD9C47+80D1078EC53308F507AF3B1515A45E14680DFAFC+0FCEF96681C73FEA65D847349B7CBF9A46ED8E6+817ADF44836E6E71C365FEB8DB810CC5403F04F3+8183F0D8D76CF92F35899EA98F8135EB9B0E80C8+81DD41F46EB457337248B2D0B208B70F2A06997B+8208BAFED03EF6E98038345679CBE655135F792+833ADEF6A5CD4D1DA1F4B8B6060345368F5B8506+8401703254E2DFD862F3E1015FECB4B940CDDF5D+852DE73E5E8465D607CBE4685A3158AD5225F337+85384EF426E57B5BD704097037C207F140CE9ED5+8675D6AA701696F81C0419C7E48333C075EE33A+86DA06023C3F9E0E90CD32F85D754DA0A4696215+8726B3154869E52DA197DDD8E0EFFC0BC637CE89+874219A59E1B32EBB04639021F8A4E3742158CBD+87E70980F89893DC460E897CF41361288D98D90+887E253B86B280DA94F3B119B697393EF8AA41C8+8892EC4E9281593A7C784B10D3CB118B2FC1A931+8897E68DCED81942FEB35C680823633DB22F5449+889EA5B82AB92C885ECEB5E6E3D6312F0A4BB1DF+88AFD9C84761F8E23F11F59E6666381F45F62A6+88C40F3241ECAE83B21E64BB00349A09F9A2FDF9+890D7E99A9C7CAF2B0B41574CA54BA84D7942931+89AE45BD219EC98D3837F66A333FADF28C068A9A+89D6572C12D61CEAA4547476113294BB4DA79137+89DF50ADA4DF1A29EF3D4F64D3C47512FC58403+89FDBE308984AA76D82E8FA79A92153146A4841C+8A1FE8125FEC072CAB5A81339A96E3E25DC40EFA+8A37D046D5E696B40F9D367DE9B5E1AD3FB63C12+8A5AB94CF9AA25AA48ED74383274B110650E746+8A707B992533D269732BEE35BF2C90BE19FA82C8+8AADD8DDFA47017646C4ECB391404290F7B0A362+8BE5E002216A58895ABE9D8680FC6CD74FCE8C06+8BFB1A26D1E4571FB90DCEBB4DFD41A98BE3A5A6+8C4FB846801A2FD8875A95ACAC98548D8A6147D+8CA99E741D24C9634D3BE10E8FD4164D63364437+8DF6E3E5C81D3CD2E79B8374062C087FE39B3F57+8E83CAE9800E2688F5D29E975EB4CB8A5D1206FD+8EB5C1D8DB0009D66F352BF32BC6A544C0D9A074+8F0EA0D63677F6871F677791AA0C9EEBBC9AE61+903F76994232D010CCBBC0F5CF2364E315462DA6+91A967BC205C7E7C0C77903DA69F4A485D6C7E1F+926FBD5073A857E47D8C6BF675B1E4764B3FDCC2+92813AD1FAA843598116179E07CD9F0FD598D3F+92FDBB6EEB79A22056CD4901399F147DA229353B+935BCBC0217AC51B41C57F8B5425E33001D5B097+938B66249BC029CEAC9881E24170B13E254E1EE9+93DF9F56C7D6BEDF721D2BFADEBCB4EE9D6121BB+93E1455D3F70CCBC232A53E6CD15ACA1B62A5B1+94839EE51D100CAC68B8E35DA652F94452B3CAC4+94848881AD8E126C42FABE52CC48A07545E86B3F+9506914B6F1C4F3269C5CA3260FD818C5268524F+961C6983A289A9ADBD197F131B264CA167AFDDBC96B32736A5CBABE8200737F24D1BDE81385D143A+9AC9EE96BA7415A48070D644433C408D97C72558+9B5B8BB8DD31A59B4B9A984CCFD863869661D223+9C017143B8AB6AD270149CE57785B800471BA3AE+9D1997FE73A82F06C9C145F10761D0E38ADFE35+9DE4B468008939459D2EED84D20910872D540698+9EC80438962FA35924EBAE5E279FC0B86FE73373+9F1AE19C5B64B03AD74D7B4B32E548D86031F804+A1010955558F757D341D18067BD0EB58A5FBEE57+A19371D6CFEC58EB274F610F72265533919E999+A252FF1CE50F7593CCC7BF2F295098CEEBEA8E21+A25882A9ED76FEF99A8440FEE54CF6EC36AB6CFC+A32D12BC63C5DB7210BC635264ACD89150BB3B8C+A4614B75E3BE47FA8605D46709B0F466C7F3162+A5973769C6D1542163C030861A3283320831B274+A5F948DDD7E571F3A9B03FEFE9979DEBCB02453C.z". I'll try again soon. [/log] Tor version 0.3.0.9 (git-100816d92ab5664d) on a Debian 8 Jessie. I don't remember seeing this before ! If it can help... -- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

2 2

Tor relay dying in FreeBSD
by Farid Joubbi 14 Jul '17

14 Jul '17

Hello, I just installed a new relay in a fresh FreeBSD installation. The relay starts fine, except for a warning that I don't understand. Then it dies all of a sudden. The time before it dies is different every time. I have googled for the warnings but could not find anything. Does anyone here know what is going on? Tor 0.3.1.4-alpha (git-fab91a290ded3e74) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A. Jul 12 23:44:24.672 [warn] You appear to lack permissions to change memory limits. Are you root? Jul 12 23:44:24.672 [warn] Unable to raise RLIMIT_MEMLOCK: Operation not permitted .... Jul 12 23:44:29.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Jul 12 23:44:30.000 [err] Out of memory on realloc(). Dying. It's the tor-devel version installed from ports. Thanks in advance.

3 3

Tor on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.
by neel＠neelc.org 14 Jul '17

14 Jul '17

Hi, I recently got a dedicated server from Joe's Datacenter running FreeBSD (it's for a Tor exit node) and when I try to start Tor, I get this error: Failed to find node for hop 0 of our path. Discarding this circuit. Other FreeBSD installations I have with Tor, on both VPS providers as well as personal machines I own do not have this issue. Do you know what could be causing this? -Neel Chauhan

2 1

no abuse complaints?
by Erik Winter 13 Jul '17

13 Jul '17

This might be a bit of a weird question, but I keep wondering about it, so I'll try it anyway. Since April I run an exit node, this one to be precise: 84FAA41C7A7E83EC18964683E1DBA4B6C9E63492 According to Atlas, it works as it should. I have an exit page and a whois, both with valid email adresses. There is some spam filtering, but I also check that folder. In those months, I have received no complaints at all. Not one mail was sent about the exit. Now, this is of course a good thing. We don't want complaints. But it is not what I expected and what I prepared for, so I keep wondering whether I'm doing something wrong. I live in The Netherlands and the level of education about Tor is supposed be high. That might keep authoroties from complaining, but I also heard about bots that send copyright violation notices. So far, they haven't been able to find me Any ideas? Erik Winter

2 2

keys.gnupg.net broken; can't add Debian Tor repo
by tor 12 Jul '17

12 Jul '17

I'm trying to follow the instructions here to install Tor from the official package repository: https://www.torproject.org/docs/debian.html.en On the steps to add the gpg signing key, it doesn't work. It seems something has changed with the keyserver at keys.gnupg.net: 1) http://keys.gnupg.net/pks/lookup returns a 404. 2) Trying to manually visit the root of the domain [http://keys.gnupg.net](http://keys.gnupg.net/pks/lookup) in a browser results in a redirect to https://keys.gnupg.net/wiki/. Here SSL is broken due to a cert mismatch. The cert is for "uz.sns.it". I'm not sure what's going on. Is [keys.gnupg.net](http://keys.gnupg.net/pks/lookup) hacked, or something more mundane? Anyone know how to work around this? Is the signing key available from any other trusted keyservers?

2 2

Re: [tor-relays] keys.gnupg.net broken; can't add Debian Tor repo
by paul＠paulfurley.com 11 Jul '17

11 Jul '17

On the SSL issue: keys.gnupg.net is an alias to the SKS keyserver pool, which is a number of public volunteer run servers: https://sks-keyservers.net/status/ My guess is you hit a misconfigured one that redirected you to TLS without checking what host you requested. For example I redirect http://keyserver.paulfurley.com to https://keyserver.paulfurley.com *only* if the requested host is keyserver.paulfurley.com. Otherwise I would serve a certificate with a mismatching domain. I'd recommend posting your finding to the sks-devel mailing list since it's probably something the pool should look out for and warn servers they're misconfigured. (I'll post it in the morning if you like.) Paul > > On Jul 10, 2017 at 10:58 pm, <tor (mailto:tor@anondroid.com)> wrote: > > > > Actually, the directions on https://www.torproject.org/docs/debian.html.en work okay. I was trying to automate things with Ansible, but the format changed at some point, from something like: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 url=http://keys.gnupg.net/pks/lookup?op=get&search=A3C4F0F979CAA22CDBA8F512… > > > > to: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 keyserver=keys.gnupg.net > > > > The URL at /pks/lookup no longer exists, so I saw a 404. Using the newer format with just the hostname of the keyserver it works okay. > > > > Regarding http://keys.gnupg.net I still don't know why there is a SSL mismatch in the browser, or why you can no longer access the web UI, but it's not as broken as it looked. > > >

2 1

Windows relay performance: svchost process
by Vort 10 Jul '17

10 Jul '17

Hello. Since connection count for my Windows 7 relay began to grow, I have started to notice unusual CPU load pattern. That's a periodical spikes every ~8 seconds. First I was thought that this spikes are generated only by tor.exe process, but then I have found that svchost.exe process have identical spikes (I guess they belong to NlaSvc system service). Do anyone know why this can happen? Here is the screenshot: https://s8.hostingkartinok.com/uploads/images/2017/07/6fe01ab8601548f95ba47… -- Vort

1 0

increasing per IP tor instance limit (2 instances per one IPv4)
by nusenu 10 Jul '17

10 Jul '17

Roman Mamedov: > Another idea that I proposed some time ago is raising the > relay-per-IP limit is there a trac ticket for this already? AFAIR that limit primarily exists mainly to increase the price for Sybil attacks, but since they would be trivially detected (i.e. by OrNetRadar), I do not see why increasing that limit would hurt (much) on the other side: Is there an actual demand for increasing that per IP limit? If you have been impacted by that '2 instances per public IPv4'-limit and would benefit from an increase please speak up -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 2

Load balancing (with IPVS) multiple Tor daemons
by Clodo 08 Jul '17

08 Jul '17

The objective it's making a single Tor Relay and using on the machine many daemons on a multicore server. I hope someone can give me a feedback if this kind of configuration can be problematic for Tor network before test in a real environment. Many Tor daemon, with X from 0..n, binded on different port, all advertise the same ORPort/DirPort. An IPVS load balancing at kernel level. Tor Config: SocksPort 0 Nickname superrelay Address superrelay.net ORPort 443 NoListen ORPort 127.0.0.1:100X NoAdvertise DirPort 80 NoListen DirPort 127.0.0.1:200X NoAdvertise DataDirectory /var/lib/tor/childX All daemon have the same SocksPort, Nickname, Address, MyFamily. All daemon point to different DataDirectory, but each of them have the 'keys' directory identical. All daemon advertise the ORPort 443 and DirPort 80, but bind on other ports. IPVS configuration: # Clear ipvsadm -C # Add a virtual server (-A) for ORPort. ipvsadm -A -t superrelay.net:443 -s sh # Add a virtual server (-A) for DirPort. ipvsadm -A -t superrelay.net:80 -s sh # Add all real servers/daemons (-a) for ORPort ipvsadm -a -t superrelay.net:443 -r localhost:1000 -m ipvsadm -a -t superrelay.net:443 -r localhost:1001 -m ... ipvsadm -a -t superrelay.net:443 -r localhost:100X -m # Add all real servers/daemons (-a) for DirPort ipvsadm -A -t superrelay.net:80 -s sh ipvsadm -a -t superrelay.net:80 -r localhost:2000 -m ipvsadm -a -t superrelay.net:80 -r localhost:2001 -m ... ipvsadm -a -t superrelay.net:80 -r localhost:200X -m Note the scheduling method: sh - Source Hashing: assigns jobs to servers through looking up statically assigned hash table by their source IP addresses. Any source-ip will be always binded to the same daemon. I think 'Advertised Bandwidth' on onionoo/atlas can be inexact. I can experiment a relay like that, or can be problematic/unexpected for Tor network? Thanks for any feedback.

4 5

Wikileaks Unveils CIA Implants that Steal SSH Credentials from Windows & Linux PCs
by I 08 Jul '17

08 Jul '17

https://wikileaks.org/vault7/#BothanSpy

1 0

Re: [tor-relays] Exit flag and port 6667 vs 6697
by Igor Mitrofanov 05 Jul '17

05 Jul '17

> 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 <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Exit flag and port 6667 vs 6697 > Message-ID: <F84DD3E5-F83F-4B13-A5CF-7A518687B719(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > >> On 5 Jul 2017, at 05:29, grarpamp <grarpamp(a)gmail.com> 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 consensus bandwidth capacity and exit node counts for 6667:6697? >> What is the traffic ratio of 6667:6697 actually exiting the network? > > Good question. > We don't collect stats on individual ports, because it's hard to do > safely. > >> I suspect switching minimum to 6697 is fine, or at least making it >> logical OR. > > 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? > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------ > > > >

2 1

IPv6 to IPv4 tor exit relays would fix many daily tor-problems
by Fof582 05 Jul '17

05 Jul '17

I have access to a fast internet connection. This connection only have ipv6 IP and i can access the IPv4 network over the ISPs 6to4 bridge. So there are already many users using one single IPv4 address at this ISP. Sadly its technical as far as i understood at the moment not possible to run a IPv6-only exit node. If i could run such, the people on the world that could access IPv6-adresses also would be able to connect to my IPv6 exit node. Then they can finally access over IPv4 all the webpages that normally block tor users, bother them with captchas, ... Such tor-users could also finally access freenode irc again. I would like to give such service-blocked tor users again access to all websites of the internet by providing such a 6to4-tor exit node. Is there any progress at this?

5 10

What is the right repo for Redhat/CentOS Tor?
by tor＠t-3.net 04 Jul '17

04 Jul '17

The files in the repo location we have configured have not changed recently, and I know that Tor's been updated. The repo we're configured for is based out of: https://deb.torproject.org/torproject.org/rpm/el/6/x86_64

2 1

Exit flag and port 6667 vs 6697
by Igor Mitrofanov 04 Jul '17

04 Jul '17

Hi, I am trying to run a few Exit relays on my 1 gbps connection. To keep donating the exit capacity to the Tor project I have to keep abuse reports to a minimum. In order to have the Exit flag I have read that I have to keep two of ports 80, 443 and 6667 open, plus allow exiting to at least one /8 network - is that still the Dir spec? Is it correct that without the Exit flag, no clients will choose the relay for their circuits - even if its Exit policy allows the port they need? For example, take a look at the "cry" relay (one of top 10) - it is not marked as "Exit" as it only allows ports 6660-6667 - does that mean it is only ever used as a middle relay? I have read that port 80 generates quite a bit of abuse complaints as it is used to tunnel non-HTTP traffic, by malware, etc. So, choosing ports 443 and 6667 to get the 'Exit' flag looks like the safest choice. I have also read that ports above 1024 are more likely to used by BitTorrent clients, so they are to be rejected in order to minimize abuse. 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. 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. Thanks, Igor

3 3