- tor-relays - lists.torproject.org

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 10 Jun '17

10 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

Mail delivery failed : returning message to sender
by 6465ec09＠opayq.com 08 Jun '17

08 Jun '17

This message was created automatically by mail delivery software at Junk Email Filter. The message from "lists.torproject.org [Masked]" <FWD-737QLY3MGNAYQYGGAHICDII6EY4CAKZCFW6DEJZFHAADYYFABL5ABZTBS4AFSQCOACGAA6IMFJSMAAZAJZAAAIA=(a)opayq.com> is being returned by server opayq-outbound.junkemailfilter.com on Wed, 07 Jun 2017 21:17:32 -0700 A message that you sent could not be delivered to all of its recipients. NOTE: And this is important - Junk Email Filter is a front end spam filtering service. We accept email for our customers, filter it, and pass the good email on. Sometimes when we forward email as good the server we forward to rejects it. Generally if you are getting this message it is because the server we forwarded to * NOT JUNK EMAIL FILTER * has rejected the message. If you see below the phrase "error from remote mail server" then it is the server who we are forwarding to, NOT US who is rejecting the email. Read the reason carefully and see if you can correct the cause of the rejection. The following address(es) failed: m.terlinde(a)gmx.de host mx01.emig.gmx.net [212.227.17.5] SMTP error from remote mail server after HELO opayq-out-00.junkemailfilter.com opayq-outbound.ctyme.com: 500 Syntax error, command unrecognized

1 0

libzstd and/or liblzma
by Felix 07 Jun '17

07 Jun '17

>> Can somebody please help me understand the change log for >> 3.1.x: "Support for these algorithms requires that tor is >> built with the libzstd and/or >> liblzma libraries available." Is it AND or OR or something whatever >> different ? > > > Hi! Let me try to clear it up: > > If Tor is built with liblzma available, it will use liblzma when > appropriate. The lzma format is expensive to calculate, but it > provides very good compression, so we only use it for cases when we > can compress something once and server it many many times -- like > consensus documents, or consensus diffs. > > If Tor is built with libzstd available, it will use libzstd when > appropriate. The zstd format is cheap to calculate, but appears to > provide better compression than zlib on our data. > > If Tor is built with both libraries available, it will use either one > when appropriate. > > Of course, we can only use these compression formats when both sides > support them. Thanks. Clear to me. So 'Liblzma N/A' should not be an issue. -- Cheers Felix

1 0