- tor-relays - lists.torproject.org

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

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

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

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

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

19 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