tor-relays September 2013

tor-relays@lists.torproject.org

95 participants
83 discussions

Need help to get TorDNSEL compiled
by BlueStar88 26 Jun '14

26 Jun '14

Hi there, today I've read about the outage at "check.torproject.org". Since my torcheck-service "torcheck.xenobite.eu" needs the underlying TorDNSEL feature I'm trying to get this to work on my host. Like this I won't need to query the TorDNSEL-part of "check.torproject.org" anymore. I'm not into programming and do not know anything about haskell, c++ and such. So be patient with me on such matters. ;-) I've DL'ed the code from the internet website mirror [2]. I've prepp'ed all the dependencies using lucid binary packages: ghc6 6.12.1-12 libghc6-mtl-dev 1.1.0.2-10 libghc6-network-dev 2.2.1.7-1 libghc6-time-dev 1.1.2.4-2 libghc6-hunit-dev 1.2.2.1-2 libssl-dev 0.9.8k-7ubuntu8.15 libghc6-stm-prof 2.1.1.2-5 libghc6-binary-prof 0.5.0.2-1 First error I got on compile attempt was: src/TorDNSEL/Main.hs:81:21: parse error on input `#' That was quite easy thought: import GHC.Prim (Addr#) I deleted the '#' hopefully making it correct this way. Next error is some numbers too high for me now: src/TorDNSEL/DeepSeq.hs:20:7: Could not find module `Data.ByteString': It is a member of the hidden package `bytestring-0.9.1.5'. Perhaps you need to add `bytestring' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. The libghc6-bytestring-dev-0.9.1.5-125af ist installed by it's main package ghc6 6.12.1-12. Any ideas? Or are there some binary packages for TorDNSEL around, to make this more easy for me? :-P Thanks, BlueStar88 [1] https://blog.torproject.org/blog/tor-check-outage-03-and-04-july-2013 [2] https://www.torproject.org/tordnsel/dist/tordnsel-0.0.6.tar.gz

3 7

Relay security, re: local network
by Joe 21 Oct '13

21 Oct '13

Hi, I'm planning to run a Tor relay on a spare computer at home. Security is a concern, and not only regarding the machine running the relay but also my other computers. Are there any (theoretical or otherwise) known attacks a person can perform on a running Tor relay to take remote control of it, and assuming the said person could pull that off, is it possible to extend this control to the other computers behind the same router? I am aware of possible DDOS attacks and other risks related to running an exit, but i am comfortable in taking these chances in my environment. I would run the relay on a yet-undecided-Linux distro, possibly Mint Debian or some flavor of Ubuntu which i am more familiar with, and use full-disk encryption with strong passwords. Are there any risks to my other computers worth consideration? Thanks.

11 13

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

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 29 Sep '13

29 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays September 2013