- tor-relays - lists.torproject.org

Re: [tor-relays] Consensus Weight calculation
by Vort 21 Jun '17

21 Jun '17

>> Are there any news regarding that problem? > It's a complicated problem. > We need to work out why it is happening before we can fix it. I am not sure if I really can help with BwAuth's algorithms. But that's what I would do in such situation: First, most important thing, is a clear goal. As BwAuth's task is to make a measurements, then theirs result must be clearly defined. So, the question is - how an ideal "w" ([Consensus] Weight) looks like? Suppose we have some perfectly measured parameters for relay: perfect_measured_bandwidth (KiB/sec) and perfect_measured_latency (sec). Their exact definition can be omitted now for simplicity. Then ideal_w should be equal to: ideal_w = perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth / perfect_measured_latency or, maybe, something else? Once this question is clear, then it is possible to see how existent implementation is far from this ideal. And here is part two: why it is different? It is some noise that can't be eliminated? Or algorithm for some reason converges to incorrect values? BwAuths have some debug information. This can help to investigate problem. There are also the possibility of doing manual checks. Which then can be compared to debug logs of BwAuth. Maybe my approach is not so good and you will choose another. But, anyway, thanks for working on this problem. -- Vort

1 0

Exit notice in Spanish
by ilv＠torproject.org 20 Jun '17

20 Jun '17

Hola, I wanted to let you know that at derechos digitales we wrote a basic tor exit notice in spanish. You can find it in [1] and a mirror in [2]. We look forward to receive feedback from the community to improve it (content, ui, etc), hoping that it could be useful to other relay operators. We have also added legal info of some countries. Feedback and contributions in this matter are welcome as well :) p.s.: someone on global-south list also told me about [3]. [1] https://0xacab.org/tortola/exit-notice [2] https://github.com/derechosdigitales/tor-exit-notice [3] https://github.com/chgans/tor-exit-notice Saludos. -i

1 0

I would lime to poste on this list
by Andree-anne Tremblay 20 Jun '17

20 Jun '17

Tank you

1 0

sharing tor relay at night or working hours ? make sense ?
by Zalezny Niezalezny 20 Jun '17

20 Jun '17

Hi, I have 100mbit Up/Down connection at home. Most of the day, my connection is not use. Mostly between 22:00-17:00. I would like to share my Internet connection for Tor. If I will setup some crontabs to start/stop my tor relay between that hours, will it work ? Does it make sense ? Will TOR network know that my relay is working only between 22:00 and 17:00 and will push some more traffic to me ? How to properly configure such a relay which is working only for a few hours per day ? Cheers Zalezny <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

7 8

libzstd and/or liblzma
by Felix 15 Jun '17

15 Jun '17

Hi nusenu thanks again for your responses ! > the context of that line is longer in the original changelog: > https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.3.1.2-alpha#n… That's where I got it from >> Might ports archivers/zstd only do the job (OR-type): >> >> Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on >> FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, >> Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 > > see the related comment by the FreeBSD port maintainer: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219571#c2 Good hint. When I follow the link I find the archivers/zstd port will be included which seems up to date (libzstd.so.1.2.0, 30 Jul 2016). That's what I did. Fine. Which is the right port for lzma ? When I try to include archivers/lzmalib (liblzma.so.1.1.0, 23 Sep 2008) I find it un-maintained, old and Tor does not configure for it: checking for LZMA... no configure: WARNING: Unable to find liblzma. checking for ZSTD... yes Is there a better lzma port ? -- Cheers, Felix

2 1

torservers.net: some exits became guards? (deanonymization risk)
by nusenu 15 Jun '17

15 Jun '17

Dear Torservers, are you aware that you have recently become a relay operator with end-to-end correlation (deanonymization) capabilities? (in fact you are the biggest known such operator) This is especially bad for tor clients because you are also one of the biggest tor exit operators. Some of your relays which used to be exits recently became guard-ony relays. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtor… Is there anything I can help you with to fix this and reduce the risk for tor clients? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 7

IP space for Tor exits - any takers?
by Moritz Bartl 12 Jun '17

12 Jun '17

Hi, After some trouble and ongoing discussions with one of our IP providers, we're again toying with the idea of registering IP space with RIPE ourselves. We can apply for a /22, which can be split into four /24s and announced at different locations (254 addresses each). Until now, we tried to avoid that, because we don't have enough "other things" to put on the same netblocks, so basically "one exit" would waste 254 precious IPv4 addresses (the full /24 address block needs to be announced from one location). But lately, with the rising amount not of abuse but of automated notifications and scared ISPs, and with the sponsoring of up to 10GE by Community-IX, we would really like at least one /24. Gareth from Brasshorn has graciously offered a spare /24 of his. The alternative would be that we apply for our own IP space, which would in turn mean that we could supply three other organizations with a /24 for their exit(s), or bridges. For bridges it is actually not that crazy, even if the range is "known" and easy to find: Most censors won't auto-detect them easily, and even if some do, the bridges are still valuable in many other locations. Also, this would allow for a bit of experimenting with tarpitting, different decoy strategies, etc. In terms of WHOIS information, the /24 can be segregated further, so an option would be to use a location where you have other uses for larger number of IP addresses. If you like the idea, and have actual use for a /24, please contact me off-list and explain what exactly you would like to do with it. If we have three other organizations (or reliable individuals) and a couple of good use cases, we're willing to apply for the /22. -- Moritz Bartl https://www.torservers.net/

1 0

Another relay is using the same name as mine.
by Alan 11 Jun '17

11 Jun '17

I just need some advice. I'm running 3 relays, one is called Andromeda. Today I find out there is another relay called Andromeda. https://atlas.torproject.org/#search/Andromeda mine is running from ip 144.217.161.119 Is it a problem with relays using the same name? Should I contact them and inform them of their error? Should I just leave it? Any advice would be very helpful. Alan.

3 2

published descriptor missing from consensus
by Scott Bennett 09 Jun '17

09 Jun '17

This time I'm stumped. I confess I have not followed this list for a long time until the last few days, so it's possible that I've run afoul of something already discussed. Late Wednesday afternoon, I restarted my relay (MYCROFTsOtherChild), which changed it from 0.3.0.6 to 0.3.0.7. That was the only change I made. It went through a normal startup and published its descriptor. After a few hours, tor noticed that its descriptor was still not in the latest consensus, so it republished it. After several more hours had passed with each consensus lacking my relay's descriptor, I made a small change to an ExitPolicy line in torrc. In the meantime, I had read some recent postings to this list and had noted some remarks regarding mismatched RSA and ED25519 keys, so I renamed /var/db/tor/keys and restarted tor again, whereupon it generated new keys and appeared to proceed normally. Once again a new descriptor was published and has since been republished and updated with no apparent problem beyond some republications being told by one or more authorities that the descriptor was rejected as "not new". Nevertheless, my relay's descriptor still has not appeared in a consensus since the last time it ran 0.3.0.6. If an authority operator would be so kind as to check the authority's logs for any errors pertaining to my relay with either its old keys or its new keys and let me know what they say, I would be grateful. Thanks for any help or suggestions of things to try. Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

6 19

2017-06-07 15:37: 65 new tor exits in 30 minutes
by nusenu 08 Jun '17

08 Jun '17

DocTor [1] made me look into this. _All_ 65 relays in the following table have the following characteristics: (not shown in the table to safe some space) - OS: Linux - run two instances per IP address (the number of relays is only odd because in one case they created 3 keys per IP) - ORPort: random - DirPort: disabled - Tor Version: 0.2.9.10 - ContactInfo: None - MyFamily: None - Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07 16:08:54 (UTC) - Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445', u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']} - table is sorted by colmns 3,1,2 (in that order) - Group diversity: - 20 distinct autonomous systems - 18 distinct countries https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/… Relay fingerprints are at the bottom of this file. This list of relays is NOT identical to the one from DocTor (even though the number is identical (65)): [1] https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/00796… https://twitter.com/nusenu_/status/872536564647198720 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 5