Hi, throughout the summer I've been on a project called 'arm' (anonymizing
relay monitor). It's a terminal monitor for Tor relays providing
bandwidth/cpu/memory usage, relay configuration, event log, connection
details, etc. The project is intended for command-line aficionados, ssh
connections,
Also, the arm monitor tallies up the BW events (bandwidth usage reported by
tor) to provide the totals for the duration that it runs. Cheers! -Damian
On Tue, Sep 15, 2009 at 5:33 PM, Andrew Lewman and...@torproject.orgwrote:
On 09/15/2009 01:21 PM, Michael Gomboc wrote:
I have a tor server
Interesting idea, but seems like it could be pretty dangerous. If an
attacker was able to figure out the subset of Tor users taking advantage of
these special exits and ran one themselves then correlation probably
wouldn't be too difficult. In addition, abuse issues makes finding exit
operators a
Hopefully I've got these right...
Are the choices of the ORs in the path all based on the advertised bandwidth
(Is that the average bandwidth value or the observed)?
At the moment weighting is based on advertised bandwidth (with the exception
of the entry and exit selection which has special
Exit relays are definitely the most useful (thanks for running one!).
However, it's preferable to have a fast relay for part of the month rather
than a slow relay always available so I'd suggest using AccountingMax rather
than RelayBandwidthRate/Burst to stay below your provider's cap. Cheers!
Not sure about the first question (my guess would be either multiple
circuits are built for added bandwidth or for complimentary exit
policies - docs or someone else could answer this).
As for the second question, I'm assuming that entries using nickname
(verses a fingerprint like
+1. I was kinda floored at the logic behind 'since this attack hasn't
been used in the wild it should be ignored' but... for each their own.
;)
-Damian
On Sun, Feb 14, 2010 at 9:16 PM, Flamsmark flamsm...@gmail.com wrote:
On 14 February 2010 03:15, Scott Bennett benn...@cs.niu.edu wrote:
But
I guess arm is using this or something similar to display the bandwidth
usage of Tor.
Nope, arm just gives a running total of the BW events (ie, if you restart
arm the totals will revert to zero). At the moment I'm unaware of a method
of getting the total bandwidth besides tallying it (though
Unfortunately the state doesn't provide a complete bandwidth history - if
you check on line 1168 of src/or/rephist.c you'll see:
/** How many bandwidth usage intervals do we remember? (derived) */
#define NUM_TOTALS (NUM_SECS_BW_SUM_IS_VALID/NUM_SECS_BW_SUM_INTERVAL)
This is used later when
While I understand your concern I disagree since we're already in this boat.
I'm currently running a relay with Comcast as my ISP, and if I was going to
run an exit I'd go back to the past list correspondence about low-hassle
(tor friendly) hosting solutions. In both cases my ISP or hosting
) Me: thx
On Wed, Mar 10, 2010 at 9:24 PM, Damian Johnson atag...@gmail.com wrote:
While I understand your concern I disagree since we're already in this
boat. I'm currently running a relay with Comcast as my ISP, and if I was
going to run an exit I'd go back to the past list correspondence about
Thanks Anders! You're right - this is a highly requested piece of
information (dozens of times at least this year). If this makes it into the
control spec it might be nice to include an option for the total bytes
downloaded/uploaded verses since the last reset (sighup). Regardless,
keeping my
Hi there John - glad to have you working with Tor! We're really anxious to
see where you go with this project since, as exemplified by the recent
incident with PrivacyNow [0], we're currently pretty miserable about
noticing and flagging bad exits.
Unfortunately our definition of a bad exit is
Hi GD. I'd imagine the acronym in this case is very well known to most
people here, since it's the location of the tor irc channels. It's also
plenty unique and search able - if it was an alternative definition of, say,
'SOAP', then I'd fully agree with you. -Damian
On Sat, May 1, 2010 at 8:49
:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On Sat, May 15, 2010 at 11:58:44PM -0400, Roger Dingledine wrote:
On Sat, May 15, 2010 at 06:37:54PM -0700, Damian Johnson wrote:
Hmmm... so we aren't interested in having a clearer definition of what
makes
up a bad exit? From
Does anybody use tortunnel ?
Never heard of it before, so doubt it.
Is tortunnel evil since it maybe hacks Tor-cirucits to reduce the number
of relays ?
We discourage people from reducing the circuit length since it cripples the
anonymity tor provides, makes exit nodes more tasty targets
The trick is that both parties need to list each other as family for this to
work. As per the man page..
When two servers both declare that they are in the same 'family'...
The attacker would need to be listed in every other relay's torrc for the
attack you described to work. I'm pretty sure
Oops, apologies - didn't realize this had already been answered. (a pox upon
thread forking...)
On Thu, May 20, 2010 at 7:03 AM, Damian Johnson atag...@gmail.com wrote:
The trick is that both parties need to list each other as family for this
to work. As per the man page..
When two servers
This is not something to be 'fixed', see:
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ
and search for You should hide the list of Tor relays, so people can't
block the exits. (sorry about the lack of an anchor, guess it was lost in
the move to trac). Cheers! -Damian
On
Doh! My stupidity, sorry. Here's the anchored link:
https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldhidethelistofTorrelayssopeoplecantblocktheexits
.
-Damian
On Fri, May 21, 2010 at 9:20 AM, Damian Johnson atag...@gmail.com wrote:
This is not something to be 'fixed
Probably because your exit node is being used to do something that
warrants an abuse report.
Maybe, but if this shadowserver site is being incommunicado then I wouldn't
put much confidence in their findings.
Stop the activity on your exit node that is causing them to lodge reports?
Very
No. The directory authorities determine the consensus. They are not capable
of figuring out what relays you've picked from it for your circuits.
I'm kinda confused why you want to use them for your entry nodes. Setting
StrictEntryNodes this way harms your anonymity since you're only making use
of
No, it's not related to tor and be aware that the design (shown in their
FAQ) looks like you're sending your traffic via this Tor-Proxy.net thing,
which means you're trusting them in the same fashion as a single hop proxy.
-Damian
On Wed, Jul 21, 2010 at 8:14 AM, emigrant
Just a heads up that there *has* been torrc validation in arm for quite some
time now. Warnings about this issue (unused entries due to duplicates) have
been given since release 1.2.2 (11/8/09, so bit less than a year now). I
just tested and it has been giving warnings about ExcludeNodes all this
One option for providing feedback on the health of the relay would be arm (
www.atagar.com/arm) with the following config changes to keep with the aims
of tor-ramdisk:
# would prevent any connection related information from being queried
startup.blindModeEnabled true
# crops log messages after a
Hi Theodore.
The reason the operators of the largest tor relays (Blutmagie,
TorServers, and Amunet) operate multiple instance is because this is
the best way in practice for utilizing large connections. Robert and
others are right and you should call people out if they operate
multiple relays
Hi. After over a year it's about time that I announced an arm release
so here it is! What's new since August of 2009 [1], you ask? Lots. The
project has been under very active development, continuing to add
usability improvements to make relay operation nicer and less error
prone. If you're really
work just fine. -Damian
On Tue, Nov 30, 2010 at 10:56 PM, John Case c...@sdf.lonestar.org wrote:
Hi Damian,
On Tue, 30 Nov 2010, Damian Johnson wrote:
Hi. After over a year it's about time that I announced an arm release
so here it is! What's new since August of 2009 [1], you ask? Lots
this is
generally of interest to the rest of the tor community. -Damian
[1] https://svn.torproject.org/svn/arm/trunk/src/util/connections.py
On Wed, Dec 1, 2010 at 10:34 PM, John Case c...@sdf.lonestar.org wrote:
On Wed, 1 Dec 2010, Damian Johnson wrote:
Arm should work just fine under BSD with the exception
far no one has
volunteered to do a bsd port.
On Fri, Dec 3, 2010 at 11:34 AM, Fabian Keil
freebsd-lis...@fabiankeil.de wrote:
Damian Johnson atag...@gmail.com wrote:
The lsof command issued by arm [1] is:
lsof -nPi | grep process\s*pid.*(ESTABLISHED)
I'd be happy to work with you to provide
Hi all. I've checked in the resolver fixes (thank Fabian and Hans!)
and a test tarball is available at:
http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2
http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc
I've added both of the commands you mentioned as fallback resolvers.
On Ubuntu
This IP serves as the internal adress to the jail when
called from a local subnet, and may show multiple connections to the
SocksPort,
usually IP:9050.
Sorry, I'm not sure if I'm following. You're saying that the check
should essentially be:
if (localPort == ORPort or localPort ==
Fantastic - thanks Fabian! The patch looks perfect. I'll apply it
either after work today or tomorrow morning.
but I think the same should be done with connections on the SocksPort
Yup, sounds like a bug. Until recently arm had just been for relay
usage so I probably missed this when writing
... Damian, how
many connections are on the node that you successfully see the conn list ?
I don't recall. It was on amunet and I'll retest this once the relay's
back up to speed (we recently switched ISPs so it'll take a few weeks
for the BW authorities to send more traffic our way again).
Hi, I've uploaded a new tarball to:
http://www.atagar.com/transfer/tmp/arm_bsdTest3.tar.bz2
http://www.atagar.com/transfer/tmp/arm_bsdTest3.tar.bz2.asc
Besides a modified version of Febian's patch to autodetect FreeBSD
jails it most notably includes...
- A replacement for the connection test
Hi everyone. The next version of arm (1.4.1) is available including
the proc querying enhancements, Fabian's BSD compatibility patches,
and numerous other improvements:
https://blog.torproject.org/blog/arm-release-141
Updates to the packages and repositories will be staggered a week
(just in case
That's because it's a hidden service. Here's the tor2web page:
https://xqz3u5drneuzhaeo.tor2web.org/users/shew/shewstring/20110127-shewstringv1.0.0.html
-Damian
On Fri, Jan 28, 2011 at 2:59 PM, Zaher F. the_one_man...@hotmail.com wrote:
the link is not working
Date: Fri, 28 Jan 2011
Damn, looks like the bin function is new in Python 2.6:
http://docs.python.org/library/functions.html#bin
Thanks for the catch. In the future please file a trac ticket rather
emailing everyone on or-talk. Cheers! -Damian
On Sun, Jan 30, 2011 at 12:25 AM, Paul Menzel
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
[1] https://trac.torproject.org/projects/tor/wiki/badRelays
On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote:
At some point, we intend to shrink exit
, Orionjur Tor-admin
tor-ad...@orionjurinform.com wrote:
Damian Johnson wrote:
The five relays Mike mentioned have been flagged as BadExits [1].
Adding them to your ExcludeExitNodes isn't necessary. -Damian
[1] https://trac.torproject.org/projects/tor/wiki/badRelays
On Sun, Jan 30, 2011 at 1:33
Can you please say a little more about this for all of us who are not au
fait with all command options?
Relays have an option to allow single hop connections through them,
which is off by default. If relays *do* set this and allow single hop
circuits through themselves then Tor clients by
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l1285
On Tue, Feb 1, 2011 at 4:10 PM, Joseph Lorenzo Hall joeh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote:
In both of those cases we took harder measures based on suspicion
the whole discussion didn't change my mind. I still support the idea of
flagging them as bad exit.
Same. Mike gave some good reasons for flagging them weeks ago and I've
yet to see much else besides ranting that seems to ignore most of this
thread. -Damian
43 matches
Mail list logo