- tor-relays - lists.torproject.org

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

18 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 18 Jan '14

18 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 15 Jan '14

15 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 15 Jan '14

15 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

Re: [tor-relays] One relay shown as two
by Andy45 11 Jan '14

11 Jan '14

Thanks to everyone who replied to my question. I guess I'll just be patient then! The funny thing is that I never did reinstall Tor/Vidalia... although I got one working then the other with different configs for a while. That may have been it. Thanks! Andy

1 0

One relay shown as two relays in Atlas
by Andy45 10 Jan '14

10 Jan '14

Hello all! My question is related to Atlas. I asked this question on Tor help and I was referred to here. Here are my questions: I run a small exit relay on my computer. (Nickname is Andy45 and IP address is 108.249.221.251 if you want to look at this problem on Atlas for your self.) When I look up my relay on the Atlas, the relay is displayed as two separate relays with differing bandwidths and different uptimes. I'm not sure what's up with that - but my best guess is that it is splitting the amount of bandwidth I donate in half? The one of the average bandwidths listed on Atlas is a fair amount less than what the bandwidth monitor shows I give. (70 kbps rather than 100+ kbps.) Thanks, Andy

3 2

Hidden Service web design to speed load times
by Gordon Morehouse 09 Jan '14

09 Jan '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey folks, I've been off the list for quite a long time due to personal reasons, and I'm aware I have a couple irons still in the fire WRT RasPi and the SYN flood stuff - I'll get to it. Today, though, I came across this article: http://csswizardry.com/2013/01/front-end-performance-for-web-designers-and-… tl;dr you can add a 'dns-prefetch' link tag in the HEAD of HTML documents to do DNS lookups ASAP, instead of later on when the browser parses the content which does it, or your Javascript (yeah, I know) does it, etc. I'm wondering if this would have any value for Tor hidden services - would a "DNS lookup" of a .onion force Tor to start building a circuit to the hidden service in question? I suppose one could deliberately request a nonexistent file or a 1x1 pixel PNG or something, too, to get the circuit built, but this is obviously a little cleaner and probably a little better for privacy versus an HTTP request which may be logged even if the user never takes an action to *actually* request real info. Just a thought for hidden service operations. It's always easier to get one's message out the less time it takes to load. Best, - -Gordon M. -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJSztxfAAoJED/jpRoe7/ujrx8IAJyREaH6TZ2z5GjBPrZfZcir fWi5zfwO/t/we/uQzn0IriM8DIMvLQOHS1Z9ly/qzUyoBLPRxzUqPpkzmtzXgXOy l2bAhmRCSyGZXDgE4GAXpVXP8w2w3fb7ijJADqy+I/nqQYZX7MMzlcT8hlsqqon9 I39ITwbDoUuem+y/XG/IICcbTVBsrH3m2auhRBfHawAJW8iO6xooltyUS6JExxLB fALfaG64YOy8mv+eyOT4tYoP67r8miEDlmTnplARUKw458lihqlnZ1TrCN+AVaJt OJCXiDnqghvBAJE+v/5JWJOMDr90ucI/+9mitOmbbQh03JOSRsSryeffPmUN08c= =gl1d -----END PGP SIGNATURE-----

1 0