- tor-relays - lists.torproject.org

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 13 Nov '14

13 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