- tor-relays - lists.torproject.org

significance of different bandwidth values
by starlight＠binnacle.cx 15 Oct '13

15 Oct '13

Question: What the difference between the bandwidth value given by getinfo ns/name/xxxxx >>> w Bandwidth=297 and getinfo dir/server/authority >>> bandwidth 300000 375000 335872 Here they are close, but sometimes they are far apart. The first above is what shows up in the Vidalia Network Map and the latter is less visible, but shows up in various web tools for monitoring the Tor Network. In particular, how are these values used in choosing route paths? Thanks

1 0

dynamically adjusting bandwidth
by starlight＠binnacle.cx 15 Oct '13

15 Oct '13

Hello, I've recently established a full-time relay running on a fast Linux router. Working nice with version 0.2.4.17-rc. Have a daily offsite backup that was butting heads with TOR traffic, so I wrote a 'tor_bwreduce' and 'tor_bwrestore' script like these: nc 10.92.88.1 9151 <<EOF AUTHENTICATE "xxx" SETCONF RelayBandwidthRate=60000 SETCONF RelayBandwidthBurst=60000 QUIT EOF : nc 10.92.88.1 9151 <<EOF AUTHENTICATE "xxx" SETCONF RelayBandwidthBurst=375000 SETCONF RelayBandwidthRate=250000 QUIT EOF : and run them at the appropriate points in the offsite backup script. The backup is rate-limited as well so the link now avoids going into significant oversubscription or contention. This works much better than I expected. The Tor network consensus bandwidth for the node was taking a bad hit due to congestion delays when the backup ran. Now it seems unaffected and the consensus for my node has shot up above the 'RelayBandwidthRate' value. So that's all super. The question is, should I put in an adjustment for 'MaxAdvertisedBandwidth' during the backup window or make any other change to advise remote relays to de-prioritize the node for the duration? Ideally I'd like to put the node into temporary hibernation, but it seems the only way to do that is indirectly by fiddling with several Accounting* parameters. Thanks! P.S. BTW Vidalia could use some improvement in the area of dealing with a Tor relay living on a different box in the same network. Nothing major, but it should 1) not override the config and/or warn first 2) import the config when a virgin TBB install connects to a non-local address 3) not shut down the relay casually without an "are you sure?" pop-up

1 0

Re: [tor-relays] NSA's "Tor Stinks"
by Eugen Leitl 14 Oct '13

14 Oct '13

----- Forwarded message from Adam Back <adam(a)cypherspace.org> ----- Date: Mon, 14 Oct 2013 12:02:04 +0200 From: Adam Back <adam(a)cypherspace.org> To: Eugen Leitl <eugen(a)leitl.org> Cc: Cpunks List <cypherpunks(a)cpunks.org>, info(a)postbiota.org, zs-p2p(a)zerostate.is Subject: Re: [tor-relays] NSA's "Tor Stinks" Message-ID: <20131014100204.GA28712(a)netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) Btw speaking of GCHQ or NSA operating Tor nodes, of course that is inevitable; and to the extent that they are not perfectly policy aligned a good thing, and they'll try to do a professional job of securing their own tor nodes :) eg if you are a chinese dissident maybe you want to use them as one hop. You just dont want them controlling to many nodes. And probably the Russians, French, Israelis, Chinese etc are all running Tor nodes and even less mutually cooperative. What we could really do with is North Korea, and Iran intelligence services running some also. I suspect to the extent that they are experiencing limited success you could imagine its because not ony are some nodes controlled by users, but more that some are operated by mutually distrustful competing intelligence agencies. The intelligence agency nodes are probably better secured than user nodes, though some user nodes maybe run by security capable and conscious users. The intelligence agencies however have a budget for and hoard of unpublished 0-days on PC & router operating systems so they have a slight edge. Also the intelligence agency is not going to cave under legal pressure when someone from law enforcement comes with threats and demands relating to exit traffic so they have that advantage too. It would be better to my mind if they just came out and said yes this is our node and ran it from their own domain tor.gchq.gov.uk or tor.nsa.gov; then users could opt to use it. However I suspect they think no one would use it, or the people they actively want to use it (who they are trying to trace) would avoid it. Could be useful if they used an identified one and a plausibly hidden one. Speaking of plausibly hidden I notice there is mention of code word 'NEWTONS CRADLE' in one of the docs for a GCHQ tor node operation, speculating could that be some MoD funded student at cambridge in their dorm? (Quite commnon in the UK for students to be sponsored by a company they will work for afterwards or a government career they took a break from. A couple of my classmates at BSc, University of Exeter (UK) comp sci BSc were openly MoD sponsored.) No matter, its trivial for establishment to provide perfect cover for node operation, just run from home address, or persuade ISP/telco to route traffic via DSL lines identifying IP address range as a IP forwarding proxy. They can do whatever they want, you'd think that more likely, however a university dorm IP address range would look nice and plausible/credible also, maybe more so than a DSL address. Probably a university upstream or the university IT itself (universities often take defense contracts) could fake it or operate it under contract with intelligence cleared dual-hat admin if they cared enough. I do think it would be very useful if the intelligence agencies running tor nodes also ran one on their own domain. Then you could route via one who's government is overtly supportive of your political cause. (Doesnt protect you from backroom information exchange deals and horse trading, which I'm sure happens even with sworn enemies, but its a start if you are unintersting enough!) However I expect another reason they dont want to do that is they dont want to enable people to get stronger privacy period. They have a dual hat, they want internet privacy for their own open source research, but they selfishly dont want other users to have privacy or gain any privacy as a side-effect from their own. Adam On Mon, Oct 14, 2013 at 11:18:33AM +0200, Eugen Leitl wrote: > ----- Forwarded message from Jesse Victors <jvictors(a)jessevictors.com> ----- > > Date: Tue, 08 Oct 2013 13:23:48 -0600 > From: Jesse Victors <jvictors(a)jessevictors.com> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] NSA's "Tor Stinks" > Message-ID: <52545BC4.3020106(a)jessevictors.com> > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 > Reply-To: tor-relays(a)lists.torproject.org > > > I recently ran across several articles related to the NSA's attempts at > cracking Tor and de-anonymizing its users. They are after terrorists and > other individuals who seek to do harm of course, but their work > obviously has implications into other Tor users, the vast majority of > whom use Tor for legal and proper activities. So far, it appears that > the cryptographic standards and protocols implemented by the Tor devs > appear to be holding, which I find interesting. The NSA has been trying > other methods to figure out Tor, including identifying and then > infecting user machines, trying to control/hijack the Tor network, or by > influencing the network as a whole, and they've had a very small amount > of success, but not much. One thing that was especially interesting to > me (and I expect to everyone on this mailing list) is that they are > trying to control more relays via cooperation or direct access, which > can then be used for timing attacks or disruptions to the users. They > are also trying to shape traffic to friendly exits. For anyone > interested, I would highly recommend these links: > http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-pre… > http://www.bbc.co.uk/news/technology-24429332 > http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… > > Also, from > http://www.theguardian.com/world/interactive/2013/oct/04/tor-high-secure-in… > it appears that their opinion of Tails is that it "adds severe CNE > misery to [the] equation". These are all highly informative articles, > and it appears that Tor is remaining resilient to their efforts, as long > as people (including relay/exit operators) use the latest software, > remain aware that Tor doesn't protect them in all aspects, and as long > as there are enough non-NSA relays and exits (we need more!) such that > everything they see still remains encrypted and anonymous. Interesting I > say. > > Jesse V. > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ----- End forwarded message ----- > -- > Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org > ______________________________________________________________ > ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org > AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

iptables changes required to advertise on 80 and 443 and bind to different ports.
by Tor Operator 13 Oct '13

13 Oct '13

I’m running a Tor exit relay on ports 9030 for advertising directory connections and 9001 for advertising incoming Tor connections. In the spirit of proxy-proofing my relay, I’d like to expose the directory and Tor connections on 80 and 443. I’ve spent hours trying to get my iptables config correct, but never successfully. I’m running CentOS 6 with SELinux enabled. Swap and /tmp are encrypted. SSH is set to public key auth only and limited to a single user. Root login is disabled, as is X11 forwarding. No other services are active and log retainment is set to a short interval. It’s a dedicated box in data center with a 100Mbit, unmetered networking connection. The box’s sole purpose in life is to be an exit node. My current iptables looks like this: # Generated by iptables-save v1.4.7 on Sat Oct 12 13:52:47 2013 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 9001 -j ACCEPT -A INPUT -p tcp -m tcp --dport 9030 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited -A OUTPUT -j ACCEPT COMMIT I tried adding the following rules without success: iptables -t nat -A PREROUTING -p tcp -i eth0 —dport 80 -j REDIRECT —to-ports 10091 iptables -t nat -A PREROUTING -p tcp -i eth0 —dport 443 -j REDIRECT —to-ports 10090 There was also a binding issue due to Tor being blocked from binding to 10091 and 10090, which I fixed with semanage port. But the logs still indicated that the ORPort and DirPort were not reachable from the outside. I think I’m missing some other key iptable routing directives, but I can’t figure them out. I want 80 and 443 publicly exposed, but 10091 and 10090 to not be accessible from the internet. I’ve read countless FAQs, how-tos, message board posts, Linux books, the Tor mailing lists, and the answer still eludes me. It’s maddening. If anyone can provide any assistance, I’d be greatly appreciative. If I’m running the directory connections on port 80, should I still setup a vhost on the relay with the exit notice or can I just point to it in the torrc file? .cpj

3 2

NSA's "Tor Stinks"
by Jesse Victors 10 Oct '13

10 Oct '13

I recently ran across several articles related to the NSA's attempts at cracking Tor and de-anonymizing its users. They are after terrorists and other individuals who seek to do harm of course, but their work obviously has implications into other Tor users, the vast majority of whom use Tor for legal and proper activities. So far, it appears that the cryptographic standards and protocols implemented by the Tor devs appear to be holding, which I find interesting. The NSA has been trying other methods to figure out Tor, including identifying and then infecting user machines, trying to control/hijack the Tor network, or by influencing the network as a whole, and they've had a very small amount of success, but not much. One thing that was especially interesting to me (and I expect to everyone on this mailing list) is that they are trying to control more relays via cooperation or direct access, which can then be used for timing attacks or disruptions to the users. They are also trying to shape traffic to friendly exits. For anyone interested, I would highly recommend these links: http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-pre… http://www.bbc.co.uk/news/technology-24429332 http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… Also, from http://www.theguardian.com/world/interactive/2013/oct/04/tor-high-secure-in… it appears that their opinion of Tails is that it "adds severe CNE misery to [the] equation". These are all highly informative articles, and it appears that Tor is remaining resilient to their efforts, as long as people (including relay/exit operators) use the latest software, remain aware that Tor doesn't protect them in all aspects, and as long as there are enough non-NSA relays and exits (we need more!) such that everything they see still remains encrypted and anonymous. Interesting I say. Jesse V.

11 14

Re: [tor-relays] NSA's "Tor Stinks"
by Jesse Victors 09 Oct '13

09 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Message: 1 > Date: Wed, 09 Oct 2013 11:48:01 +0200 > From: Konrad Neitzel <konrad(a)neitzel.de> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] NSA's "Tor Stinks" > Message-ID: <1381312081.3204.32.camel(a)opensusevm1.site> > Content-Type: text/plain; charset="utf-8" > > On Tue, 2013-10-08 at 23:40 -0400, krishna e bera wrote: >> On 13-10-08 03:23 PM, Jesse Victors wrote: >>> ... >>> obviously has implications into other Tor users, the vast majority of >>> whom use Tor for legal and proper activities. >> Could you give some evidence for what "vast majority" means in terms of >> percentages? How are you getting such data? > I think that we first need a clear definition what "legal" means or what > "proper activities" are. The core problem is, that the definition of > these terms can differ a lot (e.g. from country to country but even from > person to person inside a country. At least the interior minister of > germany seems to have some strange ideas :) ). > > And I just read a news article of a german publisher (Heise) about NSA > and what they do and I understood it that NSA is claiming to just check > on non US citizens or illegal things. The "owner" of the data that is > sent between 2 tor nodes cannot be identified so when the NSA attacks > any tor traffic there must be some kind of understanding, that using the > tor network already is something illegal in the minds of these people. > > At least that was, what I understood when I was reading this article. > > With kind regards, > > Konrad Ok, I did not expect that this was going to be a talking point or be otherwise confusing. No I don't have any hard numbers, nor do I run an exit that I can test using tcpdump. But the Torproject repeatedly says that Tor is often used for good, or simply to just hide one's Internet activities for those who feel that they have a right to be hidden even if they have nothing to hide. I have friends who do their browsing over Tor, and there's nothing at all controversial about what they are up to as far as I'm aware. I understand what you're saying: I agree that simply going to Google may be illegal in some countries. I believe that a few bad apples put Tor in the news, make things hard for the exit operators, and spoil things for the rest of us. My point was that the NSA is doing penetration testing on the Tor network and doing what they can to figure it out. No matter what kind of traffic goes through Tor, the fact remains is that they are doing that, and we need to be aware of their efforts, the progress they've made, and what they are planning. That was my main topic that I was introducing to the group. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSVWhVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAnvcIALGb0/r7GNfxozWW27uc/dIN 5asIgWpUCFIm9Rw4pl8EfDeQ7r0ktauM8/MsRrOaIxMiyoj8u1n07HS7bmf6UKyg dLZTIJeyxnjewEw1fSAHAw6e3dxXVQxyNz0eF6EqIJureRXqfzvEa+9oFNBOBxgk qsCDNn38xwnhumOMESmiGzaUO7eEvTNAnwCZTKtrlYwSUf7G8zWjHafJbe68kcGE j5bxa8+sjB6OwdvCnCXEOe+L65L+N0RCPIEL+NWBqn+ff5dwQY5GYPNhszil4qLr RlFgpOwvbwmA5hRAHBKpVLubrPDx9ocLaNBwcWwlP/ccgFfwqYJrOInTueKSs9k= =SOt/ -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Admin panel compromised
by Yoriz 06 Oct '13

06 Oct '13

All, I have successfully reinstalled the 'privshield' exit: https://atlas.torproject.org/#details/BA2D32ECE096FC423D6DC1975021A01D96C01… Unfortunately, as fresh server keys have been generated, the node will keep its "unnamed" flag for another 6 months (why?!), and consensus weight started at the bottom again so I am not seeing a lot of traffic yet. And most importantly: I have to start all over again to try to earn my Tor T-Shirt! ;-) @Lunar and @Jon: thank you for your kind words. // Yoriz

1 0

Anyone using obfsproxy on Ubuntu Lucid?
by Lunar 05 Oct '13

05 Oct '13

Hi! Ubuntu Lucid is getting old. Building an obfsproxy package for Lucid now requires some extra work. weasel stopped building tor master branch for Lucid already. Is there anyone providing obfsproxy bridges using Ubuntu Lucid? -- Lunar <lunar(a)torproject.org>

2 1

Re: [tor-relays] NSA v TOR Guardian article
by tor＠t-3.net 05 Oct '13

05 Oct '13

The tech articles had fascinating info which I know the Tor devs will be eating right up like a cupcake :) Does anyone have any insights into the articles which would be specific to tor relay operators, and would allow us to be better node hosts? Didn't like that the NSA has in essence verified that they run some nodes. Could have guessed it was the case, but still. Would love to know which nodes belong to them. They would have a big budget for donated bandwidth if they so chose, since they get to dip the soup ladle deep into the US/UK taxpayer cauldron. On Saturday 05/10/2013 at 1:26 am, Roger Dingledine wrote: > On Fri, Oct 04, 2013 at 09:12:07PM -0800, I wrote: >> >> http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… > > Hi! > > This is best discussed on the big thread on tor-talk. > > But see also > https://blog.torproject.org/blog/yes-we-know-about-guardian-article > > Thanks, > --Roger > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

NSA v TOR Guardian article
by I 05 Oct '13

05 Oct '13

2 2

Running more nets than Tor?
by grarpamp 05 Oct '13

05 Oct '13

Anyone also offering up vpngate, i2p, mail mixes, other p2p/networks, etc to the public on their relay platform?

5 5

BBG and Tor funding
by mick 05 Oct '13

05 Oct '13

See http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… Note the new addition at the end of this article, presumably added at the request of BBG "• This article was amended on 4 October after the Broadcasting Board of Governors pointed out that its support of Tor ended in October 2012." So. How does this square with BBG's alleged support for financing new fast exit relays? https://lists.torproject.org/pipermail/tor-relays/2013-September/002824.html Best Mick --------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net ---------------------------------------------------------------------

1 0

Admin panel compromised
by Yoriz 04 Oct '13

04 Oct '13

For your info: I am the operator of the "privshield" exit. I just got notice from my hoster (5gbps.com) that their backoffice admin panel was compromised. Indeed my firstname and password to the admin panel have been changed. Fortunately, I have SSH on my VPS configured to only accept public key-based logins, and see no signs of entry of the VPS. As the backoffice panel provides direct console access, there is a slight chance they logged in directly by a safe-mode boot, but my uptime is a month, and I see no dip in the tor bandwidth: https://atlas.torproject.org/#details/DA3F7BD5428F88C79C9C7006B791982DA0115… However, as a precaution I have shut down my tor exit. I will request a clean Ubuntu image and reinstall my tor exit this weekend. I will generate new server keys just to be sure. My mail is hosted on the same system, I won't have access to this email address for a few days. // Yoriz

3 2

need help with running tor in combination with shorewall
by Jan Hendrik den Besten 03 Oct '13

03 Oct '13

Hi, I installed tor a few days ago. It only runs fine if I stop my shorewall firewall. I found here some online help: https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ However, the shorewall-rules example given there doesn't work. It's mentioned the example is for shorewall v2.2.3 whereas the current version is v4.5.16.1. Does anyone have a latest exmple of the /etc/shorewall/rules file? thanks, Jan Hendrik --

2 2

relays "in the cloud"
by Jonathan D. Proulx 03 Oct '13

03 Oct '13

Hi All, There must be discussion of this I'm not finding so references to that are welcomed. As I understand it there are three risk layers in each Tor node: 1) The node operator (who has r00t) 2) The data center (who has net) 3) The legal jurisdiction I've recently started running a couple of relays on public IaaS providers. To my thinking this doesn't present significant security issues beyond a hosted physical server, largely because they are not running hidden services or using Tor to anonymize their own traffic. Presumably memory inspection on the underlying hypervisor could easily reveal that. Most of what could be discovered from hypervisor monitoring seems liek it could also be discovered by traffic analysis available to any datacenter provider should they choose or be compeled to. The one novel thing this may make easier is stealing the hosts private keys, which would make traffic analysis easier (but I don't thing significantly better) and allow impersonation of the node which would not otherwise be possible (well it maybe possible to steal from memory on a running system given physical access and sufficient equipment, time and expertise but nearly impossible if not actually so). What is the consensus level of paranoia on this? Are there threats to virtualized systems I'm not considering? Thanks, -Jon

4 5

hardware accelerated crypto
by Sarah Vigote 02 Oct '13

02 Oct '13

hi, I would like to run a 100Mb/s tor exit node, but I have issues wrt power consumption. reading http://ortizaudio.blogspot.fr/2011/10/using-dreamplugs-crypto-chip.html it seems dreamplugs has *fast* aes-128-ecb. Does anyone have any experience running a node based on cheap crypto chip (dreamplug, marvell 88F6282, sheeva-core, padlock, ...) ? What performance can I expect out of these ? regards, sv

9 12

Warnings in log
by Konrad Neitzel 02 Oct '13

02 Oct '13

Hi all, I am running a tor node (idkneitzel) on a linux server (using opensuse 12.3). Today I saw: Oct 01 14:20:34.000 [warn] Failing because we have 8163 connections already. Please raise your ulimit -n. So I modified the /etc/security/limits.conf and added: * soft nofile 65000 * soft nofile 65535 and rebooted the system but now I got that warning again. Did I missunderstood the warning and should I add other entries, too? And now I also got the following warning: Oct 01 18:25:19.000 [warn] Cannot get strong entropy: no entropy source found. Now I am unsure, what I should do regarding this point. (After a restart, this message seems to no longer occur but I am still curious what is going on here). Thank you in advance for your help. With kind regards, Konrad

4 5

Directory traffic
by Jobiwan Kenobi 01 Oct '13

01 Oct '13

As of between 18:00 and 19:00 yesterday (9/30/13) directory traffic on my relay has gone up dramatically, from mere background noise to more than half my advertised bandwidth, and hasn't really come down since. I pasted the numbers from /opt/var/lib/tor/state into a spreadsheet and made a graph. The green line is the interesting one. I don't know whether I can send attachments to the list, so I put it here: http://jb4m.homeip.net/T/graph1-dirw.png Right now, I advertise 1 Mbit but don't actually limit bandwidth, and I was quite happy with the profile until this started. If it keeps doing this, I may have to put a cap on again. I'm a non-exit, non-guard. Is this normal? Is there anything I should look into? Thanks, -Job

1 0

Re: [tor-relays] Reimbursement of Exit Operators
by tor＠t-3.net 01 Oct '13

01 Oct '13

I wonder if I am the only one who finds this creepy, in light of all of the news that has come out lately about the banking systems having been hacked, etc. This kind of thing would draw a direct line of sorts to the bank account of the person/company involved with the exit node. This information could be used later by someone who doesn't have the person's best interest in mind. Tor is to some degree tolerated right now by certain authorities but what happens if that suddenly changes? On Tuesday 17/09/2013 at 2:38 pm, Moritz Bartl wrote: > Hi, > > tl;dr: We want to start reimbursing exit operators end of this month. > Partner orgs, please sign the contract! Everyone else, consider > becoming > a partner. > --- > > In July last year, Roger announced that BBG was interested in funding > fast exits. [1] The initial discussion on the mailing list continued > into August. If you're interested, you should consult the archive for > the various points raised. Since then, we've been discussing that > topic > on and off. It matched with my plans to turn torservers.net into a > platform for many organizations, instead of just one single entity > that > runs too many exit relays, so I agreed to take the lead. I posted a > status report of some sort on this list in April this year. [2] > > The Wau Holland Foundation agreed to be one of the organizations > willing > to handle the money and pass it on to other entities, be it single > operators or organizations. Both Torproject and Wau Holland Foundation > checked with their lawyers to see if this turns into a problem about > liability, and it looks like it does not. We're open for more > organizations to join in to manage the reimbursement process, but this > is what we've got for now. > > In parallel, we've seen a growing number of organizations that were > created to turn donations into exit bandwidth. [3] > > Two issues with reimbursements, that were also mentioned in Roger's > initial posting, are that (1) you don't want to drive away all the > volunteers, and (2) you don't want to become dependent on (a single or > a > handful of) sponsors. These are difficult issues, and I want to > strongly > encourage everyone to keep contributing to the network. We really need > you, and we need more of you! > > The second issue, dependence on funders, is on the one hand a harder > one, but on the other hand (in my opinion) a less relevant one. If > structures die and nodes have to be shut down because a funder backs > off, so be it. We hopefully don't change the picture too much in > comparison to the "unfunded times of today". The reimbursement process > does not guarantee a money stream, and the amounts are set on a > month-to-month basis, to encourage recipients to plan only short-term, > and only make contracts based on the money they have, disregarding > what > they may or may not receive in the future. The current "bucket" is the > one-time BBG money, and it currently does not look like they will > restock it. > > It might sound scary, but to satisfy the tax authorities (and to show > that it is a [hopefully] fair and transparent process), the Wau > Holland > Foundation needs to have partners sign a contract. The contract does > not > limit the partners abilities or restrict what they do, it only defines > the reimbursement process. > > The way we want to start doing it now is not set in stone, and > hopefully > now that we finally start handing out money it will encourage further > discussion around it. We want to refine the process over time, but it > looks like we just have to try with what we have now and learn from > our > mistakes. Please don't be too hard with your criticism or you will > emotionally hurt me. I'm all ears. :-) > > We want to reimburse based on the throughput per exit relay and > organization. To strengthen network diversity, we came up with the > plan > to also factor in the location of the relays. There is a maximum > amount > any entity can receive so we hopefully don't grow big monsters. > > The contract [4] specifies that there is a monthly amount, currently > set > to $3500, split amongst all recipients (whom I started calling > "torservers partners"). The recipient share is calculated from the > throughput per relay * country factor, and the maximum amount per > month > per partner is 500 Euro. The Wau Holland Foundation can currently only > reimburse via wire transfer. > > The country factors can change over time, and are currently derived > from > the total exit probability of that country. We can and should refine > this. Changes of these factors do not require new contracts. > > Note that since the total amount of $3500 will be handed out every > month, as long as we have less than 6 entities signing the contract, > each entity will receive their maximum share of 500 Euro. I don't > really > like the idea of a fixed monthly total handed out like that, but > that's > what the lawyers and tax authorities signed off for Wau Holland > Foundation. It seems to be costly to re-evaluate such contracts, so > this > is what we will stick to for now via WHF. > > Technically, the monthly shares and the country factors are calculated > using a tool written by Lunar^^ (big thanks!). [5] You can find an > example report at [6] (not the correct numbers, but you'll get the > idea). This monthly report will be sent to all partners, and once they > signed the contract they will simply get their monthly share. > > As stated at the top, we want to start reimbursing this month. Please > let me know if you have any questions. We have a mailing list that is > public and read-only where we send important announcements, and > require > every participant to be on and actually read. We have another mailing > list that is also read-only for the public, but people of the > participating organizations can post and discuss everything around > Torservers.net and reimbursements. [7] > > The process to become a "partner" for now requires that I "know you". > So, if you're interested in becoming a partner, start social > interaction > with me. I see that as a bad bottleneck, and I hope we can somehow get > rid of it in the future. I generally prefer "organizations" over > single > persons, because (1) in most countries it seems to be really > inexpensive > and easy to set up organizations and (2) the process of setting up > such > entities includes that you gather enough people around you, so chances > are you will continue even if one of you drops out. > > If you want to discuss, I prefer the tor-relays mailing list and our > IRC > channel, #torservers on irc.oftc.net. I also explicitly want to invite > every partner to join that channel. > > --Moritz > > [1] > https://lists.torproject.org/pipermail/tor-relays/2012-July/001433.html > [2] > https://lists.torproject.org/pipermail/tor-relays/2013-April/001996.html > [3] http://www.torservers.net/partners.html > [4] [fill out + send back via pgp-encrypted and signed mail to me] > plain: https://www.torservers.net/misc/2013-07-19_TorExit_en.txt > fancy: https://www.torservers.net/misc/2013-07-19_TorExit_en.ott > german: https://www.torservers.net/misc/2013-07-19_TorExit_de.ott > [5] git clone https://people.torproject.org/~lunar/exit-funding.git > [6] https://www.torservers.net/misc/reimburse-output-2013-07.txt (set > encoding to Unicode) > [7] > https://lists.torproject.org/pipermail/tor-relays/2013-May/002138.html > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

6 5

MaxOnionQueueDelay
by nsane 01 Oct '13

01 Oct '13

Hello, there is a Tor setting "MaxOnionQueueDelay" in torrc (see https://www.torproject.org/docs/tor-manual-dev.html.en) with a default of "1750 msec". As operator of a Tor relay 0.2.4.17-rc (on Debian) I would like to know were I can find the current processing time for onionskins to set "MaxOnionQueueDelay" different from its default value (1750) in the torrc. Where can I find the current processing time? -- http://www.fastmail.fm - Choose from over 50 domains or use your own

3 4

tor 0.2.4.x on the Raspberry Pi. How to?
by Martin Kepplinger 01 Oct '13

01 Oct '13

In order to run an obfsproxy bridge on my Pi, I need tor from git or tor's experimental repos; raspbian's packages are too old right? I got confused with recent discussions on raspberry pi here. What's the simples way to run a obfsproxy bridge on my Pi and keep it up to date as well! thanks!

3 2

New GPG key for Mike Perry
by Mike Perry 01 Oct '13

01 Oct '13

Hi everyone, I've finally made a new GPG key (after a scant 7 years!). This new key will be used to sign email from me going forward, and will be used to sign software releases until such time as I get around to creating a second set of keys on a hardware token for that purpose. While I dislike the Web of Trust for a number of reasons*, my plan is to cross-certify these two sets of new keys, and also sign both with my old key. Hence I will not immediately be issuing a revocation for my old key. The new key is attached, and is available on the keyservers (with a signature from my old key) at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x29846B3C683686CC Here's the fingerprint and current subkey information for reference: pub 8192R/29846B3C683686CC 2013-09-11 Key fingerprint = C963 C21D 6356 4E2B 10BB 335B 2984 6B3C 6836 86CC uid Mike Perry (Regular use key) <mikeperry(a)torproject.org> sub 4096R/717F1F130E3A92E4 2013-09-11 [expires: 2014-09-11] sub 4096R/A3BD8153BC40FFA0 2013-09-11 [expires: 2014-09-11] This message should also be signed by my previous key, which was used extensively to sign my email and my source code releases prior to today. * Ensuing flamewars about the Web of Trust should reply only to tor-talk. -- Mike Perry

2 1

What do bridge operators expect when providing a ContactInfo line?
by Karsten Loesing 30 Sep '13

30 Sep '13

Hi bridge operators, Nick rightly suggests moving this discussion from Trac here: What do bridge operators expect when providing a ContactInfo line? Details are on Trac, pasting below: https://trac.torproject.org/projects/tor/ticket/9854 There's an interesting question in the Tor StackExchange beta: """ I'm guessing that a bridge uploads its ContactInfo to the bridge authority, so there's a point of contact for the Tor project. Is this information available to any other parties, i.e. users requesting bridges, or people randomly connecting to IP addresses looking for Tor installations? """ In practice, users of a bridge will be able to learn the bridge's ContactInfo line, because they download the bridge's descriptor. But Tor people will have a hard time to do that, because this line is removed from bridge descriptors in the sanitizing process. One needs access to the non-sanitized descriptors, which limits the set of people to maybe five. I don't remember a single time in the past couple of years when we tried to contact bridge operators using provided contact information. This is rather unexpected for bridge operators, I'd think. I guess most bridge operators would expect their contact information to be known to Tor project people and used for debugging only. Three options: 1. We conclude we don't need the contact line for bridges, because we wouldn't contact the bridge operator anyway. Bridges should remove that line from their descriptor before uploading. 2. We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors. 3. We don't change anything, because everything's fine as it is. At least now we know this information is theoretically available to a few Tor people and definitely available to bridge users. Feel free to reply on the ticket. If you reply here (tor-relays@) and *don't* want me to paste your reply on the ticket, please mention that in your reply. Thanks! Karsten

1 0

Slow exit node over VPN
by Konstantinos Asimakis 30 Sep '13

30 Sep '13

Hello everyone. I am usually connecting to the internet through VPN (Mullvad). Would it make sense to setup an exit relay to run whenever I can? I can forward one or two ports to my machine. My IP may change often and I might have to shut down the node when I need the bandwidth for something else. Also the bandwidth won't be much. I expect 40KB/s upload on average with bursts to 70 or 80. Mullvad is obviously already receving a bazilion complaints about forum SPAM etc (thus I often find myself blocked from a few sites, having to solve captchas in many cases) so I guess they will see no diference. ----- My full signature with lots of links etc.<https://bittit.info/publicDro/signature.html>

3 5

(Re)Introduction
by Jonathan D. Proulx 29 Sep '13

29 Sep '13

Hi All, It's been quite a while since I've been active in TOR, but recent events have reminded me I should be doing more. To that end I've started running a Fast Exit again: racktor fingerprint: 8B7D6BFF6AE63BE39E438FE7A4249FEA1A340EBD This is running in the Rackspace public cloud (Chicago region) on my personal account. Next week I plan on looking into (re)starting an exit at my place of employ (will set MyFamily fo the nodes). That's mostly a practical issue of making sure I'm the one getting the complaints and not my coworkers... In the mean time I'm reading a lot and trying to catch up on the past few years of TOR news and development. -Jon

2 1