- tor-relays - lists.torproject.org

A friendly reminder for all ScrambleSuit bridge operators.
by Yawning Angel 24 Sep '14

24 Sep '14

Hello all, This is a friendly reminder to all ScrambleSuit bridge operators that unless you are running tor-0.2.5.x, you should not be running a ScrambleSuit bridge. This is because the method for propagating the ScrambleSuit password (or any other future pluggable transport server side argument) for inclusion in the Bridge line served from BridgeDB was implemented in 0.2.5.x, and is not present in 0.2.4.x, and to make matters worse, 0.2.4.x has a bug that will allow this configuration to run instead of failing with an error[0]. If you are running a ScrambleSuit bridge with tor-0.2.4.x, it is useless. Users that happen to be served your ScrambleSuit bridge will not be able to connect, because the password is missing. Approximately 1/7th of the ScrambleSuit bridges in BridgeDB exhibit this behavior and we will most likely start filtering them on the BridgeDB side. Please see https://trac.torproject.org/projects/tor/ticket/13202 if you wish to know more about this. Best Regards, -- Yawning Angel [0]: Apparently this is not worth patching 0.2.4.x for, which I personally view as unfortunate.

1 0

Re: [tor-relays] Estimating the value and cost of the Tor network
by Tim 24 Sep '14

24 Sep '14

On 24 Sep 2014, at 13:38 , tor-relays-request(a)lists.torproject.org wrote: > Date: Wed, 24 Sep 2014 05:40:00 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Estimating the value and cost of the Tor > network > > Hi, > > Prices vary widely across different countries. We pay between $400 and > $1500 per Gbit/s per month in "popular and cheap locations". In a > scenario where we want to grow the network and at least keep the current > geographical diversity (or even grow it), we'd have to at least equally > strengthen less fortunate locations. > > The list of the top 20 countries [0] contains countries such as Russia, > Poland, Norway and Hungary, where international bandwidth is quite > expensive. Hopefully someone from this list can help us compile or find > estimates for pricing per country. It would be interesting to learn the > prices even for mid-size (~50-100Mbit/s+) relays in any country outside > of the top five countries, even more so for crazy places that don't make > the top 20. > > Another factor that we should not ignore is that, while it may be > possible to find a set of ISPs that allow mid-size exit relays, it gets > harder the more traffic you push, because of the additional workload > (and scariness) for the ISP from complaints. > > [0] https://compass.torproject.org/ > > -- > Moritz Bartl > https://www.torservers.net/ Mike, Moritz, Re: crazy places that don't make the top 20 I've noticed that most of the Tor network is concentrated in the northern hemisphere, particularly Europe and North America. I assume the distribution of authorities is similar. Apart from China, no Asia-Pacific country makes the top 20 in Tor compass.[1] And no southern hemisphere country makes the top 20 at all. The first Asia-Pacific countries after China are Japan at #29, then Singapore at #37. And unless I've missed something, the first southern hemisphere country is Australia at #42. Details aside, I'd love to see more routers and exits in countries other than the top 4 (Germany, France, Netherlands, United States). This helps spread failure risk, sovereign risk, and the risk from 3 letter agencies and the like. And it would make Tor faster for those in the southern hemisphere, Africa, and the Asia-pacific. But I don't know how much hope there is for this - I've tried to find pricing in Australia, and the figures I've found are: $8000 per month for 100Mbps.[2] $1500 per month for 25Mbps.[3] $800 per month for 10Mbps.[4] That seems ridiculously pricey… I'd rather wait for the National Broadband Network and run one on 100Mbps fibre at 1% of the price.[5] (Except bandwidth would not be guaranteed on a "home"-style plan.) Time to find a sympathetic university? Tim [1]: https://compass.torproject.org/?family=&ases=&exits=all_relays&by_country=T… [2]: http://www.intervolve.com.au/datacentre/ [3]: http://www.exetel.com.au/corporate/ip-transit-colocation [4]: https://www.xhostsolutions.com.au/services/dedicated-server-unmetered.cfm [5]: http://delimiter.com.au/2014/04/03/unlimited-100mbps-89-99-tpg-equals-top-n…

2 1

Good/Bad ISPs
by obx 23 Sep '14

23 Sep '14

I've updated the list of good/bad ISPs. It shows relay [ ] exit [ ] in front of every good ISP. Please verify that information is accurate. Special information, like anonymous hosting, would be appreciated. Thanks

1 0

printfection - tor shop
by Sebastian Urbach 23 Sep '14

23 Sep '14

Hi, Is it just temporary or is the tor-shop at printfection permanently deactivated ? -- 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

Correctly setting up arm
by Chris Whittleston 23 Sep '14

23 Sep '14

Dear all, Previously, I've run arm using 'sudo -u debian-tor arm'. As was mentioned here previously, this is not how you should run it - in fact there is a bit of documentation to suggest how it should be done. Unfortunately I'm having some issues getting arm working correctly as described here in step 14: https://www.torproject.org/docs/tor-relay-debian.html.en#after Having added my user (pi) to the debian-tor group, I try to run 'arm' and get the following: Failed to read authentication cookie (permission denied): /var/run/tor/control.authcookie I've tried reinstalling arm, relogged and checked that I'm in the right group still using 'groups' (which I am) - no joy. I've checked my torrc and found the following lines: ## If you enable the controlport, be sure to enable one of these ## authentication methods, to prevent attackers from accessing it. #HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C #CookieAuthentication 1 CookieAuthentication wasn't initially enabled, turning it on makes no difference, I get the same error. I am able to get it working when setting up HashedControlPassword by generating a has using tor --hash-password <password> and editing torrc accordingly. Am I missing something when it comes to setting up CookieAuthentication? I guess I must be...although it seems strange that I was getting that error even with CookieAuthentication disabled. Any insight appreciated :) Chris -- *Dr Chris Whittleston 栗主* Department of Chemistry University of Cambridge Lensfield Road, Cambridge, CB2 1EW Email: csw34(a)cam.ac.uk Tel: +44 (0)1223 336423

4 5

help with getting CentOS 5
by I 23 Sep '14

23 Sep '14

Hej, Following the installation on CentOS instructions on https://www.torproject.org/docs/rpms.html.en it appears there is no package for CentOS 5 only 6 and 7. "http://deb-master.torproject.org/torproject.org/rpm/el/5/i386/repodatarepom…: [Errno 4] IOError: <urlopen error (110, '\xe8\xbf\x9e\xe6\x8e\xa5\xe8\xb6\x85\xe6\x97\xb6')> " Could someone tell me whether CentOS 6 version can be used on CentOS 5? Robert

1 0

Mac OS X configuration problem(s)
by Surf Norway 23 Sep '14

23 Sep '14

I've installed the tor package via homebrew, and cofigured /usr/local/etc/tor/torrc according to the documentation. My problem is that every time I try to use launchctl I get an error, both as an admin user and via sudo. As an admin user: Could not open job overrides database at: /private/var/db/launchd.db/com.apple.launchd.peruser.502/overrides.plist: 13: Permission denied launch_msg(): Socket is not connected When run via sudo it complains about "dubious owbership on file" and says "nothing found to load". I followed whatever documentation I could find. The torrc config is on torproject.org under "configuring a relay graphically" (I know this isn't graphically), the homebrew info is linked to in the same article and looks to be from a mailing list discussion. I wanted to set up a simple relay to run automatically when the (OS X) machine boots. It's a home server on a 30MB/sec symmetrical fiber line. Since I run the machine as a file server anyway, I figured I could allocate some bandwidth and help support the community. Thanks, Surf Norway

3 2

Multithreading progress
by Sebastian Urbach 22 Sep '14

22 Sep '14

Dear list members, I asked Mikhail Belous for a quick status update regarding the multithread feature for the tor-daemon. Here's what he said: Good news: My version of multi-thread tor passes the test and doesn't shows mem racing problems. Bad news: 1)Processing channel is only big enough operation to be paralysed. Tor daemon uses a lot of global variables that should be locked. I have already done this for some resources. 2) Multithread branch is behind master for over 1000 commits. What should be done before release: 1) Merge master in better_workqueue branch. 2) Find all global resources, that are available from command_proccess_cells. I already sent you a list, but it should be checked. 3) Lock all global resources. 4) Code review 5) Compare performance of one thread and multi-thread daemons. -- 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

exit relay not receiving flag
by jason＠icetor.is 22 Sep '14

22 Sep '14

Hey All, I'm a bit embarassed here but I don't see what I'm doing wrong. I've recently inherited a VPS donation from an anonymous donor. I've configured it up like the rest of Icetor's exit relays but it never receives the exit flag. The exit in question is loki4: https://atlas.torproject.org/#details/44DB05F3AEDA5DA34BC713201DD0394418C7D… An external Nmap scan of the IP shows the DirPort and ORPort open and accessible, so what gives? -Jason

3 3

Re: [tor-relays] Mac OS X configuration problem(s)
by Tim 21 Sep '14

21 Sep '14

On 21 Sep 2014, at 22:00 , Surf Norway <surfnorway(a)gmail.com> wrote: > > I've installed the tor package via homebrew, and cofigured > /usr/local/etc/tor/torrc according to the documentation. > > My problem is that every time I try to use launchctl I get an error, > both as an admin user and via sudo. > > As an admin user: > > Could not open job overrides database at: > /private/var/db/launchd.db/com.apple.launchd.peruser.502/overrides.plist: > 13: Permission denied > launch_msg(): Socket is not connected > > When run via sudo it complains about "dubious owbership on file" and > says "nothing found to load". > > I followed whatever documentation I could find. The torrc config is on > torproject.org under "configuring a relay graphically" (I know this > isn't graphically), the homebrew info is linked to in the same article > and looks to be from a mailing list discussion. > > I wanted to set up a simple relay to run automatically when the (OS X) > machine boots. It's a home server on a 30MB/sec symmetrical fiber > line. Since I run the machine as a file server anyway, I figured I > could allocate some bandwidth and help support the community. > > Thanks, > Surf Norway Hi Surf, A few pointers: 1. On OS X, launchctl has to be run as root/superuser in order to start system-wide services. You can do this using sudo. 2. launchd plist files can't be writable by anyone other than the superuser. If you've installed the tor launchd plist file as your admin user, it will have permissions based on your user, not root. You have a few options here: A. Disk Utility's "Fix Permissions" might automatically fix ownership for you, but it might also leave the file alone because it wasn't installed by the OS X Installer. B. You could try (re-)installing the launchd plist file as root using "sudo". This will make sure the owner is "root". C. Or you could use the "ls -l", "chown" and/or "chmod" commands in the Terminal to investigate and fix the ownership and permissions yourself. 3. It's hard to tell what torrc instructions you're following, but instructions for other platforms will require modifications. OS X launchd works differently to both Linux/BSD and Windows services. For example, you can't use "RunAsDaemon 1" on OS X, or launchd will think tor has crashed. A. You might want to try the OS X-specific instructions at: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot By the way, if this is your first tor relay, and since it's at home, you probably want to run a relay with no exit ports open. And if you have multiple IPs, on its own IP. This is a much safer option than running an exit on a shared IP. If you're still having problems, can you please include URL(s) of the instructions you're following, copies of your torrc and launchd plist files, and the exact output from the launchctl and tor programs? This really helps us help you, because then we can see exactly what you're seeing. A final question: can you manually launch tor without using launchd? It sounds like you're not even getting to the point where launchd tries to run tor. But it can be helpful to make sure that tor will run without the added intermediary of launchd. T

1 0

obfs3 not recognised by tor 0.2.5.7-rc ?
by Nick Sheppard 20 Sep '14

20 Sep '14

I'm running tor 0.2.5.7-rc and obfsproxy 0.2.6, and everything seems to work perfectly with these PT lines in torrc: ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy managed ExtORPort auto However, if I try to use obfs3 as well: ServerTransportPlugin obfs2, obfs3 exec /usr/bin/obfsproxy managed then on tor start I get: [warn] Strange ServerTransportPlugin type 'obfs3' [warn] Failed to parse/validate config: Invalid server transport line. I thought my versions would be recent enough to handle obfs3? Is this a bug, or am I missing something obvious? Nick Sheppard

2 3

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

20 Sep '14

[Edit: Convert to end-posting & fix quote levels] On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Wednesday 17 Sep 2014 22:40:36 Tim wrote: > >> 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 > > > Hi Tim -- > > Very good points, and yes most likely the mail protocols would be candidates for "slow", high > latency circuits. > > However, there may be another class of relays that's overlooked - many VPS providers sell VPSes > with low data caps, even on fast connections (100Mbit/s). There are two ways to address this: > > a) traffic accounting: the relay hibernates until the next reset > b) throttling so that the data cap for the month isn't prematurely reached. > > I'd imagine that most relay operators with such VPS packages will choose to throttle and keep the > relay up and running continuously rather than having it hibernate (I know I've had to do this in the past). > The actual connection is fast enough to not suffer real latency issues, it's just the relay doing the throttling > - do you think throttling to 0.5Mbit/s or 1Mbit/s will create issues of high latency? > > I'm about to go and read the Conflux paper: > > "In this paper, we present Conflux, a dynamic traffic-splitting approach that assigns traffic to an overlay path > based on its measured latency. Because it enhances the load-balancing properties of the network, Conflux > considerably increases performance for clients using low-bandwidth bridges." > > This would obviously create better utilisation of circuits as a whole, so it may well make my idea totally redundant. :) > > Cheers, > > -- > Paritesh Boyeyoko Paritesh, For fast Tor relays with low data caps, the general advice is I've heard is two-fold: * enable AccountingMax, which will hibernate the router when the bandwidth is used up, and * disable directory caching to save (upload) bandwidth (AccountingMax does this automatically when it's configured) This means that the network has many fast routers each covering some of the day/week/month, rather than many slow routers for the entire month. (It also uses the entire bandwidth quota more efficiently - what if the calculated bandwidth limit is too low?) Tor seems to need more fast routers to reduce latency, because there is a long tail of slower routers which can provide significant capacity when needed. T

3 2

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

RELAY_EARLY tor network update status (CVE-2014-5117)
by Nusenu 18 Sep '14

18 Sep '14

(if you are on the CC list of this email you are probably one of the tor relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] relays on the tor network. Please upgrade your tor relay) > The tor network is currently at 64% of the bandwidth being served by > relays running a recommended version according to torstatus.blutmagie.de. > I updated a previous metrics feature request so we might see nice > graphs about patching progress in the future [2]. Since we are seeing active RELAY_EARLY attacks again (or new buggy tor implemantations) I was wondering what the current update stats look like. ~85%* of the tor network's bandwidth is provided by patched relays. (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) *) according to data from torstatus.blutmagie.de 10 fastest relays still running a vulnerable version: https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE…

3 2

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running relay
by Dan Hanley 18 Sep '14

18 Sep '14

> > > I have just received a slightly more positive reply: "At present, our GeoIP data provider classes Tor nodes as proxies, regardless of whether or not they're an exit node. We understand that there is room for improvement in this model, since non-exit relays do not present traffic on behalf of other users. We have asked our provider to give us a way of differentiating Tor exit nodes from non-exit relays, to allow us to block exit nodes only." So perhaps they will make a change... certainly reporting the issue seems to raise its importance :-) atb Dan > 5. Re: BBC and UK Lottery blocking ip addresses running relay > nodes (Chris Whittleston) > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 01:40:31 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay nodes > Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt > though, it seems like they still don't get the difference between using Tor > as a client and running a relay, so this isn't the end of the road there. > You are going to have to rely on them wanting to actually think about it > though. > > If all else fails, you could always try to simply report the issue again > using the form I linked before, but this time just don't mention Tor at all > and see if you get a different customer service person... > > http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 > > I suspect you'll end up having to explain that you're running a relay in > the end anyway, but you never know. > > Chris > > On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: > >> Stephen Mollett: >> > [...] >> > "Thank you for contacting the BBC iPlayer support team. >> > >> > "I understand you’re experiencing problems accessing BBC iPlayer as >> > you’re told that you are outside of the UK. >> > >> > "Please note that if you run TOR, then I’m afraid as per our development >> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >> > continue to use TOR then your IP address may be blacklisted against UK >> > only services across bbc.co.uk." >> > >> > I made a point of stating explicitly in my original case filing that I >> > run a middle relay and that no traffic exits from my node to the BBC's >> > website or to anywhere else, along with a link to my node's stats on >> > blutmagie confirming the (non-)exit policy. >> > [...] >> >> Hi Stephen, >> >> I'm not sure whether I'm surprised at the BBC or not! >> >> It is a shame if they seem to be doing blanket blocking of Tor relay IP >> addresses. I suppose this >> ( >> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >> ) >> has /some/ relevance. >> >> The problem is obviously convincing a organisation like the BBC to treat >> individual IP addresses different from other Tor relay IP addresses (and >> whether they should be doing that at all). Although it seems Chris >> Whittleston obviously managed it! Maybe you simply got 'the wrong person >> at the other end'. Personally, I would continue to pursue this with them! >> >> --Matt >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > *Dr Chris Whittleston 栗主* > Department of Chemistry > University of Cambridge > Lensfield Road, Cambridge, CB2 1EW > Email: csw34(a)cam.ac.uk > Tel: +44 (0)1223 336423 > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

3 2

Where to report relay warnings
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, I also found a lot of the mentioned log entries. The comment from Arma within the ticket is just right "Bonus points for using the name in the NSA document" Rofl :-) -- 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

Where to report relay warnings
by Jens Müller 18 Sep '14

18 Sep '14

Hi there My relay logged the following warning this morning: Sep 18 04:52:58.387 [Warning] Received an inbound RELAY_EARLY cell on circuit 2147511747. Closing circuit. Please report this event, along with the following message. Sep 18 04:52:58.388 [Warning] upstream=85.159.214.57:9003 Now, I have checked the FAQs but didn't found any information where to report this, so I hope you can help me out. Thank you already and kind regards Jens

2 1

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 17 Sep '14

17 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