January 2014 - tor-relays - lists.torproject.org

17 Jan '14

In this morning's messages - One about three relays paid for a year in advance. “Something Solutions LLC has decided to ban the usage of TOR.“ despite “We DO Allow Tor Relays" being in their current AUP. One about downloading Tor and installing it as an exit for me when I couldn't. “This issue has now been resolved. root@XXXIX:/# tor Jan 02 23:51:53.668 [notice] Tor v0.2.4.20 (git-0d50b03673670de6) running on Linux with Libevent 2.0.19-stable and OpenSSL 1.0.1c. Best Regards," Robert ____________________________________________________________ FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth

5 6

Tor listenes to UDP ports?
by Wollomatic 17 Jan '14

17 Jan '14

Dear all, i run a tor relay (version 0.2.4.20) on debian wheezy. Today I noticed Tor uses some UDP ports: # netstat -tulpen tcp 0 0 0.0.0.0:9030 0.0.0.0:* LISTEN 0 46692311 26643/tor tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 0 46692310 26643/tor [...] udp 0 0 0.0.0.0:33915 0.0.0.0:* 104 46692315 26643/tor udp 0 0 0.0.0.0:56554 0.0.0.0:* 104 46692316 26643/tor udp 0 0 0.0.0.0:34821 0.0.0.0:* 104 46692317 26643/tor udp 0 0 0.0.0.0:49463 0.0.0.0:* 104 46692314 26643/tor Since I thought Tor only uses TCP may this be a security problem with my server? Best regards, Wollomatic -- PGP 0xC1BF1482

4 4

Tor Cloud: still not listed
by Patrick ZAJDA 17 Jan '14

17 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I have set up an Amazon EC2 instance to run a Tor Relay, I chose Obfsproxy Bridges. First, I am blind and I am not to read the "How to" in the Get started page of cloud.torproject.org, so I though all was configured, and had a surprise with the security group I have to define by myself. :) So my question is: would it be possible to make the step by step instructions accessible please ? Less pictures or more text in all cases, having text doesn't require to remove images. The second point is: I looked at the configuration, and noticed bridge is set to 1. I though it made the tor relay private, do I have miss-understood something? If I didn't miss-understand, that explains why it is still not listed on atlas.torproject.org, and there is a problem with the provided EC2 image. Else, how long in my relay will be listed? And which reasons could make my relay unavailable on atlas? I opened all four ports I found on the get started page but half an hour latter, it is still not listed. Thanks, - -- Patrick ZAJDA Skype : gansta93 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1o1vAAoJEKPVT2DeSPb41WYIAKc3PWOf5RB0dUdo/Rcru2iF 8LceynqNjYbqyjJxwQbBIdpXkUHfoD1t2D9Tv8DYYrm0pLHrPWDzRZbbKHKPCiKI VlvrUy7TKyLPl6CKV3QztMMx62jGYsxitEOjy2b7GS2XyA1VnWu5JR8TgDNBeh4L KeP3CQOLKGS3dyqOfEjXzBpSb3sQQwJbzVjZJIZBaGMgqYbEVU7YsPdP/+e+1/0H V0T/uDTgquCE2eo7tXjgQLp97IAKIxrufJewaVnwJjTNDVwAxh5VigFhMbebf7yW rLo3PRGZMrCrJ5I9niGziGglmnnqWHmLxLIHRHx00TH1E+2fV+fPlWY3ssMwEuk= =SfE2 -----END PGP SIGNATURE-----

7 11

Relay, bridge, and family members
by Patrick ZAJDA 17 Jan '14

17 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Now I created a bridge, I'd like to create a relay on a dedicated server. I read about the FamilyMembers configuration value, to list all relay which are from the same owner. If I create another relay, do I have to put the bridge fingerprint to the new relay and put the relay fingerprint in the bridge configuration? Thanks, - -- Patrick ZAJDA Skype : gansta93 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS1qH1AAoJEKPVT2DeSPb4+QUIALJNLP9MsGN8FbPEP6EegNV9 gcc66Iz2Z7maJD35pMquQqBqJrK+Zo6brSe2aX0N9+GipV9+jCpMa0hUOfzsf1h8 oebEjDLPgf4nxE6GuztU7Jkm0XwqHFmT1ELFPS2qU/EwGOBhj4l0Pywff7qfhBBC nvM+5O6+DRVD/44RGyhQqaNCDkxYuUkcLMJUX104RCoBQ6WmPYRBEPBm8YbrPKmc eGZNpRggSDRYzITZrT0SneIzExFP5IbTdGlHidyL4it70iJDI+LBZsm/ZGMENv/h lUYHe8RQbmDgt81BB+dq763zIeFMvBMOtJEdVdWPtuzsGypLxWJPMiR0NKqf6ZI= =X0ps -----END PGP SIGNATURE-----

6 7

Bad experience with hetzner.de and "Trusted Tor Traceroutes" experiment
by irregulator＠riseup.net 17 Jan '14

17 Jan '14

Hello there, We're running a Tor relay (not exit) on a virtual private server at Hetzner for about a year. On Wednesday January 8th, we decided to take part in the "Trying Trusted Tor Traceroutes" [1] research experiment. There have been various calls for participation on public mailing lists [2] [3]. The traceroutes were conducted using the scamper package, as suggested in README. We imposed no rate limiting to requests, just run the script with default values. Some hours later, Thursday 9th, we received an email from Hetzner stating that our server was taking part in attacks and they would suspend our instance if we didn't react within 8 hours. As soon as we got the warning we killed scamper conducting the traceroutes, and followed the procedure so as not to get our instance suspended. Hetzner also asked for some explanations about why we think our server was not taking part in the attack. We responded via email with a full explanation about the traceroutes from our server and the "Trying Trusted Tor Traceroutes" experiment from various researchers from University of Illinois [1]. We told Hetzner that our server was making harmless and legal traceroutes to various destinations on the Internet, thus they had no reason to suspend our instance. Twenty four hours later, Friday 10th, Hetzner blocked network access to the IP address of our server, did send us an email about blocking, but ignored our exlanations submitted the previous day. After the blockage of our IP we insisted on trying to resolve the case by sending one more email exlaining the situation and asking to unblock us, and then opening a ticket. Hetner's response to the last email (5 hours later) was that we should open a ticket, which we already had done. Alas, our ticket was marked as duplicate and closed(?). During this loophole support nightmare most responses from Hetzner's part actually seemed to be machine generated. At last Hetzner asked us via email to send them a signed document via fax(!) containing explanations about the incident. Now that was ridiculous, since we had submitted explanations already three times with the first submission only four hours after Hetzner's first warning on Thursday. Nevertheless, we did resend the explanation. After about 7 hours of downtime, Hetzner unblocked network access to our server. More than 36 hours later they sent an email "Dear Mr. xxxx, your server is unlocked." Concluding, - Hetzner considers traceroutes to various internet destinations as attack. All relay operators with machines at Hetzner should be _careful_ when taking part in "Trying Trusted Tor Traceroutes" experiment. - Hetzner has awful customer support. Cheers, Alex [1] https://web.engr.illinois.edu/~das17/tor-traceroute_v1.html [2] https://lists.torproject.org/pipermail/tor-relays/2013-October/003113.html [3] https://lists.torproject.org/pipermail/tor-news/2014-January/000027.html

4 7

Re: [tor-relays] using Curve p25519 cryptography for type 2(Mixmaster) and type 3(mixminion) remailer blocks
by grarpamp 14 Jan '14

14 Jan '14

>> On Tue, Jan 14, 2014 at 2:14 PM, gwen hastings <gwen(a)cypherpunks.to> wrote: >>> ... >>> I am looking at resurrecting >>> >>> mixmaster, mixminion and nym.alias.net nymserver designs from the >>> various code wastebaskets and retrofit them with some newer encryption >>> technology based on curve25519 and poly-1305 libsodium based algorithms >>> and routines. I believe there is sufficient demand to merit deployment of a good mix network. As well as perhaps web/other intake frontends due to the now prevalent a) dwindling free email b) demand by mail providers for phone authentication. As for operators, I'd reach out to the Tor, I2P, Bitcoin, etc operators. It's a shame that one of the hardest things to find these days is anonymous free speech in the simple form of the written word.

1 0

Re: [tor-relays] System Time
by Moritz Klammler 14 Jan '14

14 Jan '14

Hi, if the time difference is too big, NTP will refuse to touch the clock altogether. You can force an update by the '-g' option. However, the adjustment might still be slow. I'd do the following (as root): # hwclock --set --utc --date="2014-01-14 22:05:35" # ntpd -qg The first command manually sets the hardware clock to the approximate correct time (which you should adjust, of course). Note that the date string must specify the time in your local timezone, despite the '--utc' option. The second command tells NTP to do a one-shot sync ('-q') and allow an initial big adjustment ('-g'). Then, for the future, just make sure you have the NTP daemon enabled to keep the clock in sync. On Debian, if you have installed the 'ntp' package, this should be fine. Happy Hacking Moritz Jeroen Massar <jeroen(a)massar.ch> writes: > On 2014-01-14 21:05, I wrote: >> Jeroen, >> >> Thank you. It did that but I can't see a change. > > NTP adjusts slowly, as your clock is 6+ hours off, you should force the > timesync first, eg with with rdate (apt-get install rdate): > > rdate -v ntp.xs4all.nl > > should do the trick. Then after that make sure that ntpd is running: > /etc/init.d/ntp restart > >> The VPS person said it is set to UTC. Previously on another VPS it >> was another relay in the ?circuit which had the time difference. > > UTC is a timezone, and having that is great as it avoids all the > pitfalls and annoyances with summer/winter time. > > Note that some VPSs do not allow changing of the time, one will have to > ask the host to set the time. > > Do note that a VPS can be inspected and controlled easily by the Host, > as such, make sure that you trust that operator. > > Greets, > Jeroen -- OpenPGP: Public Key: http://openpgp.klammler.eu Fingerprint: 80C1 EC79 B554 3D84 0A35 A728 7057 B288 CE61 2235

2 1

Throughput changes?
by Thomas Themel 14 Jan '14

14 Jan '14

Hi, I've been running two nodes on the same machine for some time because I was unable to get enough throughput to blow through my bandwidth budget otherwise. However, something seems to have changed recently, since right now I'm blasting through about double my usual bandwidth (~25 MB/s) with the two tor jobs at only ~60% CPU usage each while previously it was always CPU limited. This doesn't seem to correlate with any software updates on the machine. Here's atlas: https://atlas.torproject.org/#details/3DD2523F1B241F01D54818F327714CDA7F542… ciao, -- [*Thomas Themel*] [Albulastrasse 52] To begin with, GNU will be a kernel [...] [ CH-8048 Zürich ] - RMS announcing GNU in 1983 [*+41 78 9070988*]

4 8

recent OVH feedback?
by Alan Turing 13 Jan '14

13 Jan '14

Dear all, I am currently running a fairly large tor relay (no exit, due to OVH's restrictive policies) and would like to know if other people have made experiences with running non-exit relays using OVH's services. Did any contracts get canceled or did you receive any kind of (legal) threats by OVH for doing so? Have you made positive experience with OVH regarding non-exit relays? I'd be grateful for information. regards, s.

3 2

404: /tor/keys/fp-sk/print-print not found
by nano 12 Jan '14

12 Jan '14

I haven't looked into this at all yet, thought I would share it here first. Both my exit relays [0] received these repeated warnings around the same time yesterday: timestamp [warn] Received http status code 404 ("Not found") from server 'server1IP:port' while fetching "/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0". timestamp [warn] Received http status code 404 ("Not found") from server 'server2IP:port' while fetching "/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0". timestamp [warn] Received http status code 404 ("Not found") from server 'server3IP:port' while fetching "/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0". timestamp [warn] Received http status code 404 ("Not found") from server 'server4IP:port' while fetching "/tor/keys/fp-sk/A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0-A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6Q7R8S9T0". Only one timestamp and serverIP was consistent on both relays. All fingerprints, however, were consistent on both. Hasn't appeared before or since. Anything to worry about? Thanks. [0] https://atlas.torproject.org/#details/799B025E25850A88CD133276301FAFB731C2E… -- syn.bsdbox.co

3 4