- tor-relays - lists.torproject.org

Re: [tor-relays] iptables / dump
by Sebastian Urbach 15 Nov '14

15 Nov '14

On November 15, 2014 2:33:23 PM Libertas <libertas(a)mykolab.com> wrote: Hi, > > Honestly, the safest thing to do is to NOT USE PASSWORD BASED > > LOGINS. Im aware of that. > I wrote a script to scan the Tor network for password-based login > availability. If I have the time and no one beats me to it, it'll lead > to a site that warns relay operators about security problems with > their servers. For example, I can combine it with basic, non-invasive > nmap results to warn about non-essential network applications, old OS > versions, and old Tor versions as well. Awesome, like to see that. Sebastian

1 0

Graph not updating.
by Kevin de Bie 14 Nov '14

14 Nov '14

Is there any paticular reason the bandwidth graph flatlined since last night? My ISP may have had some maintenance but my TOR relay is purring like a kitten again, data throughput is quite formidable at the moment at around 1mbps. I use orbot on android.

1 0

Relay's clock settings off no matter what
by Austin Bentley 14 Nov '14

14 Nov '14

Hello everyone, I have an interesting problem. I am monitoring my relay using arm. I am getting the following warnings: >05:56:12 [WARN] Received directory with skewed time (server '154.35.32.5:80'): It seems that our clock is behind by 1 hours, 0 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time, timezone, and date settings. Most of the messages tell me that my clock is an hour behind. However, I also get these messages occasionally (but not as often): >02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind the time published in the consensus network status document (2014-11-14 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! I am running a Tor exit relay on a FreeBSD VPS. Said VPS is in Czech Republic. If I set the time to CET, it is 1 hour behind true CET (GMT+1); therefore, I have it set to EET (GMT+2.) I have verified the time is correct in Czech Republic. This problem is rather frustrating because it is causing my server to throw away circuit data as old data. Could someone shine some light on this? Thanks, Austin

7 9

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 13 Nov '14

13 Nov '14

Looks like the BBC have changed their rules. I am still running a relay, but can now access www.bbc.co.uk in a normal fashion. Still blocked by national lottery, but I'm hopeful that they both use the same third party ip checker, and that the next lottery update will fix the issue. On Thu, Sep 18, 2014 at 10:41 PM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. RELAY_EARLY tor network update status (CVE-2014-5117) (Nusenu) > 2. Re: BBC and UK Lottery blocking ip addresses running relay > (Ross Petrie) > 3. Re: BBC and UK Lottery blocking ip addresses running relay > (Chris Whittleston) > > > ---------- Forwarded message ---------- > From: Nusenu <BM-2D8wMEVgGVY76je1WXNPfo8SrpZt5yGHES(a)bitmessage.ch> > To: tor-relays(a)lists.torproject.org > Cc: markus(a)mdfnet.se, info(a)enn.lu, torpids(a)yahoo.com, nick(a)calyx.com > Date: Thu, 18 Sep 2014 21:00:41 +0000 > Subject: [tor-relays] RELAY_EARLY tor network update status (CVE-2014-5117) > (if you are on the CC list of this email you are probably one of the tor > relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] > relays on the tor network. Please upgrade your tor relay) > > > The tor network is currently at 64% of the bandwidth being served by > > relays running a recommended version according to torstatus.blutmagie.de > . > > I updated a previous metrics feature request so we might see nice > > graphs about patching progress in the future [2]. > > Since we are seeing active RELAY_EARLY attacks again (or new buggy tor > implemantations) I was wondering what the current update stats look like. > > ~85%* of the tor network's bandwidth is provided by patched relays. > (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) > > *) according to data from torstatus.blutmagie.de > > > 10 fastest relays still running a vulnerable version: > > > https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… > > https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… > > https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… > > https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… > > https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… > > https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… > > https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… > > https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… > > https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… > > https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE… > > > > > ---------- Forwarded message ---------- > From: Ross Petrie <ross.petrie(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:18:05 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > Hi all, > > I've just reported this same issue this week, no reply yet. > > I can still watch catch up BBC TV through my sky box though. > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 22:41:04 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay > > That's great news Dan, keep us posted! > > Chris > On 18 Sep 2014 21:40, "Dan Hanley" <hanley.dan(a)gmail.com> wrote: > >> >>> I have just received a slightly more positive reply: >> >> "At present, our GeoIP data provider classes Tor nodes as proxies, >> regardless of whether or not they're an exit node. We understand that there >> is room for improvement in this model, since non-exit relays do not present >> traffic on behalf of other users. We have asked our provider to give us a >> way of differentiating Tor exit nodes from non-exit relays, to allow us to >> block exit nodes only." >> >> So perhaps they will make a change... certainly reporting the issue seems >> to raise its importance :-) >> >> atb >> >> Dan >> >> >> >>> >> >> 5. Re: BBC and UK Lottery blocking ip addresses running relay >>> nodes (Chris Whittleston) >>> ---------- Forwarded message ---------- >>> From: Chris Whittleston <csw34(a)cam.ac.uk> >>> To: tor-relays(a)lists.torproject.org >>> Cc: >>> Date: Thu, 18 Sep 2014 01:40:31 +0100 >>> Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses >>> running relay nodes >>> Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt >>> though, it seems like they still don't get the difference between using Tor >>> as a client and running a relay, so this isn't the end of the road there. >>> You are going to have to rely on them wanting to actually think about it >>> though. >>> >>> If all else fails, you could always try to simply report the issue again >>> using the form I linked before, but this time just don't mention Tor at all >>> and see if you get a different customer service person... >>> >>> http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 >>> >>> I suspect you'll end up having to explain that you're running a relay in >>> the end anyway, but you never know. >>> >>> Chris >>> >>> On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: >>> >>>> Stephen Mollett: >>>> > [...] >>>> > "Thank you for contacting the BBC iPlayer support team. >>>> > >>>> > "I understand you’re experiencing problems accessing BBC iPlayer as >>>> > you’re told that you are outside of the UK. >>>> > >>>> > "Please note that if you run TOR, then I’m afraid as per our >>>> development >>>> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >>>> > continue to use TOR then your IP address may be blacklisted against UK >>>> > only services across bbc.co.uk." >>>> > >>>> > I made a point of stating explicitly in my original case filing that I >>>> > run a middle relay and that no traffic exits from my node to the BBC's >>>> > website or to anywhere else, along with a link to my node's stats on >>>> > blutmagie confirming the (non-)exit policy. >>>> > [...] >>>> >>>> Hi Stephen, >>>> >>>> I'm not sure whether I'm surprised at the BBC or not! >>>> >>>> It is a shame if they seem to be doing blanket blocking of Tor relay IP >>>> addresses. I suppose this >>>> ( >>>> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >>>> ) >>>> has /some/ relevance. >>>> >>>> The problem is obviously convincing a organisation like the BBC to treat >>>> individual IP addresses different from other Tor relay IP addresses (and >>>> whether they should be doing that at all). Although it seems Chris >>>> Whittleston obviously managed it! Maybe you simply got 'the wrong person >>>> at the other end'. Personally, I would continue to pursue this with >>>> them! >>>> >>>> --Matt >>>> >>>> >>>> >>>> _______________________________________________ >>>> tor-relays mailing list >>>> tor-relays(a)lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>> >>> >>> >>> >>> -- >>> *Dr Chris Whittleston 栗主* >>> Department of Chemistry >>> University of Cambridge >>> Lensfield Road, Cambridge, CB2 1EW >>> Email: csw34(a)cam.ac.uk >>> Tel: +44 (0)1223 336423 >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >>> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> >> > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

4 4

Why isn't my relay getting indexed?
by Dedalo 13 Nov '14

13 Nov '14

I was running 2 relays but I'm currently running 1 (with no problem) since some months ago, One of my VPS accounts got suspended and I'm now trying to setup another relay, a middle relay. This new VPS has been running the tor relay since about 12 hours ago but It's not getting indexed in http://torstatus.blutmagie.de/ neither atlas :/ not sure why, I can see I'm getting connections to 9001 but I can't understand why is this happening... Regards, Dedalo. -- Twitter: @SeguridadBlanca Site: Blog.Dedalo.In

3 6

Re: [tor-relays] Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 12 Nov '14

12 Nov '14

Drake Wilson <drake(a)dasyatidae.net> wrote: > thegreatwent(a)Safe-mail.net wrote: > > So that mostly just leaves open the question of why managed mode obfsproxy wants to read /etc/passwd and nsswitch.conf? > > Sorry for jumping in without reading the whole context, but on GNU/Linux systems, > nsswitch.conf is used for determining how resolution works for host and user names > (among other things), and passwd is usually needed to map names to UIDs. If there's > anything that takes a "which user should I run as" parameter then it'll read those > two in the process of looking up the user, for instance. > > ---> Drake Wilson Thank you, I knew enough to be a bit concerned about /etc/passwd (even though there's no actual passwords in it), but not enough to know if it was an issue in this particular case! I'll continue with adding those files to the Apparmor profile and post back here when it's complete.

1 0

Re: [tor-relays] Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 12 Nov '14

12 Nov '14

I fixed the logging issue by changing "/var/log/tor/log rw," in the profile to "/var/log/tor/obfsproxy rw,"; and changing the value in my service script to: DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy --log-file=/var/log/tor/obfsproxy --log-min-severity=info obfs3 --dest $DEST server $SERVER" I also changed to PIDFILE="/var/run/obfsproxy.pid" because the earlier version didn't work on reboot. Now I can see I am getting traffic! 8 unique addresses in the past hour etc. So that mostly just leaves open the question of why managed mode obfsproxy wants to read /etc/passwd and nsswitch.conf? Is this the wrong place to ask? -------- Original Message -------- From: thegreatwent(a)Safe-mail.net Apparently from: tor-relays-bounces(a)lists.torproject.org To: tor-relays(a)lists.torproject.org Subject: [tor-relays] Standalone obfsproxy apparmor profile etc. Date: Tue, 11 Nov 2014 18:01:16 -0500 > Not sure if this is the right place to post or if this will help anybody, but I think I figured out how to run a standalone (NOT managed) obfs3 obfsproxy on Ubuntu 14.04 with a somewhat confined apparmor profile running under the debian-tor user. > > I verified this by looking at ps and it shows "debian-tor [...] /usr/bin/python /usr/bin/obfsproxy obfs3[...]". AA-STATUS says /usr/bin/obfsproxy is in enforce mode, and removing "network inet stream," for example from the aa profile results in obfsproxy failing to start. > > The line in the profile for "/usr/** r," is ugly, but replacing it with "/usr/bin/** r," didn't work. Obfsproxy log messages also seem to be going to /dev/null, so I'm missing something there. > > So Linux/Apparmor experts, is there anything bad/wrong with this setup? Am I relatively safe from bad guys hacking into my obfsproxy ports? How can I see if the good guys are using it successfully? > > The aa profile does not work for managed instances of obfsproxy. It complained about wanting read access to nsswitch.conf and /etc/passwd and I don't know enough python to understand why it wants that, so I didn't add it. > > Below is also attached: > > /etc/tor/torrc [just the relevant lines, using iptables to redirect from advertised obfs3port to actual] > > ------------------- > ServerTransportPlugin obfs3 proxy a.b.c.d:[advertisedobfs3port] > ExtORPort auto > ------------------- > > > /etc/apparmor.d/usr.bin.obfsproxy > > ------------------- > # vim:syntax=apparmor > #include <tunables/global> > > /usr/bin/obfsproxy { > #include <abstractions/base> > #include <abstractions/python> > network inet stream, > > /var/log/tor/log rw, > /dev/urandom r, > /dev/random r, > /usr/** r, > /usr/bin/obfsproxy rix, > > } > ------------------- > > > /etc/init.d/obfsproxy > > ------------------- > #!/bin/bash > > PIDFILE="/var/run/obfsproxy/obfsproxy.pid" > DEST="127.0.0.1:[ORPort]" > SERVER="a.b.c.d:[obfs3port]" > DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy obfs3 --dest $DEST server $SERVER" > > ### BEGIN INIT INFO > # Provides: Obfsproxy > # Required-Start: > # Required-Stop: > # Default-Start: 2 3 4 5 > # Default-Stop: 0 1 6 > # Short-Description: Obfsproxy > ### END INIT INFO > > case "$1" in > start) > echo "Starting Obfsproxy" > > /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ > --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON > ;; > stop) > echo "Stopping Obfsproxy" > > /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose > ;; > restart|reload) > /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose > sleep 1 > /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ > --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON > ;; > *) > echo "Usage: /etc/init.d/obfsproxy {start|stop|restart|reload}" > exit 1 > ;; > esac > > exit 0 > -------------------

2 1

Standalone obfsproxy apparmor profile etc.
by thegreatwent＠Safe-mail.net 11 Nov '14

11 Nov '14

Not sure if this is the right place to post or if this will help anybody, but I think I figured out how to run a standalone (NOT managed) obfs3 obfsproxy on Ubuntu 14.04 with a somewhat confined apparmor profile running under the debian-tor user. I verified this by looking at ps and it shows "debian-tor [...] /usr/bin/python /usr/bin/obfsproxy obfs3[...]". AA-STATUS says /usr/bin/obfsproxy is in enforce mode, and removing "network inet stream," for example from the aa profile results in obfsproxy failing to start. The line in the profile for "/usr/** r," is ugly, but replacing it with "/usr/bin/** r," didn't work. Obfsproxy log messages also seem to be going to /dev/null, so I'm missing something there. So Linux/Apparmor experts, is there anything bad/wrong with this setup? Am I relatively safe from bad guys hacking into my obfsproxy ports? How can I see if the good guys are using it successfully? The aa profile does not work for managed instances of obfsproxy. It complained about wanting read access to nsswitch.conf and /etc/passwd and I don't know enough python to understand why it wants that, so I didn't add it. Below is also attached: /etc/tor/torrc [just the relevant lines, using iptables to redirect from advertised obfs3port to actual] ------------------- ServerTransportPlugin obfs3 proxy a.b.c.d:[advertisedobfs3port] ExtORPort auto ------------------- /etc/apparmor.d/usr.bin.obfsproxy ------------------- # vim:syntax=apparmor #include <tunables/global> /usr/bin/obfsproxy { #include <abstractions/base> #include <abstractions/python> network inet stream, /var/log/tor/log rw, /dev/urandom r, /dev/random r, /usr/** r, /usr/bin/obfsproxy rix, } ------------------- /etc/init.d/obfsproxy ------------------- #!/bin/bash PIDFILE="/var/run/obfsproxy/obfsproxy.pid" DEST="127.0.0.1:[ORPort]" SERVER="a.b.c.d:[obfs3port]" DAEMON="/usr/bin/obfsproxy -- --profile=/usr/bin/obfsproxy -- /usr/bin/obfsproxy obfs3 --dest $DEST server $SERVER" ### BEGIN INIT INFO # Provides: Obfsproxy # Required-Start: # Required-Stop: # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Obfsproxy ### END INIT INFO case "$1" in start) echo "Starting Obfsproxy" /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON ;; stop) echo "Stopping Obfsproxy" /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose ;; restart|reload) /sbin/start-stop-daemon --stop --pidfile $PIDFILE --verbose sleep 1 /sbin/start-stop-daemon --make-pidfile --background --oknodo --start --pidfile $PIDFILE \ --chuid debian-tor:debian-tor --startas /usr/sbin/aa-exec --exec $DAEMON ;; *) echo "Usage: /etc/init.d/obfsproxy {start|stop|restart|reload}" exit 1 ;; esac exit 0 -------------------

1 0

Re: [tor-relays] Node Operators Web Of Trust
by tor＠t-3.net 11 Nov '14

11 Nov '14

On 11/07/2014 10:26 PM, grarpamp wrote: > Is it not time to establish a node operator web of trust? > Look at all the nodes out there with or without 'contact' info, > do you really know who runs them? Have you talked with > them? What are their motivations? Are they your friends? > Do you know where they work, such as you see them every day > stocking grocery store, or in some building with a badge on it? > Does their story jive? Are they active in the community/spaces > we are? Etc. This is huge potential problem. I can't think of a good reason to do this, or why there is a problem. Can think of quite a few negatives, the worst of which are related to the fact that NSA/GCHQ would like for Tor to go away. Something like what you describe would be a nice little tool for them to get useful-to-them personal info about Tor node operators. Even assuming that the node operators' identities are already known to the aforementioned agencies, how could feeding them juicy little details possibly help the situation. It also kinda has "perfect environment for social engineering" written all over it. Who's to say that the most trusted-feeling people in such a group wouldn't necessarily be one of the infiltrating baddies. They are pro at this.

1 0

Node Operators Web Of Trust
by grarpamp 11 Nov '14

11 Nov '14

Is it not time to establish a node operator web of trust? Look at all the nodes out there with or without 'contact' info, do you really know who runs them? Have you talked with them? What are their motivations? Are they your friends? Do you know where they work, such as you see them every day stocking grocery store, or in some building with a badge on it? Does their story jive? Are they active in the community/spaces we are? Etc. This is huge potential problem. NOWoT participation is optional, it is of course infiltratable, and what it proves may be arguable, but it seems a necessary thing to try as a test of that and to develop a good model. Many operators know each other in person. And the node density per geographic region supports getting out to meet operators even if only for the sole purpose of attesting 'I met this blob of flesh who proved ownership of node[s] x'. That's a big start, even against the sybil agents they'd surely send out to meet you. Many know exactly who the other is in the active community such that they can attest at that level. And so on down the line of different classes of trust that may be developed and asserted over each claimed operator. Assuming a NOWoT that actually says something can be established, is traffic then routable by the user over nodes via trust metrics in addition to the usual metrics and randomness? WoT's are an ancient subject... now what are the possibilities and issues when asserting them over physical nodes, not just over virtual nodes such as an email address found in your pubkey? And what about identities that exist only anonymously yet can prove control over various unique resources? If such WoT's cannot be proven to have non-value, then it seems worth doing. This doesn't just apply to Tor, but to any node based system.

8 11

Bwauths Measures question, friends.
by Rafael Rodriguez 10 Nov '14

10 Nov '14

Anyone knows how often bwauths measures a relay? I don't understand why directory authorities have not lifted the 20KB cap for my older relay. Now I have doubts if it could be a problem with my server. This is a 2MB/s relay with burst of 4MB/s to start tuning it and increase it later if stable, which is not being used and has been running for over 3 days. Is it normal for Relays to take longer than three days to start getting at least some traffic and for directory authorities to lift the 20KB cap? Fingerprint 48ADFCC561402D7EBB1CDE233F206B01D8FA0765

8 15

Windows Tor Server Guide
by Rafael Rodriguez 10 Nov '14

10 Nov '14

Hello fellows, Where can we contribute (post a guide) to deploy Tor in Windows without the extras unneeded stuff? I was looking for a Tor Server installation guide on Windows to run Tor as a service. I did not wanted to install all the extra browser stuff but a plain "Tor server" service and secure it by giving the service its own limited account and write permissions just to the datadir. Since I couldn't find information online to help me out, I ended up using the latest Tor Browser package and removing everything except Tor itself and deployed it in two Windows servers as services. I would like to post somewhere in the Top project about the process for others to benefit from it.

4 6

Re: [tor-relays] Node Operators Web Of Trust (Spencer Rhodes)
by Spencer Rhodes 10 Nov '14

10 Nov '14

> > From: Gareth Llewellyn <gareth(a)networksaremadeofstring.co.uk> > To: tor-relays(a)lists.torproject.org > Date: November 10, 2014 at 5:58:12 AM EST > Reply-To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Node Operators Web Of Trust > > > On Fri, Nov 7, 2014 at 8:26 PM, grarpamp <grarpamp(a)gmail.com <mailto:grarpamp@gmail.com>> wrote: > Is it not time to establish a node operator web of trust? > Look at all the nodes out there with or without 'contact' info, > do you really know who runs them? Have you talked with > them? What are their motivations? Are they your friends? > Do you know where they work, such as you see them every day > stocking grocery store, or in some building with a badge on it? > Does their story jive? Are they active in the community/spaces > we are? Etc. This is huge potential problem. > > I had an idea for this a little while ago; https://tortbv.link/ <https://tortbv.link/> using the published GPG signature in the contact info to sign the node fingerprint, if you trust the GPG key then you can _possibly_ trust that the node is run by the named operator. > > Never got round to actually doing anything with it though... > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Strikes me as a very good idea. Perhaps lawyers wielding attorney-client privilege could be used to protect the identities of those node operators who wish to remain anonymous. -- Spencer Rhodes, Esq. 126 East Jefferson Street, Orlando, Florida USA 32801-1830 t: +1.321.332.0407 | f: +1.321.332.0409 | m: +1.407.796.8282

1 0

Re: [tor-relays] Node Operators Web Of Trust
by Eric Hocking 10 Nov '14

10 Nov '14

That sounds like an excellent idea. if the site nowot.com is available, someone could register it. Maybe we could even get providers on board with the idea. > On Nov 10, 2014, at 7:00 AM, tor-relays-request(a)lists.torproject.org wrote: > > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Node Operators Web Of Trust (grarpamp) > 2. Re: Node Operators Web Of Trust (Gareth Llewellyn) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Nov 2014 15:26:40 -0500 > From: grarpamp <grarpamp(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: cypherpunks(a)cpunks.org > Subject: [tor-relays] Node Operators Web Of Trust > Message-ID: > <CAD2Ti2__JyLd2CYfWOitEOkPfOFDOiGb7_xqtUCgo+cKrJRVKw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Is it not time to establish a node operator web of trust? > Look at all the nodes out there with or without 'contact' info, > do you really know who runs them? Have you talked with > them? What are their motivations? Are they your friends? > Do you know where they work, such as you see them every day > stocking grocery store, or in some building with a badge on it? > Does their story jive? Are they active in the community/spaces > we are? Etc. This is huge potential problem. > NOWoT participation is optional, it is of course infiltratable, > and what it proves may be arguable, but it seems a necessary > thing to try as a test of that and to develop a good model. > Many operators know each other in person. And the node > density per geographic region supports getting out to meet > operators even if only for the sole purpose of attesting 'I met > this blob of flesh who proved ownership of node[s] x'. > That's a big start, even against the sybil agents they'd surely > send out to meet you. > Many know exactly who the other is in the active community > such that they can attest at that level. And so on down the > line of different classes of trust that may be developed > and asserted over each claimed operator. > Assuming a NOWoT that actually says something can > be established, is traffic then routable by the user over nodes > via trust metrics in addition to the usual metrics and randomness? > WoT's are an ancient subject... now what are the possibilities and > issues when asserting them over physical nodes, not just over > virtual nodes such as an email address found in your pubkey? > And what about identities that exist only anonymously yet > can prove control over various unique resources? > If such WoT's cannot be proven to have non-value, then it seems > worth doing. > > This doesn't just apply to Tor, but to any node based system. > > > ------------------------------ > > Message: 2 > Date: Mon, 10 Nov 2014 10:58:12 +0000 > From: Gareth Llewellyn <gareth(a)networksaremadeofstring.co.uk> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Node Operators Web Of Trust > Message-ID: > <CAM8M=ki3y0xgOEdsTJPU_Y7DPVRQ37uZ5rPrE1W4i_TjByNNaQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > >> On Fri, Nov 7, 2014 at 8:26 PM, grarpamp <grarpamp(a)gmail.com> wrote: >> >> Is it not time to establish a node operator web of trust? >> Look at all the nodes out there with or without 'contact' info, >> do you really know who runs them? Have you talked with >> them? What are their motivations? Are they your friends? >> Do you know where they work, such as you see them every day >> stocking grocery store, or in some building with a badge on it? >> Does their story jive? Are they active in the community/spaces >> we are? Etc. This is huge potential problem. >> > > I had an idea for this a little while ago; https://tortbv.link/ using the > published GPG signature in the contact info to sign the node fingerprint, > if you trust the GPG key then you can _possibly_ trust that the node is run > by the named operator. > > Never got round to actually doing anything with it though... >

1 0

How's your relay doing? Reporting Bad Relays
by Matthew Finkel 08 Nov '14

08 Nov '14

Hi Relay Operators, A few months ago[0], we announced the bad-relays(a)lists.torproject.org mailing list and asked everyone to send reports to that list if they suspected a relay was...bad. We've already received many reports, so please keep them coming. We also want to ask all of you to use that list, as well. If at anytime you think your relay is no longer safe for use, please tell us. Roger tweeted about this yesterday[1][2], too. The Tor network exists because of all of you and we can only keep it safe with your help. Let us know if you have any questions. Thanks! Matt [0] https://blog.torproject.org/blog/how-report-bad-relays [1] https://twitter.com/RogerDingledine/status/530878388605423616 [2] For those who don't want to open Twitter: If your #Tor relay is stolen or you lose control of it, please report it so we can blacklist it: https://blog.torproject.org/blog/how-report-bad-relays @TorProject

1 0

This may be a stupid question to you but how do I unsubscribe from these posts? Graeme.
by Graeme Briggs-White 07 Nov '14

07 Nov '14

As above....

3 2

Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network)
by grarpamp 07 Nov '14

07 Nov '14

On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd <adrian(a)freebsd.org> wrote: > ... that's .. odd. > > Let's poke the freebsd crypto and network stack people and ask. I > can't imagine why this is a problem anymore and we should default to > it being on. I don't think there's a crypto@ list, though security@ might represent. > The other thing you could do is have the tor port require > it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. > On 7 November 2014 00:20, grarpamp <grarpamp(a)gmail.com> wrote: >> On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter <phw(a)nymity.ch> wrote: >>> >>> FreeBSD still seems to use globally incrementing IP IDs by default. >>> That's an issue as it leaks fine-grained information about how many >>> packets a relay's networking stack processes. (However, nobody >>> investigated the exact impact on Tor relays so far, which makes this a >>> FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD >>> relays I tested (38%) use global IP IDs. >>> >>> There's a sysctl variable called "net.inet.ip.random_id" which makes a >>> FreeBSD's IP ID behaviour random. FreeBSD relay operators should set >>> this to "1". >>> >>> Note that this issue was already discussed earlier this year in a thread >>> called "Lots of tor relays send out sequential IP IDs; please fix >>> that!". >> >> It's been default off since before it was a sysctl over a decade ago. >> Anyone know what the deal is with that? Some objection, or >> forgotten flag day, or oversight that really should be set to 1? >> https://svnweb.freebsd.org/base?view=revision&revision=133720

1 0

Re: [tor-relays] Unexpected sendme cell from client. Closing circ (window 1000)." error message.
by K. Besig 06 Nov '14

06 Nov '14

Thanks for all the informative responses, they were truly underwhelming...

2 1

Re: [tor-relays] Adding relays with a click
by Nan 04 Nov '14

04 Nov '14

SiNA Thank you -- that looks like the script we need. Even though it was written for Ubuntu it should work just as well on debian. We probably can simplify it because every GoodCrypto server is already a tor proxy. Thanks again, Nan ----- On Nov 4, 2014, at 17:41:37, SiNA Rabbani sina(a)redteam.net wrote: > You mind find this script interesting: > > https://gitweb.torproject.org/tor-cloud.git/blob/ce98487e1174bff3a76c1f9f03… > > --SiNA GoodCrypto warning: Anyone could have read this message. Use encryption, it works.

1 0

Adding relays with a click
by Nan 04 Nov '14

04 Nov '14

We're considering trying to make it a single click for a sysadmin to add their GoodCrypto server to tor as a bridge or non-exit relay. Any experience with anything like this, especially responses from sysadmins? Nan GoodCrypto warning: Anyone could have read this message. Use encryption, it works.

2 1

CMU exit node IP address will change
by Zack Weinberg 02 Nov '14

02 Nov '14

CMU network operations has decided to move the Tor exit node that my group operates (tor-exit.cylab.cmu.edu) to an isolated subnet in order to minimize consequences for the rest of the campus network. For instance, apparently there have been several cases where third parties blacklisted the entire CMU IP space in response to malicious traffic from the exit node. This is currently scheduled to happen Tuesday (Nov. 4). The new IP address will be 204.194.29.4. I'm sending this message primarily as an assertion that nothing nefarious is going on, but also because I haven't had to change the IP address of a running node before and I would like to ask if there's anything in particular that should be done to minimize downtime. Thanks, zw

1 0

Unexpected sendme cell from...
by Kurt Besig 01 Nov '14

01 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I this was discussed awhile back through the mailing list and online to some extent, however I never grasped the solutions or any real resolution to the issue. My relay is getting fairly hammered daily and I'd appreciate any input regarding the, "[WARN] Unexpected sendme cell from client. Closing circ (window 1000)." error message. Horizons3 Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUVSJWAAoJEJQqkaGlFNDPKbcH/jZ1H4IAmNZ0PHUHIEvisBJJ oSHPQ6fgmtAHwdo6uJakc5L+f4aeIZrOfCKWQ+cQ/LxkcWmZs7H/0N4w/PV8mJWV xN0lPAso9VZLulLuHhLbIJrq6G2XJ1zmBbkmLrEGhT1ZAvFhjcFtwsVTsB0h52EO da2NWvMpNFESkznkvPZSVa7zIRk4nM4YIdb0jrMa1Jw+Z/JdhfE4IJZ2sCgf9HRu 1fX0318uL1AEN9KKYU4yxwZnboEoyluGALy42e7oGxHryctOHmez0MjXglA2j0BA 4VakJJfF8A4BTkGEzMhi4laDDh1glkRal8nJRONsBlTCulzqEMCCNSLml+Cw6Po= =PQab -----END PGP SIGNATURE----- --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

Re: [tor-relays] upgrade tor bridge raspberry-pi
by jchase 31 Oct '14

31 Oct '14

> On Thu, Oct 30, 2014 at 08:30:31PM +0000, jchase wrote: >> On hearing the news that tor 0.2.5.10 was available, I upgraded my >> raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade >> restarted the tor daemon automatically. I would have rather done it >> myself using a restart. When I used arm to look at my new traffic, I >> noticed that I had been magically turned into an exit relay (besides >> staying a bridge). My torrc was still intact and clearly stated: >> ExitPolicy reject *:* >> I restarted tor by hand and got the same result. I am not interested in >> having an exit relay. So I turned off the bridge and am waiting for >> advice from you. >> rasptorholland > > Is it possible you are being bitten by this arm bug? > > https://trac.torproject.org/projects/tor/ticket/12956 > https://trac.torproject.org/projects/tor/ticket/6430 > > --Roger Thanks! I will assume I was bitten by an arm bug and turn everything on again until the police come to look for me. -rasptorholland

1 0

upgrade tor bridge raspberry-pi
by jchase 31 Oct '14

31 Oct '14

Hello, On hearing the news that tor 0.2.5.10 was available, I upgraded my raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade restarted the tor daemon automatically. I would have rather done it myself using a restart. When I used arm to look at my new traffic, I noticed that I had been magically turned into an exit relay (besides staying a bridge). My torrc was still intact and clearly stated: ExitPolicy reject *:* I restarted tor by hand and got the same result. I am not interested in having an exit relay. So I turned off the bridge and am waiting for advice from you. rasptorholland

3 2

Choosing to run vanilla or obfuscated bridge
by eliaz 29 Oct '14

29 Oct '14

I know that vanilla bridges cannot carry obfsproxy traffic. But can obfsproxied bridges carry vanilla traffic? If not, are there criteria to help me decide which bridge configuration is useful at any particular time? - eliaz

3 2

exit node experience: abuse over HTTP, stealrat infection
by Kees Goossens 29 Oct '14

29 Oct '14

Dear all, I’ve been running tor non-exit relay freshhumbug at torrelay.nl <http://torrelay.nl/> for about 3 months now. Recently, I tried running it as an exit relay for a week, with following interesting results. Set up: - Ubuntu 14.04 running as VPS with transip.nl <http://transip.nl/>, latest release version of Tor - bandwidth rate set to between 1 MB/s and 2 MB/s - VERY reduced exit policy (listed below) Part 1: Abuse over HTTP. Within one week of being an exit, my provider forwarded the following abuse notification to me (XXXX is the abused Russian website, ZZZZ is me): ==== Greetings, XXXX abuse team like to inform you, that we have had mass bruteforce attempts to the Joomla / WordPress control panel on the our shared-hosting server XXXX from your network, from IP address ZZZZ During the last 30 minutes we recorded 333 attempts like this: XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:49 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-" XXXX - [14/Oct/2014:14:17:51 +0400] "POST /administrator/index.php HTTP/1.1" 200 11646 "-" "-“ XXXX - [14/Oct/2014:14:17:54 +0400] "POST /administrator/index.php HTTP/1.1" 499 0 "-" "-" ==== Lesson (for me at least): since HTTP was used, even a very reduced exit policy is does not make one immune to abuse problems. At this point I reverted back to being a non-exit relay, as I have no interest in having to deal with this. Part 2: Stealrat infection. As part of being an exit relay, I set reverse DNS to this-is-a-tor-exit.torrelay.nl <http://this-is-a-tor-exit.torrelay.nl/>, and I displayed the this-is-a-tor-exit-node.html web page on port 80, using the DirPortFrontPage option. A few days after having shut down my exit, I received notification from my provider that they have been told that my IP address was infected with Stealrat. It hosted a Stealrat PHP file, used to send spam. - http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-site… <http://blog.trendmicro.com/trendlabs-security-intelligence/compromised-site…> - http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white… <http://www.trendmicro.com/cloud-content/us/pdfs/security-intelligence/white…> However, the only thing I do with my VPS is run tor. I don’t run a web site, and don’t have apache or whatever installed. I didn’t investigate much further, but my hypothesis is that when publishing the tor-exit notice on port 80 either tor internally uses a web server or enables a web server that’s present in the system. Either way, that webserver was hacked through a PHP hack. (Note that I received the Stealrat notification only after stopping my exit node. I’m not sure if the Stealrat hack was still active or not. I couldn’t find relevant PHP files on my system.) Since I didn’t want to spend time or effort (figuring out how to) clean my system, I reinstalled ubuntu & tor (only ~40 min work anyway). Lesson (for me): using the DirPortFrontPage option opens up an unexpected web server vulnerability. Perhaps this information is useful for others. With best regards, Kees Relevant parts of the torrc: ORPort 9001 # port used for relaying traffic DirPort 80 # port used for mirroring directory information - not used, since have accountingmax SocksPort 0 # prevents tor from being used as a client RelayBandwidthRate 1000 KB # limit for the bandwidth we'll use to relay RelayBandwidthBurst 10 MB # maximum rate when relaying bursts of traffic BandwidthRate 1000 KB # same as RelayBandwidthRate BandwidthBurst 10 M # same as RelayBandwidthBurst DirPortFrontPage /home/administrator/.arm/this-is-a-tor-exit.html ExitPolicy accept *:20-23 # FTP, SSH, telnet ExitPolicy accept *:43 # WHOIS ExitPolicy accept *:53 # DNS ExitPolicy accept *:79-81 # finger, HTTP ExitPolicy accept *:88 # kerberos ExitPolicy accept *:220 # IMAP3 ExitPolicy accept *:389 # LDAP ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:464 # kpasswd ExitPolicy accept *:531 # IRC/AIM ExitPolicy accept *:543-544 # Kerberos ExitPolicy accept *:554 # RTSP ExitPolicy accept *:563 # NNTP over SSL ExitPolicy accept *:636 # LDAP over SSL ExitPolicy accept *:749 # kerberos ExitPolicy accept *:981 # Remote HTTPS management for firewall ExitPolicy accept *:989-995 # FTP over SSL, Netnews Administration System, telnets, IMAP over SSL, ircs, POP3 over SSL ExitPolicy accept *:1194 # OpenVPN ExitPolicy accept *:1293 # PKT-KRB-IPSec ExitPolicy accept *:1723 # PPTP ExitPolicy accept *:1755 # RTSP ExitPolicy accept *:2086-2087 # GNUnet, ELI ExitPolicy accept *:3690 # SVN ExitPolicy accept *:4321 # RWHOIS ExitPolicy accept *:5222-5223 # XMPP, XMPP over SSL ExitPolicy accept *:5900 # VNC ExitPolicy accept *:6660-6669 # IRC ExitPolicy accept *:6679 # IRC SSL ExitPolicy accept *:6697 # IRC SSL ExitPolicy accept *:8008 # HTTP alternate ExitPolicy accept *:8080 # HTTP Proxies ExitPolicy accept *:8082 # HTTPS Electrum Bitcoin port ExitPolicy accept *:8332-8333 # Bitcoin ExitPolicy accept *:8443 # PCsync HTTPS ExitPolicy accept *:8888 # HTTP Proxies, NewsEDGE ExitPolicy accept *:9418 # git ExitPolicy accept *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy reject *:*

15 29

Re: [tor-relays] How many IOERRORs are common ?
by Mike Patton 29 Oct '14

29 Oct '14

On 29/10/2014 5:23 am, =?ISO-8859-1?Q?Toralf_F=F6rster?= <toralf.foerster(a)gmx.de> wrote: > > Watching the status of a tor-relay (4 MB bandwith, guard + exit, having more than open 1000 connections) with arm shows a rather high frequent amount of connection errors. Nearly every seconds or so a connection can't be established. > > /me just wonders if this is common (replaced ip addresses with <XXXXXX>) > My exit isn't the size of yours but at times has supported quite a bit of traffic and I haven't ever seen one of these errors. Rgds, M.

3 3

exit relay not utilising full capacity (even after months)
by Rejo Zenger 29 Oct '14

29 Oct '14

Hi, I am running an exit-relay and noticed a couple of odd things: 1. Last months, the node seems to be slow in using the full capacity. - Back in April, I changed the relay's configuration to allow the relay to use all the bandwidth it could take. As a result, within a week or two the bandwidth consumption went up to 50 Mbps. In the months of May to July, I had to limit the capacity of the node again. Mid-July I reverted to the same configuration from April. However, the node was a lot slower to pick up the full capacity. [1] - So, the question is: why is it so much slower maximising the full bandwidth? The configuration from mid-July onwards is identical to the one in April. The only thing that has changed is in mid-August, when I moved to relay into a LXC container. However, that doesn't explain the slow pickup in mid-July to mid-August. - And yes, I am aware of the Roger's blogpost. That does explain why the node may be slow to pick up traffic, but it doesn't explain why it was a lot faster in doing so in April then in mid-July. 2. Since Friday there is a considerable drop in the traffic. - Last Friday, around 23:00 hours CET the traffic dropped to about a third of it's usage the days before. Since then, there have been some increase from time to time, but the average is still half or even less than before Friday. There was no change in configuration. I don't have the time to investigate these issues myself. However, if someone wants to look into this, let me know and I am more than happy to provide the details needed. [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-year.png [1] https://rejo.zenger.nl/tmp/94.142.240.243_10-week.png -- Rejo Zenger E rejo(a)zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl T @rejozenger | J rejo(a)zenger.nl OpenPGP 1FBF 7B37 6537 68B1 2532 A4CB 0994 0946 21DB EFD4 XMPP OTR 271A 9186 AFBC 8124 18CF 4BE2 E000 E708 F811 5ACF

2 2

minimal specifications for a non-exit relay?
by René Ladan 29 Oct '14

29 Oct '14

Hi, I was running a non-exit relay from my 50/5 Mb/s (more like 35/4 in practice) home connection on a Raspberry Pi B (496 MB RAM, 700 MHz) running FreeBSD using the following configuration: Tor 0.2.4.24 % cat /usr/local/etc/tor/torrc SocksPort 0 Log notice file /var/log/tor ORPort 9001 ORPort [2001:980:d7ed:1:ba27:ebff:fe96:9eb2]:9001 Nickname ymkeo RelayBandwidthRate 500 KB RelayBandwidthBurst 500 KB ContactInfo Rene <r.c.ladan(a)gmail.com> DirPort 9030 ExitPolicy reject *:* ExitPolicy reject6 *:* This seemed to be fine until last night the socket connection pull ran over, so I increased the value from 128 to 32768 (kern.ipc.somaxconn) Things mostly seemed to be fine again until the kernel ran out of resources later last night: ==> /var/log/tor <== [warn] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 148 buildtimes. ... Oct 29 00:28:44.000 [notice] Performing bandwidth self-test...done. ==> /var/log/messages <== Oct 29 01:15:35 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:15:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:16:30 raspberry-pi last message repeated 36 times Oct 29 01:18:31 raspberry-pi last message repeated 1094 times Oct 29 01:19:30 raspberry-pi last message repeated 450 times Oct 29 01:19:30 raspberry-pi kernel: smsc0: warning: Failed to write register 0x114 Oct 29 01:19:35 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:20:07 raspberry-pi last message repeated 157 times Oct 29 01:20:50 raspberry-pi last message repeated 234 times Oct 29 01:20:50 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:20:52 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:21:37 raspberry-pi last message repeated 216 times Oct 29 01:22:31 raspberry-pi last message repeated 558 times Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: Failed to read register 0x114 Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: MII is busy Oct 29 01:22:31 raspberry-pi kernel: smsc0: warning: failed to create new mbuf ==> /var/log/tor <== Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. Oct 29 01:22:32.000 [warn] Your system clock just jumped 332 seconds forward; assuming established circuits no longer work. ==> /var/log/messages <== Oct 29 01:23:12 raspberry-pi last message repeated 10 times Oct 29 01:25:13 raspberry-pi last message repeated 855 times Oct 29 01:25:51 raspberry-pi last message repeated 123 times Oct 29 01:25:51 raspberry-pi kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached Oct 29 01:25:51 raspberry-pi kernel: smsc0: warning: failed to create new mbuf Oct 29 01:26:21 raspberry-pi last message repeated 222 times Oct 29 01:28:21 raspberry-pi last message repeated 279 times Write failed: Broken pipe <-- local SSH connection dropped It might be a matter of further tuning as ticket #9708 and the new doc/TUNING suggest, once I log in at its console. But if a Raspberry Pi is structurally underpowered (I don't imagine relaying at fiber speed on them ;) ) shouldn't there be something on the homepage or FAQ about this? I have seen at least one blog from someone running a relay on a Raspberry Pi with Debian Linux. Regards, René

1 0

RPM for Tor 0.2.5.10 updated with Curve25519 reenabled
by Ondrej Mikle 28 Oct '14

28 Oct '14

Hi, when switching RPMs from 0.2.4.x to 0.2.5.x branch I forgot to merge re-enabling of Curve25519 (it was a historic artifact of EL5 workarounds). RPM packages of 0.2.5.10 with Curve25519 reenabled are now uploaded and should get to you shortly. Ondrej

2 2

How many IOERRORs are common ?
by Toralf Förster 28 Oct '14

28 Oct '14

Watching the status of a tor-relay (4 MB bandwith, guard + exit, having more than open 1000 connections) with arm shows a rather high frequent amount of connection errors. Nearly every seconds or so a connection can't be established. /me just wonders if this is common (replaced ip addresses with <XXXXXX>) │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $822E5F038D5FE387FC0CDE5DF209ABBD947FD485~Ololosha │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $C29E64C8988A06B4CF67673C7A4B94F5392F03F5~default REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:49631 │ 19:22:17 [ORCONN] STATUS: CLOSED ENDPOINT: $6B939266A97973428AA9224CCFD2F6A38AB49745~BaboxTelecom REASON: IOERROR │ 19:22:17 [ORCONN] STATUS: CONNECTED ENDPOINT: $99B72A7C0980DEAA922B4E3BA576E95E03F558EB~RiotRelay │ 19:22:17 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:57447 │ 19:22:16 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55347 │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $8260ADE00B93448C9CE35780BDBA742AC5E91256~McBoobies REASON: IOERROR │ 19:22:16 [ORCONN] STATUS: CLOSED ENDPOINT: $702491F10EFBE6412F6E93E883F1F586839996F8~1tornetpw REASON: IOERROR │ 19:22:15 [ORCONN] STATUS: CONNECTED ENDPOINT: $A4F3A9B0C54EAB665EA00406CEFBCBE7CB9A0138~bygkjynfyn │ 19:22:14 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:47531 │ 19:22:14 [ORCONN] STATUS: CLOSED ENDPOINT: $1337C0053C46F16F6344426029F58870017B24F9~Unnamed REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D90B107A1907302E43A6A4E6C851A3AA0B42F094~digitaldoge REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $72534C95CFB55F91B764421A1EFFEB421519DE2F~allyourbase REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:55608 │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $BD0D574F70708E96618492E31F516037E857FC39~wazong REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CLOSED ENDPOINT: $D369D86310CBC8FFBE064940B55458C754F1B03C~Kyat1 REASON: IOERROR │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $039003C320D9980E0A740F107A1A9C13C99C5FE3~ry4an │ 19:22:13 [ORCONN] STATUS: CONNECTED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: LAUNCHED ENDPOINT: $5E184FEA02B7C54172BBC757636F501047CF9691~pook0oow │ 19:22:12 [ORCONN] STATUS: NEW ENDPOINT: <XXXXXX>:35274 │ 19:22:12 [ORCONN] STATUS: CLOSED ENDPOINT: $64186650FFE4469EBBE52B644AE543864D32F43C~PsychoOnion3 REASON: DONE ─┘ -- Toralf pgp key: 0076 E94E

1 0

My VPS relay has just been hacked
by Nick Sheppard 27 Oct '14

27 Oct '14

For the last month I've been running a middle relay (no guard flag yet) on a 512 MB VPS provided by Edis.at in Switzerland (4.99 euro per month). The software is Tor 0.2.5.8-rc with obfsproxy 2 and 3 running on up-to-date Debian Wheezy 7.6. I left the iptables at their defaults. Last night Edis suspended my VPS because of a suspected outgoing DDoS attack, and emailed me. I rang their (very helpful) phone support in London and they de-suspended the VPS so I could ssh into it and investigate. ( I told them it was running a tor non-exit relay - that wasn't a problem.) Sure enough the Solus control panel traffic graphs show the tor relay traffic stopping abruptly last night, followed about 40 minutes later by an exponentially increasing spike of outgoing traffic, soon cut off when the VPS was suspended. I ssh'd into the VPS ("last login" showed my own last login, so no problem there) and looked at logs and top. notices.log simply cut off when the tor traffic stopped, but showed nothing unusual before that. The Solus control panel traffic graph started showing (a very small amount of) outgoing traffic as soon as the VPS was de-suspended, so I assumed the malware was still active, and used top. This is typical of what I found. 1 root 20 0 10604 832 700 S ... 0:00.10 init 2 root 20 0 0 0 0 S ... 0:00.00 kthreadd/3277 3 root 20 0 0 0 0 S ... 0:00.00 khelper/3277 1370 root 20 0 36976 660 492 S ... 0:00.38 hxyqbutesc 1400 root 20 0 109m 1616 1188 S ... 0:00.00 rsyslogd 1446 root 20 0 18836 884 680 S ... 0:00.00 cron 1473 root 20 0 49888 1212 608 S ... 0:00.00 sshd 3187 root 20 0 27556 744 504 S ... 0:00.00 vzctl 3188 root 20 0 17808 1968 1500 S ... 0:00.00 bash 5374 root 20 0 21584 1416 1072 R ... 0:00.00 top 5440 root 20 0 6244 536 296 S ... 0:00.00 akcviaxtbl 5443 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5446 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl 5448 root 20 0 6244 536 300 S ... 0:00.00 akcviaxtbl 5449 root 20 0 6244 532 296 S ... 0:00.00 akcviaxtbl There is a strange line near the top for process "hxyqbutesc", which didn't change; and a strange block of lines at the bottom, which changed every second or two. Sometimes it was five similar lines, as above; sometimes it was several block of lines, eg this: 5276 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5277 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5280 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 qscntoweqb 5282 root 20 0 6244 536 300 S 0.0 0.1 0:00.00 qscntoweqb 5283 root 20 0 6244 528 292 S 0.0 0.1 0:00.00 qscntoweqb 5290 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5294 root 20 0 6244 528 300 S 0.0 0.1 0:00.00 saqizxaihz 5295 root 20 0 6244 532 296 S 0.0 0.1 0:00.00 saqizxaihz 5296 root 20 0 6244 524 296 S 0.0 0.1 0:00.00 saqizxaihz 5298 root 20 0 6244 528 296 S 0.0 0.1 0:00.00 saqizxaihz Each block is always 5 lines, and the names (always 10 lower-case letters) seem to be different every time. The blocks change fairly regularly every second or two. I shut the VPS down to stop it doing any more harm, but I didn't delete anything; I can restart it and ssh in again for further investigation if necessary. Eventually I'll have to reinstall everything from scratch, straightforward enough, but what can I do to make sure it doesn't happen again? Would hardening my iptables work? Has anyone else seen this? Nick Sheppard

6 7

tor-relays set on nokia n900
by Franklin 27 Oct '14

27 Oct '14

Hey all My issu not responds?

1 0

Tor 0.2.5.10 is released!
by Nick Mathewson 27 Oct '14

27 Oct '14

Hi, all! I just sent a release announcement to the tor-announce mailing list. If you're not on that mailing list, you should subscribe; it is very low-volume. https://lists.torproject.org/pipermail/tor-announce/2014-October/000096.html Synopsis: There is a new stable out. Some packages are up-to-date, more packages should be up-to-date over the next week. Usually I don't announce a stable till there are packages, but people have been asking me about this one, and I'd rather have an official release announcement than a series of weird rumors. yrs, -- Nick

8 9

Relays alongside firewall
by Jan Nielsen 26 Oct '14

26 Oct '14

Hello. I recently enabled UFW on my relays. I have allowed in all necessary ports that my relay uses. I was looking at the logs and there are plenty of blocked incoming TCP connections. These connections are being blocked because they are attempting connection on ports that I have not opened e.g. 9001. However, the traffic appears to be relay traffic. Is ufw interfering with my relay? Are there additional steps to take when running a relay alongside a firewall? Here is a redacted snippet from my ufw log: Oct 26 15:10:29 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:xx:8a:xx:64:xx:f0:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46331 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:10:32 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cb:xx:xx:xx SRC=202.108.xxx.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=46332 DF PROTO=TCP SPT=49892 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0 Oct 26 15:15:12 [UFW BLOCK] IN=eth0 OUT= MAC=04:01:26:15:5a:01:28:8a:1c:64:cf:xx:xx:xx SRC=60.186.xx1.xx DST=178.62.xxx.xxx LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=19751 DF PROTO=TCP SPT=52502 DPT=34449 WINDOW=5840 RES=0x00 SYN URGP=0

1 0

Iptables dump
by Sebastian Urbach 26 Oct '14

26 Oct '14

Dear list members, I want to offer my iptables dump so that everybody who's interested can use it to fill up the firewall with the "usual suspects". My system basically runs just TOR and SSH, so it's not a big surprise that the file contains almost only ip's which attacked SSH. Iptables is fed by fail2ban and then dumped every hour iptables-save so that this collection is automatically loaded via iptables-persistent after a reboot. I will publish this file just once so that this list is not stressed too much. If there is a certain amount of interest i'm willing to offer the file for download permanently. Please contact me if you are interested in that. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running Tor
by Dan Hanley 26 Oct '14

26 Oct '14

Hi Matt I was in the unusual position where www.bbc.co.uk decided I was not UK resident (I am) and redirected me to www.bbc.com - where none of the links worked for me as that site decided I was UK resident. The BBC did make it clear that they understand Tor relays should not be an issue for them, but that they consider exits to violate their terms of service. It would seem they have stopped discriminating against relays, I doubt they'll ever be exit friendly :-( Dan > > ---------- Forwarded message ---------- > From: Matt Puckey <matt(a)puckey.org> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 25 Oct 2014 18:19:21 +0000 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > Tor > Dan Hanley: > > Looks like the BBC have changed their rules. I am still running a relay, > > but can now access www.bbc.co.uk in a normal fashion. > > > > Still blocked by national lottery, but I'm hopeful that they both use the > > same third party ip checker, and that the next lottery update will fix > the > > issue. > > Progress! > > I cried a little inside when I read, "We have asked our provider to give > us a way of differentiating Tor exit nodes from non-exit relays, to > allow us to block exit nodes only." > > Ugh. > > Did you have trouble reaching www.bbc.co.uk as well as iPlayer? That > would be strange. I haven't seen them block Tor relays & exits simply > getting to www.bbc.co.uk. > > --Matt > > > >

1 0

Re: [tor-relays] My VPS relay has just been hacked
by Libertas 25 Oct '14

25 Oct '14

For what it's worth, there's an operational security document on the Tor wiki: https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity However, that document covers more advanced techniques mostly intended for serious attackers such as government agencies. Others have already mentioned to you the simplest options, which should keep you safe from automated botnet hackers. These include: allow only public key authentication on SSH, use fail2ban or sshguard, update frequently, and don't run anything unnecessary (a torrent client, an HTTP/FTP server). Some relevant links: https://help.ubuntu.com/community/SSH/OpenSSH/Keys (if you're only going to read/do one thing, make it this) https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html#cont… -Libertas

1 0

Note: 0.2.3 is deprecated
by Nick Mathewson 25 Oct '14

25 Oct '14

And please forgive me or sending one more email, please let me call your attention to these bits of the Tor 0.2.5.10 release notes: This release marks end-of-life for Tor 0.2.3.x; those Tor versions have accumulated many known flaws; everyone should upgrade. o Deprecated versions: - Tor 0.2.3.x has reached end-of-life; it has received no patches or attention for some while. If you're still running Tor 0.2.3 on a relay, I'd strongly suggest you upgrade to 0.2.4, or to 0.2.5 as soon as it's available for your operating system. If there's some issue that prevents you from running a more recent version of Tor, please let us know soon so that we can try to address it before 0.2.3 becomes totally obsolete and gets rejected from the network. best wishes, and thanks for running relays! -- Nick

1 0

Oniontip
by Sebastian Urbach 24 Oct '14

24 Oct '14

Dear list members, Since i was the One who asked to put Oniontip on the tor-website (donate section), what is the current discussion status ? -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Re: [tor-relays] Unstable router
by humbletoruser＠Safe-mail.net 23 Oct '14

23 Oct '14

Hello, thank you all for your suggestions. From: Julien ROBIN <julien.robin28(a)free.fr> > Take another well known product from well known trademarks > Linksys, D-Link, Netgear, Sitecom, TP-Link, or something compatible with OpenWRT for example. Okay, I'm going to try a new router. I don't use VoIP or TV-Services. Just a Tor Node and a hidden Service.

1 0

If you've ever run one of the Tor Browser default bridges...
by isis 21 Oct '14

21 Oct '14

...then please have a look at #13504: https://bugs.torproject.org/13504 Thanks! -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Advisory: remote DoS when using Tor with recent OpenSSL versions built with the "no-ssl3" option.
by Nick Mathewson 21 Oct '14

21 Oct '14

Hello, relay operators! There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of openssl is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out). This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it. To tell if your version of openssl was built with 'no-ssl3': run "openssl s_client -ssl3 -connect www.torproject.org:443". If it gives you an output beginning with something like: CONNECTED(00000003) 140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40 140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596: then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts like: unknown option -ssl3 usage: s_client args then you need to upgrade your Tor. === Some questions and answers: Q: Does this affect clients? A: No. Only relays. Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc? A: No. Only those versions. Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option? A: No. Only versions that were built with the "no-ssl3" option are affected. Q: Does the openssl team know? A: Yes. Have a look at this thread. http://marc.info/?l=openssl-dev&m=141357408522028&w=2 . Also, before I saw that thread, I informed them the other day. Q: Does this affect Tor packages? A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected. Q: What can I do to remediate this problem? A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended. Q: What is the potential impact of this bug? A: If a relay is affected by this bug, anybody can make the relay exit remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected. Q: Should we run in circles and freak out? A: Not this time. We should just make sure we fix affected relays. Q: Hey, Nick, you didn't explain this properly! A: Please send a follow-up message that explains it better. :) best wishes, -- Nick

1 1

tor-relays on Nokia N900
by Franklin 20 Oct '14

20 Oct '14

Hi How to set tor-relays on Nokia N900?

1 0

Anonbox Project
by Sven Reissmann 17 Oct '14

17 Oct '14

Hi there, I recently read about the anonbox project [1], a small hardware-router, which allows end-users to connect their whole LAN to the Tor network. The project is on kickstarter at the moment [2]. Has there already been a discussion on how this might affect the performance of the Tor network? Regards, Sven. [1] http://anonabox.com [2] https://www.kickstarter.com/projects/augustgermar/anonabox-a-tor-hardware-r… -- PGP Key: https://0x80.io/pub/files/key.asc PGP Key Fingerprint: 2DF2 79CD 48DD 4D38 F0B6 7557 2E68 D557 49AA 1D99 Note: I'll be transitioning away from this key in the near future.

15 20

Re: [tor-relays] Few questions about relaying
by teor 17 Oct '14

17 Oct '14

Unless you have a specific need to debug tor (hint: you don't), you should remove this line to improve security: DisableDebuggerAttachment 0 And please consider adjusting these lines rather than removing them: RelayBandwidthBurst 25 MBytes RelayBandwidthRate 20 MBytes We've found that relays perform best when given a rate slightly under the capacity of the link. teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… On 12 Oct 2014, at 01:22 , tor-relays-request(a)lists.torproject.org wrote: > Date: Sat, 11 Oct 2014 17:21:51 +0300 > From: s7r <s7r(a)sky-ip.org> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Few questions about relaying > Message-ID: <54393CFF.5030903(a)sky-ip.org> > Content-Type: text/plain; charset=ISO-8859-1 > > Signed PGP part > RelayBandwidthBurst 15 MBytes > RelayBandwidthRate 3 MBytes > ContactInfo QuebecFibe(a)gmail.com - 200Mb dedicated relay > ControlPort 9052 > CookieAuthentication 1 > DataDirectory /home/blaise/.arm/tor_data > DirPort 9030 > DisableDebuggerAttachment 0 > ExitPolicy reject *:* > Log notice file /home/blaise/.arm/tor_log > Nickname QuebecFibe > ORPort 27645 > RunAsDaemon 1 > > > Use this. You are using the latest Tor? > > > On 10/11/2014 5:11 PM, Blaise Gagnon wrote: > > http://pastebin.com/DQ4k7Fzz > > > > 2014-10-11 10:06 GMT-04:00 s7r <s7r(a)sky-ip.org > > <mailto:s7r@sky-ip.org>>: > > > > Can you please copy/paste your entire torrc to a pastebin and > > provide us the link? > > > > It is hibernating only if you use accounting. Provide us your > > entire complete torrc and we will correct it for you if you don't > > have traffic limits on your server. > > > > On 10/11/2014 4:54 PM, Blaise Gagnon wrote: > >> after a few hours, still hibernating, and still wondering why I > >> lost Stable, Guard and Named all at the same time (see atlas > >> graph)... weird. > > > >> 2014-10-11 6:03 GMT-04:00 Blaise Gagnon <quebecfibe(a)gmail.com > >> <mailto:quebecfibe@gmail.com> <mailto:quebecfibe@gmail.com > >> <mailto:quebecfibe@gmail.com>>>: > > > >> no reason for my node to be hibernating, no caps... > > > >> 2014-10-11 3:31 GMT-04:00 Lunar <lunar(a)torproject.org > >> <mailto:lunar@torproject.org> <mailto:lunar@torproject.org > >> <mailto:lunar@torproject.org>>>: > > > >> Blaise Gagnon: > >>> and ... what is "hibernating" ? > > > >> See AccountingMax and related options in tor manpage: > > > >> AccountingMax N > >> bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits|TBytes Never send > >> more than the specified number of bytes in a given accounting > >> period, or receive more than that number in the period. For > >> example, with AccountingMax set to 1 GByte, a server could send > >> 900 MBytes and receive 800 MBytes and continue running. It will > >> only hibernate once one of the two reaches 1 GByte. When the > >> number of bytes gets low, Tor will stop accepting new connections > >> and circuits. When the number of bytes is exhausted, Tor will > >> hibernate until some time in the next accounting period. To > >> prevent all servers from waking at the same time, Tor will also > >> wait until a random point in each period before waking up. If you > >> have bandwidth cost issues, enabling hibernation is preferable to > >> setting a low bandwidth, since it provides users with a > >> collection of fast servers that are up some of the time, which is > >> more useful than a set of slow servers that are always > >> "available". > > > >> -- Lunar <lunar(a)torproject.org <mailto:lunar@torproject.org> > > <mailto:lunar@torproject.org <mailto:lunar@torproject.org>>> > > > >> _______________________________________________ tor-relays > >> mailing list tor-relays(a)lists.torproject.org > >> <mailto:tor-relays@lists.torproject.org> > >> <mailto:tor-relays@lists.torproject.org > > <mailto:tor-relays@lists.torproject.org>> > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > > > > >> _______________________________________________ tor-relays > >> mailing list tor-relays(a)lists.torproject.org > >> <mailto:tor-relays@lists.torproject.org> > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > _______________________________________________ tor-relays mailing > > list tor-relays(a)lists.torproject.org > > <mailto:tor-relays@lists.torproject.org> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > > > _______________________________________________ tor-relays mailing > > list tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > -- > s7r > PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 > PGP Pubkey: http://www.sky-ip.org/s7r@sky-ip.org.asc >

2 1

Unstable router
by humbletoruser＠Safe-mail.net 16 Oct '14

16 Oct '14

Hello guys, I'm hosting a tor relay at home. My router is a Fritz-Box (this one: http://avm.de/service/fritzbox/fritzbox-7362-sl/uebersicht/ ) and the internet connections is really unstable. Frequently the connection breaks. Not only to the internet, also the local network is down till the router reboots. Is there a better solution for routing a DSL connection? A better router or a way to replace the router with the computer running the tor node. Any hint is appreciated. Thanks in advance! Another question: If I'm acessing my side through a .onion address theres no need for ssl/https as the traffic is encrypted anyways, right?

4 3

About TBB downloadings
by Lluís 16 Oct '14

16 Oct '14

In the web page here: https://www.torproject.org/download/download.html.en#warning advises us not to "... open documents downloaded through Tor while online" Many technical manuals and scientific papers are written in pdf format, and I usually read them. So my question is: Is it safe to download them with TBB first and then open them with, say, "Document Viewer" ? Where can I find more information about it ? Lluís, Spain

4 7

Obfuscated bridges and tor-arm
by justaguy 16 Oct '14

16 Oct '14

Does the tor-arm tool display the used BW of the obfuscated bridge or only the normal non obfuscated bridge? -Justaguy

2 1

About bug #13256: "torsocks 1.3 possibly leaks username"
by Pablo Castellano 15 Oct '14

15 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! I reported this bug some weeks ago but I haven't received any answer: https://trac.torproject.org/projects/tor/ticket/13256 I'm bringing it here to discuss it and know your thoughts. Regards, Pablo. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUPxOMAAoJEHj0TzpGP5Gc/9MQAJF2wzKy5DEvKr90RJDSLphF /2HvBGFZyJDhusDKbwPPGujGqSpbv0f5RL2ZBZ7wFXt0TBo95q3LXiwpwux4jThl bn/smPKw6sLRiCs4/mNGlF17yxX35RrhXOiXtu5xk828zRT2qsE2ZaChH81Ynkml IAsidwdh6B3MzFa/vd1rXngoBJZNAoMn2WvVR7vZJAk9ttcCO8qVYocQje/M0QrR xVn1Aw3+Ao436KCdqu6yAjfgr7NLIwGEZI+Q19BNukuQLdOzydixdB9IAUDfXER6 XL0uPO2T6WgzdTGq8tqAc+x5CPkNeeNqRHa9Cx72gVIxdkBAtZfMlv3c1ulYfM0/ FexxuIlsmF4Ei7HsKWf/c7C0bir1wwJhWFrM8hpQHkpOyWAHQWFjaW0x/xuzU/03 Icxf9U/D92C24XmJJrPI4dIS1F2EYdoOWtrd62UacExeuwRhLb4D2FC2VamCjCYq SN9czti8MuS/Jmqq7vNI3wkcZzZ0x5r/ECYncHdC9P3MQN+JfbU5ei0bU0LOQNE/ sNRdERHymNcv5HHQC3NU+gGx4yf56GO9R6natZC78OrXwu2RroCGEjeMhq/pMe5R CG0eZHPN993pY9UdlMivsfrKnH0McZPSJ2b/NnyxLdYfK58s68hM14ypM4VVUrNT z7zgr/qYtLHzj0EWT9Y7 =D6IQ -----END PGP SIGNATURE-----

2 1