tor-relays

tor-relays@lists.torproject.org

36 participants
4815 discussions

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays