tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

Bridge Offer
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, If there is still not enough bridge capacity available after a few people already offered their help, i would be able to help with 400 Mbit (no traffic limit). -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Fwd: Call for a big fast bridge (to be the meek backend)
by Mike Perry 18 Sep '14

18 Sep '14

Forwarded from tor-dev to here, in case any relay operators missed this: ----- Forwarded message from David Fifield <david(a)bamsoftware.com> ----- Date: Mon, 15 Sep 2014 19:12:23 -0700 From: David Fifield <david(a)bamsoftware.com> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Call for a big fast bridge (to be the meek backend) User-Agent: Mutt/1.5.23 (2014-03-12) The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning. All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine. The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- End forwarded message ----- -- Mike Perry

3 2

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 18 Sep '14

18 Sep '14

On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> Hello -- >>> So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not >>> also have port-based entrance policies? I >> >> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >> >> > > @Toralf > > Correct, this has nothing to do with firewalls. This is more about better utilisation of slow > circuits/relays by deliberately choosing to push relatively lightweight traffic across them. > IRC and XMPP do not need 10Mbit/s circuits, not even close. > > I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that > > a) there are probably more slow relays than fast ones > b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of > candidates for each. > > I'm just looking for ways to drive more traffic across slow relays. :) Paritesh, I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) T

3 2

BBC and UK Lottery blocking ip addresses running relay nodes
by Dan Hanley 18 Sep '14

18 Sep '14

All I can see there was a previous thread related to this in June, but thought I'd add what I'm seeing to the discussion. After the *Data Retention and Investigatory Powers Bill (DRIP) *was rushed through parliament I decided to do my bit for the privacy cause and run a couple of Tor relays. I run one from my laptop at home and one from my desktop at work. Since doing this I have suffered deliberate disruption in service from the BBC and the National Lottery. A Tor relay is a node on The Onion Router network that traffic gets router through to anonymise where it originated from. ( https://www.eff.org/torchallenge/what-is-tor.html) Note that I am running middle relays, not exit relays, so the connection to the destination site will never come directly from one of my relay nodes. Neither have I used the Tor browser to access either site. *The BBC* Within 48 hours the http://bbc.co.uk website started redirecting me to the http://bbc.com international version. They seem to think I am no longer a licence payer, or perhaps conspiring to allow non licence payers to access their UK service. The redirect is based on my homes IP address, so all devices, laptop, phone, ipad etc get redirected. The redirect seems to trigger via Javascript, I can access http://www.bbc.co.uk with Javascript disabled. The international site recognises that my ip address is in the UK and refuses to let me access international content. The net result is that I and my family can no longer access either UK or international BBC content. *The National Lottery* The Lottery allows me to connect and browse their site but as soon as I try to make a purchase I get blocked: *Why is this odd:* Any of the popular IP checking sites/tools show that my address is located in the UK: e.g www.whatsmyip.com or https://who.is I am using two different ISPs (Zen and VirginMedia) neither can explain the behaviour. Contacting the lottery they blame the ISP, I have been unable to get a response from the BBC. Assuming I can believe the look up services and the ISPs that my IP addresses are still located in the UK, the only explanation I can come up with is that the BBC and the lottery are deliberately blocking ip addresses that are registered on the Tor network. Whether they do this independently or avail of a common third party is unknown. So the cost of trying to maintain privacy seems to be the loss of BBC and Lottery – which seems unfair. Regards Dan

4 4

help force Centos to update Tor
by I 18 Sep '14

18 Sep '14

Hej, (With very little knowledge) I can not get Centos 6 VPS to update to the newer version of Tor. Would someone please help me to do that? off list of on Robert

1 0

Multithreading
by Sebastian Urbach 17 Sep '14

17 Sep '14

Hi, Is someone able to provide a timetable for the multithreading implementation into the alpha branch ? I'll take anything ;-) Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 4

Port-Based Best-Fit Circuit Selection
by Paritesh Boyeyoko 16 Sep '14

16 Sep '14

Hello -- First of all, let me apologise if this has been covered before on this list. A couple years ago I took more than a passing interest in Tor and decided to run a non-exit relay on a VPS, which lasted until an upstream provider complained. I've recently set up another one, and while it settles into the network, it got me thinking about utilization. Much has been made of the fact that Tor is circuit-based rather than packet-based, and also of the fact that faster relays attract more traffic. So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not also have port-based entrance policies? In other words, cause deliberate selection of a "slow" path based on the protocol intended to be used. So for example, HTTP would favour faster circuits, while the likes of email (POP, IMAP, SMTP), XMPP and IRC would favour slower circuits (being mostly text-based). Perhaps the entrance policies could be maintained on-network (perhaps with "authority servers", with clients downloading the policies when they start up, rather than having them hard coded or configured client-side? Just some ideas. :) Best, -- Paritesh Boyeyoko parity.boy(a)gmail.com

2 2

Understanding Reduced Exit Policies..?
by Jeremy Olexa 13 Sep '14

13 Sep '14

Hello, I've setup a non-exit node so that I can contribute and understand the TOR network somewhat better. I've only had my node (jolexarelay1) up for a few weeks so it is still becoming a part of the network at guard status. So, as I understand my ISP, I can run an exit node if I "handle" abuse complaints to their standards. Now, since I have more idle bandwidth than idle time to "handle" complaints, I've often wondered about the reduced exit node strategy as seen at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy - I'd like to allow ports in a methodical fashion such that I can test to see if a port generates complaints easily/quickly. My question: If I want to "try" being an exit node and add allowed exit ports slowly, does that help the network or not? For example, month 1: allow port 22, month 2: allow IRC ports, and so-on. How does the client path selection work in this case - is it smart enough to pick my exit when needed? Thanks for any insight, Jeremy

3 3

request at Hetzner
by Toralf Förster 13 Sep '14

13 Sep '14

3 things: 1. ========= This is what I get few days ago from Hetzer Support: >Guten Tag Herr Förster, > >laut Deutschem Recht sind Tor Server im Moment nicht verboten. >Aus diesem Grund sind Tor Server bei uns auch nicht verboten. >Aus Erfahrung raten wir jedoch vom Betrieb eines Tor Exit Node ab. >Leider wird oft ueber Tor Server Content verbreitet welcher laut >Deutschem Recht >nicht erlaubt ist. Dies kann Ermittlungen von Behoerden nach sich >ziehen. Maybe worth to update https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs ? 2. ========= I'm planning to setup there a dedicated server now soon (with Gentoo Linux if possible) within next days - or are there too much servers already at the ISP Hetzner ? 3. ========= And for the following days I do want put the line "ExitPolicy reject *:*" before all subsequent liens like "ExitPolicy accept *:20-23 # FTP, SSH, telnet" of the reduced exit policy to just look how the system behaves as a simply relay. Worth or superflous ? Am I right, that later just commenting out that reject line enhance the Tor server from relay to "relay + exit node" ? Or does this mean that -- Toralf pgp key: 0076 E94E

6 9

What to change for v0.2.5.x?
by Steve Snyder 13 Sep '14

13 Sep '14

So now Tor v0.2.5.x Release Candidates are available. Can someone give an overview of what's new for those who don't follow the development process? What can/or should be changed in a working v0.2.4.x relay config to accommodate the changes made in the new code? Are there particular areas (IPv6, multi-threading, etc.) that one should be aware of when moving from v0.2.4 to v0.2.5? The changelogs do a great job of describing the changes between point releases but are somewhat overwhelming when attempting to determine the differences between major releases. If would be great if someone could give a brief(-ish) description of those changes. Thanks.

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays