tor-relays

tor-relays@lists.torproject.org

38 participants
4819 discussions

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 13 Dec '16

13 Dec '16

1 0

Draft Fallback Directory List
by teor 13 Dec '16

13 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 12 Dec '16

12 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 12 Dec '16

12 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 12 Dec '16

12 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays