- tor-relays - lists.torproject.org

asymmetry in connections
by Rana 19 Dec '16

19 Dec '16

On one of my relays I have 389 inbound, 38 outbound connections and 15 circuits What's the connection between these 3 numbers and why such asymmetry in inbound and outbound?

3 4

Cloning a relay - duplicate fingerprint
by Patrick DERWAEL 18 Dec '16

18 Dec '16

Hi list, I'm running a relay on a CentOS VM As I have lots of resources available, I wanted to duplicate that VM to bring more bandwidth to the Tor network --> cloned VM, changed IP and mac adresses, OS hostname, Tor nickname and restarted the Tor service Surprise: the fingerprint of the clone is identical to the one of the source VM I have stopped my clone to avoid any issue, but I guess I must have missed something... Any clue would be highly appreciated !!

5 6

is it possible to relay using ipv6?
by Flavio Leitner 18 Dec '16

18 Dec '16

Hi, I am trying to configure a relay for the first time but I am behind a cgnat for IPv4. I have a public and open IPv6 though. However, ORPort doesn't accept [ipv6]:443 and it doesn't automatically bind to :::443 either. This is running LEDE tor 0.2.8.9-1. I couldn't find if worth to run over IPv6 or not. Thanks, -- Flavio

10 25

"Up-and-coming" Ticket - 33C3
by pa011 17 Dec '16

17 Dec '16

Have Juniors interested in our work, likely to follow our steps or build new ones...need tickets for Hamburg 33C3 "Up-and-coming" would be great, but would consider "Standard" as well... Hopefully :-) Thanks and regards Paul

1 0

zencurity.dk relays: MyFamily update required
by nusenu 17 Dec '16

17 Dec '16

Hi, thanks for adding an additional relay to the tor network, please do not forget to update your MyFamily setting - especially because your new relay is outside of the /16 netblock of your other relays. And maybe update your tor version (0.2.7.6 is fairly old). https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+--------------+---------------+ | first_seen | nickname | MyFamilyCount | +---------------------+--------------+---------------+ | 2016-07-25 22:00:00 | kramse3 | 3.0000 | | 2016-01-07 22:00:00 | kramse | 3.0000 | | 2016-01-07 23:00:00 | kramse2 | 3.0000 | | 2016-12-16 14:00:00 | kramseturris | NULL | +---------------------+--------------+---------------+ regards, nusenu

1 0

Netflix overblocking non-exit Tor relays
by Gero Kuehn 16 Dec '16

16 Dec '16

tl;dr: Even paying customers sharing IPs with non-exit Tor relays are now blocked from accessing Netflix Hello everyone ! After two very fruitless attempts to get the issue silently resolved through proper Netflix support channels, the time has come to make this public. As some of you have probably already read in the news, Netflix recently announced a crackdown on what they call "VPN Pirates" and what I call "paying customers using the same benefits of globalization that global companies like Netflix (ab)use for their taxes". They have now obviously changed their strategy regarding the Tor network. I am operating (among others) a middle-relay on a German residential fixed-ip VDSL-50 line (dc6jgk1/486740353B905AA4731F82C0B4CC25821A62C6E3) behind a NAT. Until 2 days ago, none of the devices sharing the same external IP address had any problem connecting to Netflix and there never was a Tor exit relay on that IP as far as I can tell. It is also obviously not possible for users of the Tor network to connect to Netflix through middle relays. As a consequence they should not be classifying such IP addresses as VPNs/Proxies and they should not be blocking them. This has been escalated and explained twice to "technical supervisors" in their callcenters. They did however not leave the impression that they a) care or b) intend to fix this at some point by parsing the Tor network information properly instead of using whatever cheap&wrong hack they use now. The official response from Netflix is that you now need to make a choice between operating that Tor relay (of any type) and the ability to watch Netflix. They also strictly refuse to refund any remaining credit in the customer account. My personal choice with regards to that blackmailing is as clear my next steps (conditional cancellation, 14 day deadline for refund and a legal challenge of their German AGB with regards to this issue). I am allergic to being blackmailed like that and being called a pirate by a service I legitimately paid for. For those of you who just would like to contribute to the Tor network without having trouble like that, please do not let this nonsense stop you. A more diversified Tor network is a more healthy network and I would really like to see more normal users operating tor relays operating in as many different locations as possible - including DSL lines "that are there anyways". If you do not want to be put into a position where you have to choose between your contribution to the network and some legal and paid-for entertainment, you might want to operate only a bridge until the issue has been resolved. If you already have the same problem, make it as expensive for Netflix as possible and spread the word about why this block (and geoblocking in general) is wrong. Thanks ! Kind regards, Gero / dc6jgk

14 21

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi Peter unfortunately your message is empty, it only shows the signature. This occurs with all signed messages. I have no idea how to solve the problem.Mike -------- Ursprüngliche Nachricht -------- Von: Peter Ludikovsky <peter(a)ludikovsky.name> Datum: 15.12.16 07:22 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi J. I know. But I need a fan on top of the sinks. Just the heat sinks are not efficient enough. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 11:19 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? I meant aluminum heat sink, not a fanHeat sinks do not make noise, they are flat pieces of metal with rib structure for improved heat radiation. You glue them on the chips that tend to become hot as they crunch your Tor relay traffic. But hey, whatever turns you on J

1 0

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

J, TNX for the recommendation. Just used a spare one. Temperature dropped to 41 C. Didn't like the noise, because it's running permanentely. However, you are right :-) -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 09:34 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? Well I do suggest that you get a set of Pi heat sinks on ebay for $0.70 (including postage from China, adhesive and sinks for all 3 chips on the Pi). And if you are as extravagant as I you will even shell out an additional $1.20 for a Pi case. Your 20 mbps relay has some value, you do not want to step on it accidentally J From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 10:24 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? You are totally right. Besides the "cost" for the PI, I pay some additional Euros per month for the 40 MBIT upload, that's it. I really can recomment to run a relay on a Pi 3. Let's see how the Tor authorities handle this. By the way the CPU temperature levels around 60 Celsius (without running arm). I don't cool it. Mike Von meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 08:53 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? OK then let me summarize. 1. You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 kbps (measured) average utilization by Tor, with 1300 connections.2. Your Pi is under-utilized, probably limited by your ISP’s peering with those to which DirAuths are connected. 20% CPU utilization, 50% memory utilization. 3. Given that part of the memory is used by Linux kernel, and that the PI Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up to 3000 connections. Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 connections on another computer is probably a big waste of money. Comments welcome. From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 9:04 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

You are totally right. Besides the "cost" for the PI, I pay some additional Euros per month for the 40 MBIT upload, that's it. I really can recomment to run a relay on a Pi 3. Let's see how the Tor authorities handle this. By the way the CPU temperature levels around 60 Celsius (without running arm). I don't cool it. Mike Von meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 08:53 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? OK then let me summarize. 1. You are running a Pi from Cologne, at 21 mbps (measured) peak, 900 kbps (measured) average utilization by Tor, with 1300 connections.2. Your Pi is under-utilized, probably limited by your ISP’s peering with those to which DirAuths are connected. 20% CPU utilization, 50% memory utilization. 3. Given that part of the memory is used by Linux kernel, and that the PI Ethernet interface is nominally 100 mbps, the Pi is probably able to sustain up to 3000 connections. Bottom line: the $35 Pi is a killer and running a Tor node with up to 3000 connections on another computer is probably a big waste of money. Comments welcome. From: tor-relays [mailto:tor-relays-bounces@lists.torproject.org] On Behalf Of balbea16 Sent: Thursday, December 15, 2016 9:04 AM To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Tor relay from home - end of experiment? Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Pls. refer to may answers after each of your questions. -------- Ursprüngliche Nachricht -------- Von: Rana <ranaventures(a)gmail.com> Datum: 15.12.16 07:44 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Tor relay from home - end of experiment? >Hi There>This is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of >about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 >to 36 hours. From my point of view this is the only disadvantage. > >For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?>MikeMy experience is bad, the relay is not taking off at all, I have consensus weight of 19 and am sending less than 20 MB every 6 hours despite having bandwidth measured by Tor of between 70 and 120 KB/s. The total up bandwidth I have in ISP connection is 1.5 mbps and this is probably the issue. I also run this on Pi 3. I did, however, get a stable flag after 5 days, and have had it since then. My IP is dynamic and did not change in these 5 days or in the 4 days that passed since I got the Stable flag. My relay nickname is ZG0.Based on your experience I think your are doing fabulously well for a home relay, and that what really counts is the ISP bandwidth, and the Stable flag does not have much to do with how much traffic you get. Moreover, your 20% cpu util confirms my opinion that Pi is the perfect, most cost efficient way to run a relay and that running it on a larger computer is a waste of resources and money (up to the point Raspi chokes which we are yet to discover J)Moreover, clearly Pi’s cpu power will never be the bottleneck, only its memory size. You have a total of 1GB of memory on your Pi 3, what’s your memory utilization? about 513 MB What’s the total traffic the Pi sends every 6 hours (reported in the Tor log file /var/log/tor/notices.log and, for the previous time window, in /var/log/tor/notices.log.1)? About 19 GB in the last 6 hour period, with a total sent 2671.53 GB and received 2625.31 GB. What’s your relay’s nickname? Balbea16

2 1

Re: [tor-relays] Tor relay from home - end of experiment?
by balbea16 15 Dec '16

15 Dec '16

Hi ThereThis is a pretty interesting topic. I have been running a Rasp Pi 3 based relay since August this year. By now, I am up to about 1,300 incomming and outgoing connections, and a max of about 21mbps. This is about 50% of the max. upload speed. Consensus weight is between 3,000 and 6,000. The CPU is running at 20% max. However, my local ISP disconnects me after 24 to 36 hours. From my point of view this is the only disadvantage. For a home based relay, is that good, bad, or just average? Is there a chance for me to get a stable, or even guard flag? What are your experiances?Mike

2 1

Tor relay from home - end of experiment?
by Rana 15 Dec '16

15 Dec '16

After 9 days of running a relay with a stable IP address (with "Stable" flag during the last 4 days) and consensus bw steadily oscillating around 20 despite the 100 Kbyte/s bandwidth measured by Tor and 200 Kbyte/s bandwidth measured on the Internet connection, I guess it is time to quit. My relay is consistently sending less than 20MB every 6 hours, which probably means that is not making a noticeable contribution to Tor network. I have also been running another relay for the last 5 days from a friend's home - he has a static IP, a different ISP from mine and twice the bandwidth. His consensus is bw dead locked at 31 and never changes. He is getting Fast flag on and off, no Stable flag, his Atlas measured bandwidth is 150 KB/s. The traffic it relays is only slightly larger than mine, so I guess it is time to quit for this one, too. Any other advice / ideas welcome. Rana

6 17

Did you recently start >750 bridges?
by nusenu 14 Dec '16

14 Dec '16

Hi, If you recently added >750 bridges (without malicious intend) or know anything about it, please read this thread: [1] https://lists.torproject.org/pipermail/tor-project/2016-December/000851.html and get in contact with them (without disclosing the location of your bridges to the public). regards, nusenu

1 0

Does the "Advertised bandwidth" correlates with the "Consensus Weight"
by Toralf Förster 13 Dec '16

13 Dec '16

2 2

FW: Relay Shirt
by I 12 Dec '16

12 Dec '16

1 0

Draft Fallback Directory List
by teor 12 Dec '16

12 Dec '16

(This is a copy of the email I BCC'd to each relay operator on the draft fallback directory list. Please email me to add your relays.) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Relay Operator, One or more of your relays have been selected as fallback directory mirrors[0] for the next tor release. Please keep the relay available on the same addresses, ports, and identity key (fingerprint) for the next 2 years. This is a draft list.[3] I can make changes for the next week. Next weekend, I will send another email to those operators whose relays have been added or removed. (Otherwise, you're on the list.) We are taking 3 relays per operator, if you only have 1 or 2 on the list, please email me to add more. Wondering why your relay didn't make the list? Search the selection log[4] for its fingerprint. If the log says: * in neither blacklist nor whitelist, email me to add your relay. (I run a script that checks relays, then outputs a list.) If it says: * not a candidate: version delivers stale consensuses, * not a candidate: version not recommended, * not a candidate: changed address/port recently (on 0.2.7.6 or earlier), or * outdated consensus, upgrade to 0.2.8.9 or later, or 0.2.9.5-alpha or later. If it says: * bandwidth too low, * download too slow, * HTTP Error 503: Directory busy, * or some sort of download connection error, it might help to give your relay more memory or bandwidth. (And please make sure it's still running!) If it says: * not a candidate: changed address/port recently, * not a candidate: guard avg too low, * not a candidate: running avg too low, or * not a candidate: v2dir avg too low, your relay needs to be consistently up with high bandwidth to help clients. Try keeping it stable for 6-12 months, and it might be selected next time. But don't worry, your relay(s) are still helping the tor network, even if they are not selected as a fallback. Tim [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [3]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… (or [8] if you want to see what the git commit will look like) [4]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [8]: https://github.com/teor2345/tor/blob/new-fallbacks-028-v2/src/or/fallback_d… From: teor <teor2345(a)gmail.com> Subject: Call for Tor Fallback Directories Date: 4 December 2016 at 21:44:39 AEDT To: tor-relays(a)lists.torproject.org Dear Tor Relay Operator, Your relay(s) can help tor clients find the tor network by becoming a fallback directory mirror.[0] These mirrors are hard-coded into tor's source code, like the directory authorities. We have 80 fallbacks, but we want 200 for the next release. Fallbacks need to have: - - the same IP address(es) and ports for the next 2 years, - - the same relay identity key for the next 2 years, - - good uptime (at least 95%), and - - good bandwidth and network connectivity (we estimate an extra 25GB per month). Please email me to add your relays that fit these criteria to the list. If you are BCC'd on this email, it looks like you have at least one relay that could become a fallback. You can also email me if you know your relay will be changing address or key, and I'll make sure we don't choose it. We are keeping the fallback lists from the last release[1][2]. So if you have emailed me before about becoming a fallback, there is no need to email again. But please let me know if your relay details have changed. (I did not BCC relay operators who are already on the fallback lists, unless their relay details changed.) In a week or two, I will run a script to select the hard-coded list for the release. If you're interested, here's some background to this request: The latest list[3] and log[4] of candidates was generated using the instructions in [5] from scripts/maint/updateFallbackDirs.py on my GitHub branch[6]. (This branch has some bug fixes compared to what's in master.) We're tracking this work in [7]. (links updated to the latest code and relay list) [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [1]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fall… [2]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/fall… [3]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [4]: https://trac.torproject.org/projects/tor/attachment/ticket/18828/draft_fall… [5]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [6]: https://github.com/teor2345/tor/blob/fallbacks-201612-v4/scripts/maint/upda… [7]: https://trac.torproject.org/projects/tor/ticket/18828 T -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYTT+RAAoJEEUMun+WjwlLjdMP+gNwaBXpxrBy5e/0DJKoqpna /exFMCaLk1UNh5sko6IgCY+C4NbjCqwZ2NX78iJsLNzEyy+mXS/SoAeygSgiGIea d7ZgLlsj0z6JHYV/vqvKp3xs0lSUJIhd3tsaJWSZqylZVdDVzeE4o+kJtXMlOrk9 lnb+Xo9HzBKiWjSObnnli6+I4v5Z6SHidR7SYGe1N4bavDTrjnl6BCpS64QlrGwp mnM9iPNmv491soVMAKvgDX0dx6UncO6x+88jWa9OBHvkFPjNw7YQVMHsa4ltDfZQ kR2XinhpSYrvP/JFieXSP0DYNgaSdMhaKApStPs8xxP/RPfqioAcV3BopRVi0SpA jie9Z7wHUbtAZEobKpb4a8cnkfwB2j4GmVIlnSwXHmEipwCOI+Eat2qfFL6Z2xMo 0qLE7YDa3Fmjl9fbyU5H7fDgJUGMiSipEmKeC32wXfTVY424Fb3V4SXHS2qTCuQc QsfoW+12gXBemGSGAJRhvG46iG6u7+Xg/K8El+URU0Tk+QfRIGDzyLVNNQxuAuyl PtXBgxAbERh5uC8cyiKi9EugMx6NzRFtxto74XLdAuCGzbSD3HfNOEh43i/JwScO mo4bUC/bPXgtQGLCtbP8j+ieneSZom10vjspahrhasyNpFntaPor7+PvZ1vuA0JR rTv/DEYIjv6oKAstwT+C =APJ7 -----END PGP SIGNATURE----- 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 ------------------------------------------------------------------------

3 7

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons.Mike -------- Ursprüngliche Nachricht -------- Von: Patrick DERWAEL <patrick(a)derwael.be> Datum: 12.12.16 06:41 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX John, The host has 32GB RAM& 4 CPUs I have allocated 2GB & 2CPUs to my VM As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) P. 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: Patrick, I run all of my relays under VMware and I don't have any issues at all. How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? John On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Patrick Derwael Rue de la fontaine, 3 4210 Burdinne G:0479.80.50.79

3 2

Re: [tor-relays] Second relay on same ESX
by balbea16 12 Dec '16

12 Dec '16

Hi Tim,TNX for your fast response. That was more or less what I thought already. Mike -------- Ursprüngliche Nachricht -------- Von: teor <teor2345(a)gmail.com> Datum: 12.12.16 07:28 (GMT+01:00) An: tor-relays(a)lists.torproject.org Betreff: Re: [tor-relays] Second relay on same ESX > On 12 Dec. 2016, at 17:08, balbea16 <balbea16(a)gmx.de> wrote: > > Hi > Are you actually talking about identical relays, i.e. with the same fingerprint? That would be interessting for me, as I'd like to run a second Rasp Pi in parallel for redundency reasons. > Mike Please don't run a second relay on the same fingerprint. Your relay won't get much traffic, because it will look like its address and ports are changing all the time. Instead, run two relays with different keys, and let the network load-balance between them. Tim > -------- Ursprüngliche Nachricht -------- > Von: Patrick DERWAEL <patrick(a)derwael.be> > Datum: 12.12.16 06:41 (GMT+01:00) > An: tor-relays(a)lists.torproject.org > Betreff: Re: [tor-relays] Second relay on same ESX > > John, > The host has 32GB RAM& 4 CPUs > I have allocated 2GB & 2CPUs to my VM > As the VM CPU usage is +/-40%, I'm not sure if I should reduce to 1CPU (would it then be used at 80% average?) > > P. > > 2016-12-11 18:22 GMT+01:00 John Ricketts <john(a)quintex.com>: > Patrick, > > I run all of my relays under VMware and I don't have any issues at all. > > How many CPUs do you have in the physical server and how many virtual CPUs do you have assigned to the VM? > > John > > On Dec 11, 2016, at 11:19, Patrick DERWAEL <patrick(a)derwael.be> wrote: > >> Hi guys, >> >> I'm running a relay in a VM on a physical server which is largely under used >> Current advertised bandwidth 26MB, consensus 76500 >> I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: >> >> - is there any issue running it at the same geographical place? >> - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? >> - basically, would it have any significant added value to the network? >> >> Thanks >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > -- > Patrick Derwael > Rue de la fontaine, 3 > 4210 Burdinne > G:0479.80.50.79 > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays 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 ------------------------------------------------------------------------ _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Second relay on same ESX
by Patrick DERWAEL 12 Dec '16

12 Dec '16

Hi guys, I'm running a relay in a VM on a physical server which is largely under used Current advertised bandwidth 26MB, consensus 76500 I'm considering running a second relay (2nd VM) on the very same hardware, but this brings a few questions: - is there any issue running it at the same geographical place? - would the current total BW effectively consumed (26MB) be divided in 2 (i.e. no added value in BW)? - basically, would it have any significant added value to the network? Thanks

4 5

network scan results for CVE-2016-5696 / rfc 5961
by dawuud 11 Dec '16

11 Dec '16

Greetings Tor relay operators, First of all, if you operate non-Linux Tor relays then good job! Thanks! This notice isn't for you. Only Linux is affected. This morning I scanned the tor network for vulnerability to CVE-2016-5696 [1], again so that I could compare the results with the scan from last month. Linux implemented RFC 5961 [2] using a global counter which can be used as a side channel allowing blind TCP injection and other consequences as well. I used this collector consensus file for my scan: https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-… That's 7080 relays. The scan produced: 246 relays had connection timeouts and were not scanned. 60 relays had connection refused. 6795 relays scanned. 2034 relays are vulnerable according to the rationale I used a month ago to categorized the results as vulnerable (if the probe response receives between 90 and 220 Challenge ACKs). These results should be reproducible. The source code to the scanner is here: https://github.com/david415/scan_tor_rfc5961 Last month's scan showed 4069 vulnerable relays. Each probe does a TCP handshake and then sends 500 in-window packets and counts the resulting Challenge ACKs. (followed by a TCP connection close). However we've updated the buckets of probe results to this: "r == 0" : "zero challenge ACKs", "0 < r <= 10" : "probably new kernel", "10 < r <= 20" : "maybe new kernel?", "20 < r <= 90" : "inconclusive?", "90 < r < 100" : "probably vulnerable", "(r%100)==0 and 0<r<500" : "almost definitely vulnerable", "(r%100)!=0 and 100<r<450" : "probably vulnerable", "(r%100)!=0 and 450<=r<=490" : "inconclusive?", "490 < r < 500" : "most likely applied sysctl workaround", "r == 500" : "probably applied sysctl workaround", "500 < r" : "extra duplicate packets?", The researchers who discovered this vulnerability published an excellent paper [3]. Although they incorrectly described an attack on tor's path selection it may be possible that other attacks on the Tor network are possible. I think it would be better to upgrade and reboot your relays rather than risk the Tor network's exposure to attacks that may utilize CVE-2016-5696 in combination with other techniques. Furthermore being vulnerable to CVE-2016-5696 also implies that you have a Linux kernel which is also vulnerable to dirty COW; https://dirtycow.ninja If you operate a relay you can check to see if your relay's TCP stack has counted many TCP Challenge ACKs. Please let us know if your counters have very high values. Vulnerable Linux kernels will have snmp stat counters like this:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 113338 TCPSYNChallenge: 1157 High counter values maybe indicative of attacks. Linux 4.7.x has got a per socket rate limiting feature which if it has a high value may also be indicative of attack attempts and probing:: root:/# netstat -s | grep -i challenge TCPChallengeACK: 2614 TCPSYNChallenge: 442 TCPACKSkippedChallenge: 141795 If you are too lazy to upgrade your Linux kernel and reboot then you may apply a convenient workaround: sysctl net.ipv4.tcp_challenge_ack_limit=9999999999 read more about this workaround here: https://blogs.akamai.com/2016/08/vulnerability-in-the-linux-kernels-tcp-sta… Special thanks to Least Authority for supporting my research. sincerely, David Stainton 1. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5696 2. https://tools.ietf.org/html/rfc5961 3. Off-Path TCP Exploits: Global Rate Limit Considered Dangerous http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf

12 29

Inconsistent BW measurements of unused relay
by Rana 11 Dec '16

11 Dec '16

My relay remains severely under-used. One thing that bothers me are inconsistent bandwidth measurements. Here they are: Atlas "advertised" (which is actually supposed to be "measured"?: 100 KB/s = ~ 800,000 bit/s "I have sent" reported in Tor log: on the average pretty stable 17 mbytes every 6 hours = ~ 200 bit/s Atlas graphs: 1 Kbytes/s on the average ~ 8,000 bit/s Consensus BW: 26 = ~ 26,000 bit/s Average upload bw reported by arm: 100 kb/s = ~ 100,000 bit/s Makes zero sense.

3 8

ansible for tor relay ops
by nusenu 11 Dec '16

11 Dec '16

> You are quite often referring to Ansible which is new to me. Is there > a permanent free version around to let your > https://github.com/nusenu/ansible-relayor run on it? Yes ansible is free software and you can install it with your preferred package manager (depending what OS you use). > Isn’t it somehow dangerous in the area we operate, to rely on a piece > of software created more or less by a single person? Thanks for this question. Can you give a few examples for "dangerous" in the context of your question so I might be able to address your concerns more specifically? thanks, nusenu

2 1

Atlas - location of relay changed
by Duncan Guthrie 10 Dec '16

10 Dec '16

Hi folks, My Tor exit, ecntor, recently changed from being listed in the UK to being listed in Canada, without any input on our part. On the IRC channel, I was reassured that this was not a bad thing, that GeoIP is inaccurate, for example. However, I am interested in what might have caused the relay to change location listing like this? Thanks, Duncan

2 1

Connections from UNKNOWN relays
by Rana 10 Dec '16

10 Dec '16

Arm shows that my middle relay has incoming connections from UNKNOWN relays (no consensus data on them at all except locale). Are these bridges? There is also one outgoing connection to UNKNOWN but the address of that is 0.0.0.0:0

3 3