tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts
by teor 02 Jun '15

02 Jun '15

> Date: Sun, 24 May 2015 08:47:20 +1000 > From: Zenaan Harkness <zen(a)freedbms.net> > >> 3. Disable the polipo proxy on the Tor relay in your network, you do >> not need that. Run a bridge instead of a relay. Make it a non public >> bride (PublishServerDescriptor 0) and run Tor Browser on all the >> computers in your network with UseBridges 1 and define the ip:port of >> your bridge and connect it directly, no proxy setting. This way other >> 'strangers' won't be able to use your bridge and you will also not >> need the Guard flag or uptime and bandwidth requirements. > > That last bit (UseBridges 1, configure bridge IP), looks like it does > the job needed here, no new Tor config options required. There are 3 different ways to set up your local bridge, each with their own pros and cons: 1. Configure a private bridge * Only your clients use this bridge * No cover traffic 2. Configure a bridge distributed by BridgeDB * Your clients and other clients may use your bridge as the first hop * BridgeDB doesn't distribute all bridges straight away, so you may or may not get cover traffic * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all bridge traffic 3. Configure the server as a relay, but configure the clients to connect to it as a bridge * If you configure a client with a mandatory guard relay using EntryNodes and StrictNodes, the relay must have and maintain the guard flag. But configuring clients with a relay server in a "bridge" config line avoids the need for a guard flag. * Your clients use this bridge, as do other clients as at least a middle hop, and a guard or exit hop depending on flags * You get the most cover traffic this way * You can't separately rate limit external and local traffic at the bridge itself - RelayBandwidthRate includes all relay and bridge traffic * This mode of operation is less common, and may reveal some bugs in Tor. In my experience it has worked fine for months with 0.2.5 - 0.2.7-alpha, but please report any issues on https://trac.torproject.org/projects/tor/ticket/1776 * As a precaution, if you ever reconfigure a relay Tor node as a bridge Tor node, please delete the keys so it appears as a new bridge in BridgeDB. 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

IPv6 adress valid?
by tor-server-creator＠use.startmail.com 01 Jun '15

01 Jun '15

hi, is that IPv6 adress valid for example "becks" [2a01:4f8:162:7345::2]? how do i know if IPv6 is correct and reachable? thanks

4 3

[warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server.
by Martin Ekendahl 29 May '15

29 May '15

This morning I rebooted my relay after some patching. I was running 2.6.7 on Ubuntu 14.04.2 LTS from. The server is always a bit slow rebooting but when it came back up always check the Tor relay and now I see an excessive amount of these errors: May 29 12:20:36.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 906; recommendation warn; host CC23B32FA040945FF49D94AC3D4334429CB4E2CD at 62.75.241.71:1110) May 29 12:20:36.000 [warn] 905 connections have failed: May 29 12:20:36.000 [warn] 849 connections died in state connect()ing with SSL state (No SSL object) May 29 12:20:36.000 [warn] 42 connections died in state handshaking (TLS) with SSL state unknown state in HANDSHAKE May 29 12:20:36.000 [warn] 8 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSL negotiation finished successfully in OPEN May 29 12:20:36.000 [warn] 2 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (TLS) with SSL state SSLv3 read finished A in HANDSHAKE May 29 12:20:36.000 [warn] 1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in CLOSED I still see about 7000 inbound connections and 3000 outbound, I'm not sure what my connection average is, but the current bandwidth being used is below average (from the reboot). There have been a couple DDOS alerts from my ISP the past couple days, something I never used to get. I can confirm via my dashboard nothing has been mitigated so I assume no filtering is going on, and traffic is still coming and going, but for some reason there are a lot of connections not being made it appears from the logs, and these only started appearing after I restarted my server/relay. Any ideas what would be causing all these issues?

1 0

Get bridge
by Victor Victoe 28 May '15

28 May '15

2 1

Re: [tor-relays] Leaseweb exit relay notice
by tor＠t-3.net 25 May '15

25 May '15

On 05/25/2015 08:17 PM, Rejo Zenger wrote: > ++ 25/05/15 12:48 -0400 - tor(a)t-3.net: >> >> A lot of trouble would be prevented for exit node operators if, when they >> brought their relays up for the first time, they ensured that the exit policy >> rejected port 25. Even if they desire to run as unrestricted a relay as >> possible, in my experience, that one really should be rejected. It is the > > Some (or most or even all) of the Leaseweb nodes didn't forward port 25. > So, alltough you advice is a good one, it's not applicable to some (or > most or even all) of the nodes that are discussed in this thread. > I'd be curious to know what this checker says about the IP address that ultimately got this ISPs attention: http://mxtoolbox.com/blacklists.aspx I run 2 fast exits with only ports 25 and 465 rejected. I find that the IPs are in some expected lists that target Tor, plus barracuda and spamhaus-zen. But not a gigantic pile of RBLs like was being described. No sorbs, no spamcop, no uceprotect. Nothing like a real spamming box. Doing nothing on email ports but still ending up on a meaningful number of RBLs doesn't sound right. Maybe all it took to piss the ISP off was for one of them to do it.

2 1

Re: [tor-relays] Leaseweb exit relay notice
by tor＠t-3.net 25 May '15

25 May '15

On 05/22/2015 12:19 AM, Speak Freely wrote: > The problem is compounded by the fact each BL company is racing it's way > to the bottom, adding each others finds to their own lists. SpamHaus has > OVER 1 *BILLION* addresses listed. > > I lost several relays (11) from OVH because DanTor recorded my relays, > then CBL recorded DanTor, then SpamHaus Zen recorded CBL, which allowed > OVH to claim "100% of your IPs are blacklisted on multiple lists" when > in reality it was from a guy in the UK who publishes all Tor relays - > guard, middle, exit - that caused this whole problem for me. Not one > single complaint from anyone against any of my relays. > > > Matt > Speak Freely > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays A lot of trouble would be prevented for exit node operators if, when they brought their relays up for the first time, they ensured that the exit policy rejected port 25. Even if they desire to run as unrestricted a relay as possible, in my experience, that one really should be rejected. It is the port which email servers tend to use to deliver mail to one another, and some bad/old clients might try to use it as well. In theory, open-relay port 25 is just about sending email. It can send email on behalf of anyone in the world. Big deal, right? But in practice, open-relay port 25 is all about spam. Has been for years and years. It's always been abused by awful spammers wherever it may be found. It's never been used as some great tool for anonymity or email freedom. As far as Tor exits go specifically, there is someone out there who is apparently watching Tor for when exits appear that are willing to send on port 25. They very quickly begin dumping spam out of any such relays, should they appear. I know this because I briefly turned on relay for port 25, and the spammers found it fast. They immediately transformed it into a spam-vomiting heap of crap. Traffic graphs on it skyrocketed (although within the configured maximums). The new mail in the admin mailbox for the netblock clearly reflected what the box was doing. I closed that port off fast, and problem solved. In addition to port 25, relay operators who want to be extra careful of their relationship with their ISP may also wish to reject ports 465 and 587. Doing that would more-completely lock the Tor exit away from the tricks spammers use. By blocking off the email portion of the relay (especially port 25), the machine doesn't spew spam, and therefore doesn't get noticed by those who are trying to stop spam. This is good for the relay because the 'net is more accepting of it (IP reputation lists, RBLs, etc), and good for the exit relay operator's working relationship with the hosting ISP. Reputable ISPs tend to dislike spam, and if a billion spam complaints flood in for your relay, it's not going to help your cause. People who are trying to do anonymous email have means to do so which do not include dumping anything directly to port 25. And if a direct push from Tor to 465 or 587 is wanted, it can always go to the relays which don't perceive any ISP-related risk from it.

2 1

[Fwd: Re: a line "enable IPv6 on your relay"]
by tor-server-creator＠use.startmail.com 25 May '15

25 May '15

sorry, i confused something. "relay should show in the consensus as an "a" line." does not mean a "a" is required in torrc. i got confued cause of the headline "1.1 Ordinary relays" stupid me, pardon -------------------------- Original-Nachricht -------------------------- Betreff: Re: [tor-relays] a line "enable IPv6 on your relay" Von: yl <tor(a)yl.ms> Datum: Sonntag, 24. Mai 2015 19:54 An: tor-relays(a)lists.torproject.org Am 24.05.2015 um 19:25 schrieb tor-server-creator(a)use.startmail.com: > shouldnt there be a "a" in the first line? how important ist the > letter > a? i guess some operators just added the lines without "a" like > above. > additional: how many ipv6 relays are up NOW? and are there plans to > include a button into torbrowser to enable/disable ipv6? Not sure where the a should be put, so maybe someone can just past a sample config with the IPv6 enabled, I think from that we can substitute easily. One question also, is this for relay servers or ONLY for exit enabled servers? yl _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 1

a line "enable IPv6 on your relay"
by tor-server-creator＠use.startmail.com 24 May '15

24 May '15

hi, about that following lines in the mail from Moritz Bartl. [tor-relays] Please enable IPv6 on your relay! > In short, you add: > ORPort [IPv6::address]:port > IPv6Exit 1 > ExitPolicy reject6 *:* shouldnt there be a "a" in the first line? how important ist the letter a? i guess some operators just added the lines without "a" like above. additional: how many ipv6 relays are up NOW? and are there plans to include a button into torbrowser to enable/disable ipv6? thanks

2 1

Complaint being on a tor dnsbl..
by 0x23 23 May '15

23 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hey guys, Today I got a complaint from my vServer hoster that has received an abuse email The company who accused the usage of my system is called sectoor http://www.sectoor.de/tor Here's the abuse message: More Information About Sectoor Listing on the Sectoor TOR DNSBL indicates that this IP address is a tor node or a subnet (/24) containing a tor node. This listing *does not* indicate that your IP address has been blacklisted by Sectoor, as this list also contains subnets that contain a tor node. The subnet listing is not designed to block connections, but rather for use as a scoring mechanism. Your IP will only be blacklisted if it is the tor node itself and listed by Sectoor Exitnodes. Sectoor TOR DNSBL lists every IP address which is known to run a tor server and allow their clients to connect to one of the following ports: * Port 25 * Port 194 * Port 465 * Port 587 * Port 994 * Port 6657 * Ports 6660-6670 * Port 6697 * Ports 7000-7005 * Port 7070 * Ports 8000-8004 * Port 9000 * Port 9001 * Port 9998 * Port 9999 More information about SECTOOR can be found at their website: http://www.sectoor.de/tor.php *Reason for listing - **TOR Server Network detected (TOR Node on ip xxxxxxxxxxx) - see http://www.sectoor.de/tor.php for more information.* What would you reply on that accusation? I tried to convey that this isn't true and that this company only tries to alienate me as a customer cause there also running vServer offers. For now I reject using these ports..:-( Regards - -- -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQIzBAEBCgAdBQJVYGegFhwweDIzIDxydXNoMjNAZ214Lm5ldD4ACgkQF7zsyb8G Yjgxwg//c4+j6BNmr7wzyxuH3C0T3iQMrF9gK5vfdU2nyRBSV4Hqbb8zIIc1+eQy 9XMqD+tZ0uUKtT6Q+Ket1y6zqCvX1fX4NpEMN6DWMyyRCnDa1m/AOU04PQpr6VIS TzZc93BYCv+Sw8Rdt24XyRRJ9u05vehY4fkjX4qgiGp9zZDgkpZsO06qzDa4zBXb 5oHRMlO2Q2ePYAsl53E78JUMD7+rphBdUmogGU0xpEWysBSFMGCMqQt6g5+zwqtB HABL95S85UKj1mZ3vj0kbi3/jMJYG0vL5+zqBvzUFIU5NlOrz0DFKG/O8uG8h6gA avyxzdpwtBIox/FYkNG2TWeJ00RscKJ/1u33WATwOTL0x5VkIehP9Njl7pnz4cO4 4SkpV7SSGAhqPVnVPvEcYLPBGuqZAyNV/0r0GZZUdQEC0J8+BsQgf77vr5vC4yTz P2/Fj5BVzhT2UxpNtRfFnhGu+KNmXbyiVJ17jDxNfeEl7uuDRgFCMc+Vg0fvl2LY mAOZuTwUyxbl+6Gyeob66RdSmhNERr8vGvGCv1TKvFuwry2hrQI5HFRiQpssGsHX k19Z4S999jBe8fdz4EevYMMwI1phWnT3eOoSJDc4jKkClrrYgTXqU1w0riMcyPGP wMo4gHv2Ie9dBki4VC4JXDGXCqehp9dyNjKwmEp5UTzPwO45bZE= =K+EM -----END PGP SIGNATURE-----

3 2

Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
by Roman Mamedov 22 May '15

22 May '15

Hello, > We still have a depressingly low number of relays that support IPv6 > (currently only ~120 of ~1900 relays). If your host supports IPv6, > please enable it, especially if you run an exit! This has to be done > explicitly. If you (supposedly) care so much, then can you please make it automatic? There is no need to explicitly put the ____IPv4____ address into the torrc. And there is no need to explicitly put the IPv6 address into the config file of virtually any other IPv4+IPv6 supporting software I can think of: web, mail, NTP, XMPP servers, those are all capable of automatically figuring out which IPs the host has. Can't think of any reason of why this has to be otherwise in Tor, aside from perhaps a certain lack of understanding of best IPv6 implementation practices from the Tor developers side and/or nobody simply giving much thought to this yet. I currently run 15 Tor relays, 14 of those IIRC are IPv6 capable. But since you did not bother to make enabling IPv6 in Tor anywhere near user-friendly [1], I am simply not going to bother pecking the IPs into each torrc individually. [ One of the practical reasons being that I sometimes need to migrate the Tor 'identity' (torrc + /var/lib/tor/*) between machines and providers with v4/v6 addresses obviously changing. ] Aside from migrations between providers, the requirement to specify the IP is also impractical in many other situations, e.g. my ISP at home provides only a __dynamic__ IPv6 subnet which changes to a different one with each new PPPoE session. [1] Ideally there should be no 'enabling' at all!!! IPv6 should be active by default, IF the relay has determined it is able to make a successful IPv6 connection with a dir-authority -- oh and also that's how you can discover the actual working IPv6 address to use; or at least with a simple "IPv6Relay 1, but certainly with no requirement of specifying the IP address in the config file. -- With respect, Roman

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays