- tor-relays - lists.torproject.org

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 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

Relay bandwidth usage drop
by Jobiwan Kenobi 27 Sep '13

27 Sep '13

About 2 days ago, around midnight of September 20, bandwidth usage on my relay dropped from averaging a bit over 100KB/s to around 20KB/s. It's been low ever since. Consensus weight dropped accordingly. You can see on the graphs on atlas and globe. My relay is named jobiwan. There seems to be nothing wrong with my relay. Log is pretty clean and handshake and heartbeat reports indicate normal operation (just not much of it). From time to time I have bits of normal throughput. I have no indication that I'm being throttled or traffic shaped. Is there anything I should look into? Thanks, -Job

2 2

(no subject)
by ابوصالح 27 Sep '13

27 Sep '13

Android مرسل من الهاتف المحمول Samsung

2 1

. Re: Relay security, re: local network
by Harold Naparst 26 Sep '13

26 Sep '13

I have been running an exit relay from my home for many years with no issues. If you are willing to support the ideals of the Tor project, you should be willing to run an exit relay. Obviously, without exit relays, the Tor project would be useless. I am unable to surf to exactly one site that I know of, a hosting provider. I solved that problem by choosing another hosting provider, Amazon Web Services (AWS). If you are ever blocked, it is easy enough to rent another IP address at AWS for $7 per month by signing a one-year contract for a reserved micro-instance. Then run a squid server on that micro instance and use it as a proxy server. But as I said, this hasn't been a problem for me. Also, keep in mind that running an exit relay from your home will provide you with better anonymity. If you combine that with surfing using the Tor Browser bundle, you will have pretty good anonymity. (I read that once on the Tor project's site.) Regards, Harold

3 2

Which is more helpful, availability or speed?
by phoneyball＠vfemail.net 26 Sep '13

26 Sep '13

Hello all, If my relay is in a datacenter with a fast link but constrained by a in+out<100GByte monthly limit, is it more helpful to provide: * a slow relay that is usually available, e.g. 30KByte/sec available about two-thirds of the time, or: * a fast relay that hibernates a lot, e.g. 1MByte/sec but only available 1/50th of the time? Secondly, is it more helpful to be: * available every day for a fraction of that day, or: * available continuously for some consecutive days then hibernated for the rest of the month? Thanks for any advice. (I've read differing opinions on these questions written at different times, but haven't found a clear consensus.) P. Honeyball ------------------------------------------------- VFEmail.net - http://www.vfemail.net $24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!

3 2

Future versions and Vidalia?
by J.C. 24 Sep '13

24 Sep '13

Are all future versions of Tor Browser Bundle going to have Vidalia permanently stripped? I'm running a stable relay on Linux with the TBB (and thus, Vidalia) instead of installing the Tor packages, and i quite like it this way. I don't remember what exactly went wrong, but some months ago i tried to get a relay running by installing and configuring it with the terminal and failed miserably, even though i was following instructions to the letter. I could try again but i'm a huge fan of the "if it's not broken, don't touch it" approach, and my relay works fantastic right now. If Vidalia is going to be permanently dropped at some point, is there any other way to continue running a relay than the terminal? I had a look at TBBv3 and didn't find a way to enable relaying.

3 5

Tor Slides
by Simon 24 Sep '13

24 Sep '13

Hello Is there a public share with presentationslides for tor ? I'll soon hava a presentation, and i want to use the most recent informations. Simon

2 1

Re: [tor-relays] Future versions and Vidalia?
by Jesse Victors 24 Sep '13

24 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Date: Mon, 23 Sep 2013 12:54:34 +0300 > From: "J.C." <jc80(a)riseup.net> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Future versions and Vidalia? > Message-ID: <52400FDA.2060309(a)riseup.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Are all future versions of Tor Browser Bundle going to have Vidalia > permanently stripped? I'm running a stable relay on Linux with the TBB > (and thus, Vidalia) instead of installing the Tor packages, and i quite > like it this way. I don't remember what exactly went wrong, but some > months ago i tried to get a relay running by installing and configuring > it with the terminal and failed miserably, even though i was following > instructions to the letter. I could try again but i'm a huge fan of the > "if it's not broken, don't touch it" approach, and my relay works > fantastic right now. > > If Vidalia is going to be permanently dropped at some point, is there > any other way to continue running a relay than the terminal? I had a > look at TBBv3 and didn't find a way to enable relaying. I'm in exactly the same boat. I would _highly_ recommend that the current TBB stay exactly the way it is. I'm against having a ton of services start up by themselves. As a Linux user, I enjoy having the power to control what I start things up, and when. Sometimes I start my computer and I don't want certain things to start. The disadvantage of having a service install is that I lose much of that control. I too have tried to set up a Tor relay via packages and such, and I also failed. The TBB was orders of magnitude easier: I just click "configure relay" and things work fine. Vidalia is also extremely easy to use, and I like the interface. I would advise that the dev team reconsider. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQF8BAEBCgBmBQJSQPJhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAWX4H/jp1DlCgdJqRQd9I0pVpozDu VlA75uAtFxIM0VYr+eIVuC2OqQHUUFZLYNwFfePUZvIxy9bedL5WlkdZQCsaenaY wu3sLMpoBz8cH2qM/Ne5JIiFCTUEOL7XwA5d8ehdGSmnZUaBXANwiJ23uh2eVpeE HKvU/bnS5wp0YG7x/xHyQ5SGCpyWXb5H7LnGtNol9GTvbTgepo9rHtVmUCgdA5Wg BJe1yXAy/lAv5GjloejBtTu4whPuZOuY5FU+1LRHt3wnShLgEMy7UXeVQpAK2pDa mEvKD75aIb2AevGAsSdqBs2FsOOimQ7FrWudH3aZHYB6g5+nfOouLxBVcDoVjts= =Bjy+ -----END PGP SIGNATURE-----

2 1

Tor flood symptom?
by David Carlson 23 Sep '13

23 Sep '13

My relay that has been running release 0.2.4.17-rc for several day now has become saturated with what I would consider 'noise' - namely a huge amount of handshake activity. It does respond downward to lowereing the bandwidth setting, but the bandwidth graph is nearly flat. Now I have just noticed two crypto errors in the message log. Sep 23 14:17:32.902 [Notice] Circuit handshake stats since last time: 224326/224887 TAP, 40/40 NTor. Sep 23 15:17:32.999 [Notice] Circuit handshake stats since last time: 224169/225104 TAP, 77/77 NTor. Sep 23 16:17:32.016 [Notice] Circuit handshake stats since last time: 224655/225333 TAP, 63/63 NTor. Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1) Sep 23 16:50:14.883 [Warning] crypto error while checking RSA signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT) Sep 23 17:17:32.782 [Notice] Circuit handshake stats since last time: 222538/222987 TAP, 14/14 NTor. Sep 23 17:36:03.704 [Warning] eventdns: All nameservers have failed Sep 23 17:36:03.829 [Notice] eventdns: Nameserver 192.168.1.254:53 is back up Is this acceptable or should I report this to bugzilla? David?

1 0

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

21 Sep '13

On Friday 20/09/2013 at 6:37 am, Moritz Bartl wrote: > > I don't think exit relay operators are in a position to have anonymity > in the first place. It is fine if you manage to pay for and run your > relay anonymously, but I doubt it will survive more than a few LEA > inquiries where they end up with a fake name instead of a real > contact. > I get the sense that there are some exit node operators who can't attempt it or deliberately aren't for reasons related to the direct ownership of abuse complaints. But there are some where there could be ambiguity. It is not always clear-cut who the end-user of each service is. Things like leased servers with multiple sub-users, roommate/shared internet, shared VPNs, shells given away to friends, etc, are a part of it. > > How is the method of transferring funds relevant to liability or risk > in > that respect? What method of transfer would change anything about > that? > It's not all about the method. Thoughts are: - One way to damage Tor would be to mess things up for exit node operators either personally or professionally. IMO the less 'they' know about exit operators, the less damage they can do with that kind of approach. That would include information obtained from getting to know someone on IRC in this context, as you don't really know who you are talking to or if you're being monitored. - If authorities can ever build a case where Tor can be accused of being a dirty little network which hosts criminal content and profits from it, it seems that it could be fucked. I already saw Tor identified by one media source as simply being an internet network that criminals use. We know that this isn't a fair description but I'm not sure that would make a difference if certain cards get played? - When you can be demonstrated to have received money, depending upon what that money was sent for, it can be used against you. If money was to be sent, it seems better if it were done as a consulting sort of agreement? It would be invoiced like any other internet consulting service you are willing to provide (and it wouldn't be the only service offered). It wouldn't involve personal-feeling chats on IRC, it would be a professional relationship. What do you think? I don't want to scare anyone away with this stuff. Just feel like we should be more careful than what I was reading. Doesn't feel right to encourage exit node operators to show up on IRC with their bank account #s ready to go.

2 1

What happens with the time on turtles 76.73.17.194?
by tor-admin 21 Sep '13

21 Sep '13

Hi Mike, I am seeing many of these messages in the logs of torland1/torland2: Sep 21 12:09:34.000 [warn] Received NETINFO cell with skewed time from server at 76.73.17.194:9090. It seems that our clock is ahead by 15969 days, 10 hours, 9 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Can you please check turtles. Thanks & regards, torland

2 2

Is this HAL?
by I 21 Sep '13

21 Sep '13

3 2

non-exit risks?
by That Guy 21 Sep '13

21 Sep '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > You're probably fine, especially if not running an exit. You didn't list your home country, though; I'm assuming United States. > Best, > -Gordon M. While I know you have vastly more knowledge and experience than me and often my observations or worries are doe to me mis-understanding something but about the comment above, I have experienced issues running a non-exit relay pretty soon after it going up and though I have no idea if there is a connection, I started to get more trouble after the doubling of connections at the end of July. I was blocked from a number of websites, Had many of my emails returned because of a flagged IP(the one listed was not my ip) Ended up on a several blacklists within a week of starting my relay, SORBS being the most eager to BL you it seems. a few other small but new issues/quirks that I don't know enough about to attribute to anything Tor other than the timing. anyway, just my .02 btc That Guy grep(a)gmx.us _________________________________________________________________________ GnuPG Fingerprint: 7770 D186 A06E A329 2217 3161 63EB F269 37B8 8644 _________________________________________________________________________ “If you’re doing nothing wrong, you have nothing to hide from the giant surveillance apparatus that the government’s been hiding.” – Stephen Colbert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSPFjnAAoJEGPr8mk3uIZErgYQAJFXCfo0C0ekeY82Z6T2+hTO cWNL+S3swDU9Mr3IyT2bVYep3IDrBmJ4HtyixtMo2DzVQjYKsl1cNT6U07GILmdp bSUfOc5PEyn9phZ4bz1dR6dcXn2vMMAXMaiFfCcgbZnQyIZC/Xmkzq8jiwk/SEaU n/k3536nNj/2QToMhd5D702vDl5vJ1VOa174/w5/8LEgHgE7MBKAyFKYnZSVTBbl /BqF5UqucNPZBbOEL4dljawehENlWkBe2LRGmrXtHABgZtN49UQV3lIzPGg6mUOP BPlp5AkKNwRkS1PcH9oGBDFgTXo9ekumT2uxJs5g2fsskYcINXHc8LM18U9M5CLp Zab5AsSwOWnuNX8WNPSTN9Fv2jHgpalboE7ku2CfXQ52YvxytNJ6FS3QWVVJ058J jsXhvK9C/TizFImZssRlBzCoP2xLAtKFy9Z2dtIYXJ+nh9oOwvg9Ps+pX5c9yM6O hS+eG/rStIKNNEunMgM7h9ikBEjjP4ywUY+5Hbqrx5NMqZtHLhU06v0BivR97Gfi Yfg5tKRrgrBLb9kP/7M0RGPcTtVxwMcRTDt4lGR5IoW2VkfUsLhCMoMyMvOaD6bf fFbvkVjB//4l2SMBghppDpUIelw0OhrOKi8ZXOwejzQITtEXgWXOIAuZPqF+OU0f jMtxNs5m1uvZVNyxreTK =8PY+ -----END PGP SIGNATURE-----

6 7