- tor-relays - lists.torproject.org

Re: [tor-relays] Recommendation: Upgrade your OpenSSL! (Nick Mathewson)
by teor 12 Jun '15

12 Jun '15

> Date: Thu, 11 Jun 2015 14:30:35 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > > Hi, relay operators! > > There have been a series of new openssl releases today: 0.9.8zg, > 1.0.0s, 1.0.1n, and 1.0.2b. > > They fix a set of security issues described in this announcement: > https://www.openssl.org/news/secadv_20150611.txt > > Since some of these issues could allow a remote denial-of-service > attack, I would suggest that everybody should upgrade as OpenSSL > packages become available for your operating systems. If you build > OpenSSL from source, now's a good time to rebuild. You probably don't > need to run in circles freaking out, or anything -- just upgrade when > you can. > > Also, if you can possibly avoid it, it would be a good idea to stop > using the OpenSSL 0.9.8 series entirely. It's old and crufty and is > missing many security improvements in later versions. OpenSSL 0.9.8 > will not be supported in Tor 0.2.7.2-alpha or later. Please also note that OpenSSL versions 0.9.8 and 1.0.0 are becoming unsupported at the end of 2015: "As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html) support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these releases will be provided after that date. Users of these releases are advised to upgrade." See the second-last section in https://www.openssl.org/news/secadv_20150611.txt teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Recommendation: Upgrade your OpenSSL!
by Nick Mathewson 11 Jun '15

11 Jun '15

Hi, relay operators! There have been a series of new openssl releases today: 0.9.8zg, 1.0.0s, 1.0.1n, and 1.0.2b. They fix a set of security issues described in this announcement: https://www.openssl.org/news/secadv_20150611.txt Since some of these issues could allow a remote denial-of-service attack, I would suggest that everybody should upgrade as OpenSSL packages become available for your operating systems. If you build OpenSSL from source, now's a good time to rebuild. You probably don't need to run in circles freaking out, or anything -- just upgrade when you can. Also, if you can possibly avoid it, it would be a good idea to stop using the OpenSSL 0.9.8 series entirely. It's old and crufty and is missing many security improvements in later versions. OpenSSL 0.9.8 will not be supported in Tor 0.2.7.2-alpha or later. best wishes, and many thanks! -- Nick Mathewson

1 0

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by starlight.2015q2＠binnacle.cx 11 Jun '15

11 Jun '15

>Mon Jun 8 05:25:55 UTC 2015 >> UBSAN seems expensive and doesn't seem >> it would run other than test, but >> I didn't work on it long and am not >> 100% certain. Was trying ASAN extra >> stack checking at the time, which may >> have been the culprit. > >As I said in my previous email, if you're >running releases before 0.2.6.6 (2015), >Tor won't run under UBSAN due to issues >that have been fixed in subsequent >releases. Had a need to run ASAN+UBSAN and it works perfectly fine for me with version 0.2.4.27. Required a minor patch to convert a single common variable 'incoming_queue' to extern. Performance hit was not as bad as I thought from the earlier try, but bad enough that I limited the instrumented modules to only what's necessary.

1 0

Incorrect IP Address change reported
by Pascal Terjan 10 Jun '15

10 Jun '15

I got my IP address reported as changed to some Deutsche Telekom IP twice in a few minutes by 154.35.175.225 yesterday This IP is "Faravahar" according to https://trac.torproject.org/projects/tor/ticket/14487 Jun 09 12:21:50.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:21:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:21:54.000 [notice] Performing bandwidth self-test...done. Jun 09 12:22:51.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 86.59.21.38). Jun 09 12:22:51.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:22:51.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Jun 09 12:23:52.000 [notice] Our IP Address has changed from 149.18.2.82 to 91.5.121.93; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:23:52.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:24:10.000 [notice] Our IP Address has changed from 91.5.121.93 to 149.18.2.82; rebuilding descriptor (source: 154.35.175.225). Jun 09 12:24:10.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Jun 09 12:25:00.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.

2 1

Cheap exit-friedly VPS provider
by Alexey Nayden 10 Jun '15

10 Jun '15

Hello everybody, A couple of months ago I decided to run a Tor exit relay. I contacted several VPS and dedicated providers and ended up using PulseServers, because they offered unmetered fast channel for ~$13/month and were Tor-friendly. Only after installing and configuring the relay I realized their IPs are from OVH AS and they are OVH resellers. I understand OVH AS'es already dominate the network and should be avoided if possible, so I have 2 questions: 1. Is there a comparable alternative? 100 Mbit/s unmetered (or 20+ TB of traffic) for less than $20/month. I imagine cheap OpenVZ virts can't handle even 100 Mbit/s anyway, so I'm not looking for top performance, but I want something that can do at least 50 Mbit/s 24/7. 2. If one decided to use OVH AS, are VPS that OVH sells directly good enough? They have virts as cheap as 2.99/month with at least 10Tb at 100Mbit/s (http://www.ovh.com/us/vps/vps-classic.xml) Thanks! -- Alexey Naiden

7 7

Re: [tor-relays] Cheap exit-friedly VPS provider
by spiros_spiros＠freemail.gr 09 Jun '15

09 Jun '15

I have an exit on Wedos since April and so far things have been well. I receive the usual abuse/hacking/nastiness complaint and respond politely within 72 hour. The only issue is on Atlas the exit doesn't yet have exit flag, but I am assuming this is down to bwauth issue etc etc. Will happily recommend. S On 9 Jun 2015, at 17:28, Andrej Manduch <amanduch(a)gmail.com> wrote: Hi Alexey-san, I'm running tor exit relay on VPS from amerinoc and they didn't seems to have problem with that. I mentioned that when I asked them to change abuse e-mail for ip-address and they were ok with that. However I would definitly recommend you to take look at this list: https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs I also heard that https://hosting.wedos.com/en/ are very tor friendly and they're really cheap (about 100 bucks/year). On 06/09/2015 11:43 AM, Stephen R Guglielmo wrote: On Mon, 8 Jun 2015 22:35:28 -0700 Alexey Nayden <alexey.nayden(a)gmail.com> wrote: Hello everybody, A couple of months ago I decided to run a Tor exit relay. I contacted several VPS and dedicated providers and ended up using PulseServers, because they offered unmetered fast channel for ~$13/month and were Tor-friendly. Only after installing and configuring the relay I realized their IPs are from OVH AS and they are OVH resellers. I understand OVH AS'es already dominate the network and should be avoided if possible, so I have 2 questions: 1. Is there a comparable alternative? 100 Mbit/s unmetered (or 20+ TB of traffic) for less than $20/month. I imagine cheap OpenVZ virts can't handle even 100 Mbit/s anyway, so I'm not looking for top performance, but I want something that can do at least 50 Mbit/s 24/7. 2. If one decided to use OVH AS, are VPS that OVH sells directly good enough? They have virts as cheap as 2.99/month with at least 10Tb at 100Mbit/s (http://www.ovh.com/us/vps/vps-classic.xml) I can't say for exits, but I use the OVH Classic VPS ($2.99/mo) to run one of my relays. It's not an exit node. I let them know about it and paid a year in advance. No problems whatsoever with them thus far. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Improving Node Connection Testing
by starlight.2015q2＠binnacle.cx 09 Jun '15

09 Jun '15

>Mostly, latency and packet loss in nodes >will negatively impact Tor's usability. . . Was reading this thread and thought of potentially useful and perhaps not overly difficult BWauth enhancement--perhaps worth considering as part of ongoing efforts to rework the BWauth scripts. When measuring a node, a BWauth could spawn a 'tcpdump -w' PCAP capture of the specific test connection traffic and SIGTERM it when that's finished. Then run some tool or another to analyze the connection for SACKs and/or other indications of the quality of the relay and path. Here's one example: https://github.com/lennart-schulte/tcpdump-analyzer Alternately, such a mechanism could rely on a continuous 'tcpdump' running with a large circular buffer and a script or program could follow the test connections and spit out a statistical summary for completed ones to a text log that would then be consumed by the BWauth scripts. If the idea has potential, someone could perform a casual passive 'tcpdump' of test traffic and examine a few connections.

1 0

(n00b) Exit node question
by Hong, Yongmin 08 Jun '15

08 Jun '15

Hello, it's my first time running an exit. (Well, I'm n00b in running a relay too :p) I think I followed the guidelines correctly to be an exit (with some modification from reduced exit policy on trac), but atlas and globe reports that my exitpolicy is "reject *:*". My configuration is at [1]. Please tell me what's wrong here. Thanks! [1]: https://phabricator.wikimedia.org/P740 -- Revi https://www.revi.pe.kr -- Sent from Android --

3 5

Re: [tor-relays] tor-relays Digest, Vol 53, Issue 12
by Victor Victoe 08 Jun '15

08 Jun '15

U,koo On Jun 6, 2015 5:00 AM, <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: Updating tor to get fix for #15083? (Elliott Jin) > (AlexK (Tor lists)) > 2. Re: Keeping an exit node off of blacklists due to botnet > activity. (tor(a)t-3.net) > 3. BWAUTH weightings too volatile. . ."twitchy" > (starlight.2015q2(a)binnacle.cx) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 05 Jun 2015 14:32:05 +0200 > From: "AlexK (Tor lists)" <tor-relays(a)kalex.nl> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Updating tor to get fix for #15083? (Elliott > Jin) > Message-ID: <557196C5.7000103(a)kalex.nl> > Content-Type: text/plain; charset=windows-1252 > > tor-relays-request(a)lists.torproject.org schreef op 05/06/15 om 14:00: > > > Updating tor to get fix for #15083? (Elliott Jin) > > > > - Is Tor 0.2.5.10 (git-43a5f3d91e726291) actually the newest stable > > version, or did I mess something up when trying to update tor? > > - Would it be a good idea to upgrade to an experimental version? > > Assuming you're running 'standalone' on *Nix, this is a good place to > check: > > https://www.torproject.org/download/download-unix.html.en > > Here you'll find the latest source (stable/unstable) and the latest > packages for several *Nixes, including simple install instructions. > > Latest and greatest is 0.2.6.8, even if you rely on your package > manager's updates this is what you should have, e.g. on my relay: > > $rpm -qa tor > tor-0.2.6.8-tor.1.rh6_6.x86_64 > > Good luck! > Alex > > > > ------------------------------ > > Message: 2 > Date: Fri, 05 Jun 2015 09:21:24 -0400 > From: tor(a)t-3.net > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] Keeping an exit node off of blacklists due > to botnet activity. > Message-ID: <5571a254.4b95.8816c700.4c72f93d(a)t-3.net> > Content-Type: text/plain; charset=us-ascii; format=flowed > > > > I have a fairly high bandwidth exit node running for about a month > now > > that I'm having difficulty keeping off of the > http://cbl.abuseat.org/ > > blacklist and have been informed of this listing by the VPS > provider. > > The relay is running with a reduced exit policy -- and additionally > I've > > blocked common mail ports, etc via IPFW so I know that no spam is > > actually being sent out of the relay. Still, various botnets > connections > > are connecting to abuseat.org botnet sinkholes via port 80 > > Command&Control connection attempts. I'm at a loss at how to stop > this > > or somehow detect and filter botnet traffic. > > > > I've informed the VPS provider that I'm on top of it and have the > > machine configured to not actually allow this sort of malicious > traffic > > out and they seem to be generally happy with that explanation, but > a > > better solution if one exists would be appreciated. > > > > Thanks, > > > > Julian Plamann > > > > julian (at) amity.be > > GPG: 0x96881D83 > > Don't know if this will help, but maybe: > > ExitPolicy reject 85.159.211.119 # Cryptolocker > ExitPolicy reject 212.71.250.4 # Cryptolocker > ExitPolicy reject 54.83.43.69 # Cryptolocker > ExitPolicy reject 192.42.116.41 # Cryptolocker > ExitPolicy reject 192.42.119.41 # Cryptolocker > ExitPolicy reject 198.98.103.253 # Cryptolocker > ExitPolicy reject 208.64.121.161 # Cryptolocker > ExitPolicy reject 142.0.36.234 # Cryptolocker > ExitPolicy reject 173.193.197.194 # Cryptolocker > > In general, I see complaints about abuse from the exit relays we run > due to someone using Tor to try to exploit remote web server scripts > and databases and the like. I don't think there's anything that can be > done about it? I would say that it's just part of what you get coming > out out of Tor exit nodes. > > If anyone else has any better advice feel free to correct me but, I > think it might be accurate to explain to the upstream that Tor exits > will generate certain kinds of abuse complaints as part of normal > operation. They open proxy web-related ports out, and some people > abuse Tor for web hacking types of activity. > > I would say that it is normal for Tor exits to live permanently on > certain kinds of blacklists. They do not need to be on the spam email > related ones (reject *:25 and other email ports), but they will land > on other types of blacklists, and I don't think it can be helped. > > > > > > > > ------------------------------ > > Message: 3 > Date: Sat, 06 Jun 2015 02:43:09 -0400 > From: starlight.2015q2(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] BWAUTH weightings too volatile. . ."twitchy" > Message-ID: <6.2.5.6.2.20150606020527.04dbce00(a)flumedata.com> > Content-Type: text/plain; charset="us-ascii" > > I'm back to complain further about > erratic bandwidth authority behavior, > previously > > [tor-relays] BWauth kookiness > https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html > > Allowing that BWauths are in a bit of flux, > with tor26 replaced by maatuska and > moria1 dropping the GuardFraction > calculation, the bandwidth calculations > evidence wildly erratic swings. > > Specifically my relay, which is perfectly > stable, reliable, fast (9.375 Mbyte/sec) > has been assigned a jaggedly random > series of consensus weights. > > > https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF… > > earlier, fairly sane > > *gabelmoo Bandwidth=7701 Measured=9960 > tor26 Bandwidth=7701 Measured=9340 > moria1 Bandwidth=7701 Measured=18000 GuardFraction=66 > longclaw Bandwidth=7701 Measured=12800 > > later, bit high, nutty > > gablemoo Bandwidth=9375 Measured=17100 > moria1 Bandwidth=9375 Measured=77900 GuardFraction=75 > *longclaw Bandwidth=9375 Measured=23000 > > now, sane but undervalued > > gablemoo Bandwidth=8925 Measured=14900 > maatuska Bandwidth=8925 Measured=17200 > moria1 Bandwidth=8925 Measured=5330 > *longclaw Bandwidth=8925 Measured=7440 > > moria1 here is downright schizophrenic > but other BWauths regularly double > and halve the bandwidth value they > assign. Graph shows it a more vividly. > > What the graphs and numbers do not show is > that the effective difference between > the consensus values of ~7000 and ~23000 > is staggering. At the low end > of this range the relay shows roughly > 2500 active circuits and a average > load factor of about 20% of actual > bandwidth, while an assignment of 23000 > results in almost 8000 circuits > and a load factor of more like 50% > (both per Blutemagie.de). > > My point is that BWauths should not > be arbitrarily flipping stable, well > run relays from the top to the bottom > of this steeply sloped sweet-spot of > the weighting curve. Perhaps the > sweet-spot range has moved over the > last couple of years as the price of > bandwidth has dropped and faster > connections become more prevalent, > and this has been overlooked in > the algorithm. > > Regardless, it seems BWauth measurement > should be more nuanced in this > particular range, such that relays are > not slammed constantly between "rather > popular" and a "bit boring" irrespective > of their actual available capacity. > > One reason this vexes is that I > would like to see how well the relay > runs with Address Sanitizer active. > ASAN provides obvious benefits > w/r/t security, but entails a > performance trade-off. With the > BWauths throwing darts, eyes closed, > when choosing weighting, it's > impossible to gauge the performance > impact of various adjustments. > > In the bigger picture view, erratic > BWauth weighting can't be adding > clarity to the performance, > capacity and utilization situation. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ------------------------------ > > End of tor-relays Digest, Vol 53, Issue 12 > ****************************************** >

1 0

Re: [tor-relays] BWAUTH weightings too volatile. . ."twitchy"
by teor 08 Jun '15

08 Jun '15

> Date: Sat, 06 Jun 2015 14:37:01 -0400 > From: starlight.2015q2(a)binnacle.cx > > At 04:12 6/7/2015 +1000, teor wrote: > >Please let me know how you go - the 0.2.6.x > >series should also be relatively ASAN > >and UBSAN clean, as Tor has been tested > >with them since late 2014. > > I've run 0.2.4.x and 0.2.5.x with ASAN > live in production with no problems > when the relay had less bandwidth. > Performance hit is something like > 30% extra CPU. Also had it on > libssl.so and libevent.so, but > was too expensive to run on > libcrypto.so. > > UBSAN seems expense and doesn't seem > it would run other than test, but > I didn't work on it long and am not > 100% certain. Was trying ASAN extra > stack checking at the time, which may > have been the culprit. As I said in my previous email, if you're running releases before 0.2.6.6 (2015), Tor won't run under UBSAN due to issues that have been fixed in subsequent releases. If you're running on architectures other than x86_64, Tor won't run under UBSAN due to a known issue in the donna C code. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0