- tor-relays - lists.torproject.org

Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
by teor 02 Jun '15

02 Jun '15

> Date: Fri, 22 May 2015 19:29:43 +0500 > From: Roman Mamedov <rm(a)romanrm.net> > > On Fri, 22 May 2015 13:31:02 +0000 > Speak Freely <when2plus2is5(a)riseup.net> wrote: > > > Uhh, I would like to point out that it would be exceptionally stupid > > to have Tor autoconfigure IP addresses, regardless of whether it's > > IPv4 or IPv6. > > On IPv4 it currently does. There is zero rationale as to why IPv6 must be > different from IPv4 in this aspect. IP address autodetection is a useful feature for those servers which are dynamically assigned IP addresses. But it's not appropriate in every circumstance, which is why the ORPort and DirPort config options allow an IP address to be specified. It's only in the absence of a configured IP that autodetection is performed. Here are the enhancement requests in trac that need to be completed for IPv6 address autodetection: The enhancement request for Tor autodetecting IPv6 addresses is here: https://trac.torproject.org/projects/tor/ticket/5940 Since Tor normally autodetects its IPv4 address via its first directory request, this requires the directory authorities and/or fallback directories to be on IPv6 answering directory requests: Directory Authorities on IPv6 https://trac.torproject.org/projects/tor/ticket/6027 Fallback Directories on IPv6 https://trac.torproject.org/projects/tor/ticket/8374 Fallback Directories Initial Release on IPv4/IPv6 https://trac.torproject.org/projects/tor/ticket/15775 Clients/Relays will also need to query directory servers on both IPv4 and IPv6 to autoconfigure both addresses. Currently, directory requests are only made using the default IP protocol, or IPv4 (I'm not sure which). Once these client and server changes are in place, we then need to test clients to ensure they will bootstrap correctly: * When clients are on IPv4 only, mixed IPv4/IPv6, and IPv6 only; (3) Combined with: * On first run and subsequent runs; (2) Combined with: * When the directory authorities are available on IPv4 only, IPv4/IPv6, and IPv6 only; * When the directory authorities aren't available, and Fallback Directories are available on IPv4 only, IPv4/IPv6, and IPv6 only; (6) Combined with: * Using HTTP (DirPort) and Tunneled (ORPort) directory fetches. (2) 4 4/6 6 a4 Y Y f a4/6 Y Y Y a6 f Y Y f4 Y Y N f4/6 Y Y Y f6 N Y Y Y = Yes, Tor should bootstrap f = Tor should use other authorities or fallback directories with matching IP version(s) N = Tor should fail to bootstrap if it doesn't have access to any directories with matching IP version(s), and it doesn't have a recent consensus. Otherwise, it should find a directory with a matching IP version. This may involve a tunneled directory request if DirPorts are not available but ORPorts are, and Tor has enough information to tunnel over an ORPort (this might not apply in the first run case). That's a lot of different combinations that we need to test and ensure they work as intended. And I am concerned about the complexity of the "N" case. We'd appreciate any help on these IPv6 enhancements, particularly coding the server-side changes, as it's difficult to code and test the client-side changes without them. 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

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