Re: [tor-relays] No disk space for new files created by Tor

[Kostas Jakeliunas]

On Sun, Aug 11, 2013 at 1:41 PM, TonyXue  wrote:
>
> [...]
> It seems that I've run out of space. But my VPS comes with 35GB disk
space and it shouldn't be used up so fast. So how to deal with it?
> If I do run out of space,any advice for deleting the old files of Tor?
Are there any files created by Tor are not useful anymore and can be
deleted?

Assuming you're running a *nix system on your VPS, what does running
df -h
say?

Additionally, you can try getting a list of largest directories/files on
your VPS, like so:
sudo -s
cd /
for i in G M K; do du -ah | grep [0-9]$i | sort -nr -k 1; done | head -n
1000 | tac

or just run the latter on your home directory (and don't use sudo in that
case, of course.)

Kostas.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] No disk space for new files created by Tor

[Kostas Jakeliunas]

Huh, curious why it fails to write stuff to disk.

Does doing
echo "something" > tempfile
succeed?

/var/log/tor is hogging diskspace indeed :) perhaps then do
cd /var/log/tor
sudo rm *.gz

then do

du -sh *

to see if there are any remainder large files left there.

On Sun, Aug 11, 2013 at 2:32 PM, TonyXue  wrote:

> Fllowing are the result of *df -h:*
> *
> *
> *
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/xvda1   35G   17G   17G  51% /
> udev235M  4.0K  235M   1% /dev
> tmpfs98M  192K   98M   1% /run
> none5.0M 0  5.0M   0% /run/lock
> none244M 0  244M   0% /run/shm
>
> And seems /var/log/tor takes up 16G.
>
> Tony.
> *
>
> --
> From: kos...@jakeliunas.com
> Date: Sun, 11 Aug 2013 13:57:27 +0300
> To: tor-relays@lists.torproject.org
> Subject: Re: [tor-relays] No disk space for new files created by Tor
>
>
> On Sun, Aug 11, 2013 at 1:41 PM, TonyXue  wrote:
> >
> > [...]
> > It seems that I've run out of space. But my VPS comes with 35GB disk
> space and it shouldn't be used up so fast. So how to deal with it?
> > If I do run out of space,any advice for deleting the old files of Tor?
> Are there any files created by Tor are not useful anymore and can be
> deleted?
>
> Assuming you're running a *nix system on your VPS, what does running
> df -h
> say?
>
> Additionally, you can try getting a list of largest directories/files on
> your VPS, like so:
> sudo -s
> cd /
> for i in G M K; do du -ah | grep [0-9]$i | sort -nr -k 1; done | head -n
> 1000 | tac
>
> or just run the latter on your home directory (and don't use sudo in that
> case, of course.)
>
> Kostas.
>
> ___ tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] No disk space for new files created by Tor

[Kostas Jakeliunas]

On Sun, Aug 11, 2013 at 7:06 PM, Roman Mamedov  wrote:

> On Sun, 11 Aug 2013 14:43:59 +0300
> Kostas Jakeliunas  wrote:
>
> > Huh, curious why it fails to write stuff to disk.
> >
> > Does doing
> > echo "something" > tempfile
> > succeed?
> >
> > /var/log/tor is hogging diskspace indeed :) perhaps then do
> > cd /var/log/tor
> > sudo rm *.gz
>
> Before deleting you should review the log files to find out what exactly is
> happening to Tor, that made it produce so much logs. This shouldn't ever
> happen during normal operation.


That's true. I assumed the juicy stuff would be in notices.log and
notices.log.1, but yes, it would make a lot of sense to review the older
logs as well. Perhaps Tor is not starting up nicely and is constantly
spitting out error messages / warnings.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Planningon running bridge with bw limitation - config help

[Kostas Jakeliunas]

On Tue, Aug 13, 2013 at 2:39 PM, Moritz Bartl  wrote:

> On 13.08.2013 08:02, Kali Tor wrote:
> > I am actually in double minds about using obsproxy. Is there a demand
> for it?
>
> Yes! Please do set up obfsproxy.


Since obfsproxy bridges are usually really low traffic, I think the
combination of an obfsproxy bridge and raspberrypi makes quite a bit of
sense (that's what I'm running in any case, no problems so far (I also had
to compile Tor for armv6 from source)) :)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Raspberry Pi Relay Node Performance and future Plans on Documentation and more

[Kostas Jakeliunas]

On Tue, Aug 13, 2013 at 3:58 PM, Roman Mamedov  wrote:

> On Tue, 13 Aug 2013 12:02:35 +
>  wrote:
>
> > I'm wondering, is there any other method for running a tor
> > bridge/relay on
> > the raspberry pi, other than downloading the source and compiling it
> > yourself?
>
> Raspbian has it in the repositories[1].
>
>   apt-get install tor
>
> Done. No need to build anything from the source.
>

You need Tor 0.2.4.* to run an obfsproxy bridge, which I wanted to do.
Wheezy repo only has 0.2.3.*; 0.2.4.* is only in the experimental Debian
distro repo [1], afaik.

[1]: http://packages.debian.org/experimental/tor
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian

[Kostas Jakeliunas]

Thanks for sharing your experience!

> After the week I decided to shut the bridge down because I heard from
people being contacted by the police even though only running a non-exit
relay.

Do you remember where you did hear this? Was it in writing, are you by
chance maybe able to link to it? It would be interesting to know more.

All non-bridge relays (exit or non-exit) can be enumerated by anyone
(that's by design); this is not the case with bridges. However I suppose
the extent to which any potential efforts to do just that may be happening
does very much depend on the jurisdiction where that bridge is being run;
China's internet censorship / 'firewall' thing seems to have been trying to
enumerate bridges for a while now. [1] In any case, as far as I'm
concerned, it would be *really* interesting to hear of any incidents
between the police and non-exit relay operators.

[1]: https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors


On Tue, Aug 20, 2013 at 2:00 AM, z0rc  wrote:

> Hi,
>
> As lately there were many discussions on getting Tor from the experimental
> repository running on Raspian, I thought I would share my experiences here.
>
> First, I tried to install Tor following [1] and [2] and ran into the same
> compatibility issues as most of you. But then I just downloaded the
> soft-float version of Raspian "wheezy" from [3]. And I could install Tor
> and obsproxy from the experimental repository without any issues (i.e.
> without any compiling or complex configurations).
>
> I ran the obfuscated bridge for a week and it relayed a few 100 MB without
> any problems. The bridge is connected to a standard home cable connection
> in Switzerland (router runs pfSense). Of course the load was not too high
> due to only running an obfuscated bridge.
>
> After the week I decided to shut the bridge down because I heard from
> people being contacted by the police even though only running a non-exit
> relay. As I share a flat with some friends, I absolutely cannot afford
> being raided or similar. If anyone can give me some advice on running
> non-exit relays at home in Switzerland, I might consider running the bridge
> again.
>
> Hope this helps.
>
> Cheers,
>
> Damian
>
>
> [1] https://www.torproject.org/**projects/obfsproxy-debian-**
> instructions.html.en#**instructions
> [2] 
> https://www.torproject.org/**docs/debian.html.en#**development
> [3] 
> http://www.raspberrypi.org/**downloads
> __**_
> tor-relays mailing list
> tor-relays@lists.torproject.**org 
> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Upgrading an obfsbridge to the latest alpha on git master, on raspberry pi

[Kostas Jakeliunas]

A few days ago, George posted an invitation for obfsproxy operators to
upgrade their Tor software to the latest version on the master branch in
the Tor git repo. [1]

I'm running a low traffic obfsbridge on a raspberry pi, the whole thing is
rather experimental in its nature already, so decided to try just that.

Presumably everyone for whom this might be relevant already knows these
things much better than myself, but since they might be applicable to
all/some Debian users (raspberrypi + raspbian/debian users for sure), i'm
outlining a couple of snags that can maybe be avoided. Previously I ran
0.2.4.15-rc compiled from deb-src
(http://deb.torproject.org/torproject.orgexperimental-wheezy main); I
think it'd have been the same if a precompiled
package had been used. I'd still like to be able to manage Tor via init
scripts with as little change as possible, etc.

TL;DR:

   - after make && make install, do a whereis tor; in all likelihood, your
   new version will be at /usr/local/bin/tor, old one at /usr/sbin/tor etc.;
   /etc/init.d/tor will be using /usr/sbin/tor, so need to change the DAEMON
   key there
   - torrc-defaults will have different values in different distro packages.
   cd /usr/local/etc/tor; if there's no torrc there: sudo ln -s
   /etc/tor/torrc (presumably that's where you kept your torrc before;
   ~/.torrc should work in any case)

$ git clone https://git.torproject.org/tor.git && cd tor
$ ./autogen.sh
if it complains about no aclocal (et al.):
$ sudo apt-get install automake && ./autogen.sh
$ ./configure
$ make
$ sudo make install # or, just use it like that (Tor binary is in src/or/)

If you're using service tor {start,stop,reload,etc}:

$ /usr/sbin/tor --version; /usr/local/bin/tor --version
$ grep DAEMON= /etc/init.d/tor

The latter will likely point to /usr/sbin/tor, which might be outdated
(check above).
If that's the case, change that line in init.d/tor to point to the new Tor
executable /usr/local/bin/tor - that's where it *should* be; if you don't
like that, change
BINDIR = /usr/local/bin
in Tor's Makefile and make install again.

The Debian Tor packages seem to like to assume torrc will be placed in
/etc/tor/torrc. If that's where your torrc resides, make a symlink to it
from /usr/local/etc/tor, which is where the new Tor executable will look
for it.

This is probably an insanely ugly way of dealing with these snags, but if
anyone is reserved to upgrade because of things like that, maybe this'll
help someone..

Kostas.

[1]:
https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrading an obfsbridge to the latest alpha on git master, on raspberry pi

[Kostas Jakeliunas]

On Wed, Aug 21, 2013 at 10:35 AM, Peter Palfrader wrote:

> Maybe you should build .deb package from these sources?
>  https://www.torproject.org/docs/debian#source


Ah! debuild && dpkg -i. Yes, that's the cleaner way to do it for sure,
thanks. There's no reason why this shouldn't work with the latest branch, I
guess.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian

[Kostas Jakeliunas]

On Wed, Aug 21, 2013 at 1:58 AM, z0rc  wrote:

>  On 20/08/13 12:01, Kostas Jakeliunas wrote:
>
> Do you remember where you did hear this? Was it in writing, are you by
> chance maybe able to link to it? It would be interesting to know more.
>
>
> Hi,
>
> It was actually on this list a few weeks ago. Paul Staroch was contacted
> by the German authorities for running a non-exit relay [1]. It seems like
> they knew too little about Tor and thought he was providing child
> pornography through his relay as they used it as entry node. So I was
> wondering whether it was possible that some criminal used my bridge to do
> some nasty stuff and when the authorities find him, they will see my IP on
> his PC and come after me? But maybe this is just a little too paranoid. Are
> there any other known incidences like this one?
>
> Damian
>
> [1]
> https://lists.torproject.org/pipermail/tor-relays/2013-August/002365.html
>

Oh, this is interesting (I wasn't yet subscribed to @tor-relays at the time
probably). It seems that these kinds of things might be unavoidable, but
there shouldn't be any trouble after the operator explains / links to
explanations of how Tor works. I think there's much less chance of this
happening if one is running a bridge, since in that case it won't be part
of the public relay list, and it won't be possible to connect to any
.onions through it automatically, without first getting the bridge IP
through one of the bridge pools and deliberately adding it to
Vidalia/wherever (and configuring your Tor to actually use bridges.)

I wouldn't be afraid. (Ideally, operators wouldn't be afraid of some
confrontation in any case - they would kindly explain how Tor works, and
would defend Tor as a tool for empowerment of users, etc.)

Kostas.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] efficiency and reachability

[Kostas Jakeliunas]

On Tue, Aug 27, 2013 at 1:11 PM, That Guy  wrote:

>
> 1) have 4 extra unused devices, 2 android & 2 older laptops running
> Xubuntu & Lubuntu  that can run full time & my 2 primary
> machines(android tab and Debian laptop). With only so much bandwidth,
> what helps best in that situation?
> a. fewer(1-2) devices offering more BW each, or
> b. more(4-7) devices each offering less BW to the network.


Would all these devices be behind a single external IP address (if that
question makes sense)? They'd all be behind the same router (as I take it);
in all probability, that would in most cases mean they'd all share the same
external / WAN IP address.

Is that the case? If yes, you should try and not run more than two Tor
relays behind the same WAN IP. That's because the directory authorities
(which compose and sign lists of relays that Tor user clients then download
to compose circuits of) won't like this, afaik.

In any case, it does kind of matter what's your realistic overall download
and upload throughput / bandwidth.

> 2)

Port forwarding would make the most amount of sense, I guess.

Each of those devices, having Tor instances running on them, will have a
torrc config file. Probably under /etc/tor/torrc, or
/usr/local/etc/tor/torrc (you can also probably use Vidalia for this.) In
that file, there will be a line

#ORPort 9001

You will need to (after uncommenting the line) set different ports in each
of the Tor instances you're running, and then port-forward that same port
(that's the most easy way) to each of the devices. Basically, "external
port" (e.g. 9001) -> forward to local IP of the device in question -> 9001.

Try and set the ORPort to 443 on one of the devices, if possible. (This
might mean you'll have to run Tor as root, or will need to change
capabilities.) In any case, the ports will have to differ, the way I see it.

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] onionoo

[Kostas Jakeliunas]

The usual deal is to just wait a bit more, until your bridge gets voted
into the last consensus. The "running: true/false" field in Onionoo simply
indicates whether your bridge/relay descriptor is listed in the last
consensus (which is published every hour, and includes a list of relays and
bridges which the network authorities agreed on being valid / etc. for
client usage.) It usually takes some time (e.g. more than an hour) even
after your bridge/relay is successfully running. At least that's my
(perhaps oversimplifying) take.

Perhaps you're using it yourself, but one of the ways to probe Onionoo in a
user-friendly way is the new Globe tool [1]. It includes bridges as well as
relays.

[1]: http://globe.rndm.de/

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bad idea to switch from a relay to a bridge?

[Kostas Jakeliunas]

On Thu, Nov 14, 2013 at 4:01 PM, Nick  wrote:

> Hi,
>
> I've been running a very low bandwidth relay for a little while with
> my home ADSL connection, but given the up speed is so poor, and
> (more importantly) my ADSL provider has stopped switching my IP
> about every 24 hours, I'd like to switch to be a bridge.
>
> However, I'm wondering whether the fact that my IP is already known
> as a relay means that it wouldn't be useful? That is, if the people
> bridges try to foil are likely to just blacklist any relays they see
> by default (it wasn't an exit or guard).
>

I think that's a very good question, I've been considering it myself as
well (as it also was at one point relevant to me, when I was running a
relay.) Would be interested to hear opinions.

I would think it's generally OK; I would try and change the nickname of
your Tor server (by 'server' I mean a generic node that can be either a
relay or a bridge.) There are some relays that can be found (when searching
via Onionoo, e.g. using Globe [1]) to be or have been both bridges and
relays. It is questionable whether there are any ISPs / filters / etc. who
might try to use this kind of archive browsing/discovery as one of the
channels for collecting bridge IP addresses, but it's possible in theory at
least. See related ticket. [2]

Thing is, when a bridge has once been a relay (under e.g. the same IP
address), it's possible to see if that address was ever Tor relay at one
point (if it was, some ISPs might use this as enough of a reason/criterion
for censoring out connections.) With current ExoneraTor and relay-search
it's not easy as you have to enter a date / date range etc., but the
information is there in the archives. For example, if you query my new(ish)
python-onionoo tool [3] which can search in most of the archival data
available, it's very easy to see if an IPv4 address was ever part of the
Tor network. [4] I think some discussion on this might be fruitful.

[1]: http://globe.rndm.de/
[2]: https://trac.torproject.org/projects/tor/ticket/5684
[3]: https://github.com/wfn/torsearch (though I need to write up a decent
readme..)
[4]: e.g. http://ts.mkj.lt:/details?search=79.98.25.182
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bad idea to switch from a relay to a bridge?

[Kostas Jakeliunas]

Just to illustrate further, it's really easy to see if an IPv4 address was
*ever* part of the network, e.g. look up current moria1's address:
http://ts.mkj.lt:/details?search=128.31.0.34

So if a bridge was a relay once (under the same ip addr), implementing an
additional check in GFW or wherever would make sense and might be feasible.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running random web services on a bridge-server?

[Kostas Jakeliunas]

On Nov 16, 2013 1:01 PM, "Martin Kepplinger"  wrote:
>
> Hi,
>
> Sorry for being lazy, I'm not sure if I can figure it enirely out
> myself: Is there _any_ implication on the status of a bridge in the Tor
> network when I run random web services like an open website, xmpp
> server, whatever, on the same device/IP? It'll somehow be more exposed
> that way but I'd be happy on any opinion. I guess probability that
> someone finds out that there is a bridge behind my IP is rising.

I really have nothing to back this up but I would *think* that additional
services on the same IP might mask the bridge from / confuse some
active/reactive probing based bridge disovery attacks. Then again, if
active probing is usually only done on a particular (ip, port) pair (the
one that someone in China is connecting to, for example), then there's
probably no difference anyway.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Cloud: still not listed

[Kostas Jakeliunas]

On Wed, Jan 15, 2014 at 3:30 PM, Patrick ZAJDA  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I have set up an Amazon EC2 instance to run a Tor Relay, I chose
> Obfsproxy Bridges.
>
> [...]
>
> The second point is: I looked at the configuration, and noticed bridge
> is set to 1.
> I though it made the tor relay private, do I have miss-understood
> something?
> If I didn't miss-understand, that explains why it is still not listed
> on atlas.torproject.org, and there is a problem with the provided EC2
> image.
>

If your bridge is set to publish its descriptor (should be default), you
might be able to search for it using the new Globe tool:
https://globe.torproject.org/

Regards
Kostas
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Cloud: still not listed

[Kostas Jakeliunas]

On Wed, Jan 15, 2014 at 5:30 PM, Runa A. Sandvik wrote:

> On Wed, Jan 15, 2014 at 3:08 PM, Kostas Jakeliunas
>  wrote:
> > On Wed, Jan 15, 2014 at 3:30 PM, Patrick ZAJDA  wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> Hi all,
> >>
> >> I have set up an Amazon EC2 instance to run a Tor Relay, I chose
> >> Obfsproxy Bridges.
> >>
> >> [...]
> >>
> >>
> >> The second point is: I looked at the configuration, and noticed bridge
> >> is set to 1.
> >> I though it made the tor relay private, do I have miss-understood
> >> something?
> >> If I didn't miss-understand, that explains why it is still not listed
> >> on atlas.torproject.org, and there is a problem with the provided EC2
> >> image.
> >
> >
> > If your bridge is set to publish its descriptor (should be default), you
> > might be able to search for it using the new Globe tool:
> > https://globe.torproject.org/
>
> Good point! I forgot about Globe. It seems
> https://globe.torproject.org/#/search/query=ec2 only lists 43
> currently running bridges, while
> https://metrics.torproject.org/cloudbridges.png lists more than 300.
> Any idea why the numbers are so different?


I haven't checked, but can't the cloud bridge operator change the nickname
(just as any other operator can)?

See e.g. https://globe.torproject.org/#/search/query=cloud (non-zero count
of bridges there, too. Not sure if related, though.)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ExtORPort notice

[Kostas Jakeliunas]

On Sat, Feb 15, 2014 at 6:44 AM, Delton Barnes wrote:

> Upon upgrading obfsproxy to 0.2.6 and Tor to 0.2.5.1-alpha-dev
> (git-f63b394d90583b77+96972c4) for scramblesuit, I got this in the Tor log:
>
> Feb 15 04:40:03.000 [notice] We are a bridge with a pluggable transport
> proxy but the Extended ORPort is disabled. The Extended ORPort helps Tor
> communicate with the pluggable transport proxy. Please enable it using
> the ExtORPort torrc option.
>
> How should this be set?  What does it do?  I saw some web pages
> suggesting "ExtORPort 6699" for statistics-gathering purposes.
>

I personally think there should be some kind of notice (or it should be
more verbose) for obfsproxy bridge operators who are upgrading to the
newest obfsproxy, telling them to enable ExtORPort and so on. That notice
should include instructions how to do this, which is very simple (assuming
obfsproxy bridge operators are already familiar with torrc):

You just need to add one line to your torrc:

ExtORPort 

so for example

ExtORPort 6699

If obfsproxy is already running, it's probably best to then simply restart
tor (vs. just reloading, that is, 'sudo service tor reload' or 'sudo
killall -HUP tor'). Tor will start listening to that port, and will
automatically inform obfsproxy (upon starting it) to use this port for
communication.

> What does it do?

As far as I understand it, ExtORPort tells tor to open a local-only (bound
to localhost) socket for getting information from / communicating with
obfsproxy (the pluggable transport proxy executable); i.e. the only
communication that happens through this port is between tor and obfsproxy.
Information exchanged includes statistics about obfsproxy bridge users
(such as the number of users coming from a specific country and the number
of users per each pluggable transport). Tor then aggregates this data
(rounding up to a number, etc.) in a way that makes sure it is anonymized /
cannot be used by anyone attempting to pinpoint users of this specific
bridge and so on.

You can e.g. look up some statistics that come from this kind of reporting
on the Tor Metrics portal.[1] (the actual numbers are probably
significantly different from what is currently shown; hence the need for
more bridges with ExtORPort enabled.

I may have misunderstood something, though. But in any case, it's best if
you just include a "ExtORPort " line in your torrc - that should
be enough.

[1]: e.g. obfs3 transport users:
https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&start=2013-11-17&end=2014-02-15&transport=obfs3#userstats-bridge-transport

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Port 8118 Traffic?

[Kostas Jakeliunas]

On Tue, Mar 25, 2014 at 3:45 AM, Geoff Down  wrote:

>
>
> On Tue, Mar 25, 2014, at 12:55 AM, Dennis Crawford wrote:
> > Hello -
> >
> >
> >
> > I just recently installed a Tor Relay and now I'm seeing a TON of port
> > 8118
> > denied requests in my log.
> ...
> > Am I doing something wrong?
>
> No, someone out there is sniffing relays for open HTTP proxies - you'll
> find it mentioned in the list archives. If it concerns you, you can
> report it to the originating network, but if your firewall is doing its
> job


Furthermore, this relay is also advertising itself as an exit node, and the
network thinks that it can be used as one:
https://globe.torproject.org/#/relay/541D0AEF5BCA6F2D6285FEC2CF8E87AE9F8771A6(note
the exit policy and the Exit flag.)

Since the intention (as i understand) is not to have it be an actual exit
node, better to have this in the torrc:

ExitPolicy reject *:*

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] "What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"

[Kostas Jakeliunas]

Making a separate thread so as not to pollute the challenger[1] one.

Roger: you wanted to know (times are UTC if anyone cares),

[22:08:35] [...] we now have a list of 1000 fingerprints, and we could
> pretend those are in the challenge and use our graphing/etc plans on them
> [22:08:45] they happen to be the relays vulnerable to our openssl bug
> [22:11:43] "what fraction of the tor network by consensus weight are they?"
> [22:11:49] "over time"


Given them[2], the challenger (with minimal changes to fix downloader and
to make Onionoo not falter)[4] will spit out the following results:

  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json[uh
oh, this one's empty. Why is it empty? Didn't look into it.]
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json


The 'combined-weights.json' is probably the one you might be after. But
that's all I did for now.

You also said that these aren't all the vulnerable relays that there are
out there. You linked to a more complete list[3], but it has some typos,
etc. I haven't done anything with it, maybe someone will take over, or I
will do something later on.

[1]:
https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html
[2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt
[3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b
[4]: commits:
  -
https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188
  -
https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc
  -
https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae

--

kostas / wfn

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?

[Kostas Jakeliunas]

On Tue, Apr 8, 2014 at 12:59 PM, Karsten Loesing wrote:

> On 05/04/14 17:46, Lukas Erlacher wrote:
> > Hello Nikita, Karsten,
> >
> > On 04/05/2014 05:03 PM, Nikita Borisov wrote:
> >> On Sat, Apr 5, 2014 at 3:58 PM, Karsten Loesing
> >>  wrote:
> >>> Installing packages using Python-specific package managers is
> >>> going to make our sysadmins sad, so we should have a very good
> >>> reason for wanting such a package.  In general, we don't need
> >>> the latest and greatest package.  Unless we do.
> >> What about virtualenv? Part of the premise behind it is that you
> >> can configure appropriate packages as a developer / operator
> >> without having to bother sysadmins and making them worried about
> >> system-wide effects.
> >>
> >> - Nikita
> >
> > I was going to mention virtualenv as well, but I have to admit that
> > I find it weird and scary, especially since I haven't found good
> > documentation for it. If there is somebody who is familiar with
> > virtualenv that would probably be the best solution.
>
> I'm afraid I don't know enough about Python or virtualenv.  So far, it
> was almost zero effort for our sysadmins to install a package from the
> repositories and keep that up-to-date.  I'd like to stick with the
> apt-get approach and save the virtualenv approach for situations when
> we really need a package that is not contained in the repositories.
>
> Thanks for the suggestion, though!
>
> > On 04/05/2014 04:58 PM, Karsten Loesing wrote:
> >> My hope with challenger is that it's written quickly, working
> >> quietly for a year, and then disappearing without anybody
> >> noticing.  I'd rather not want to maintain yet another thing.
> >> So, maybe Weather is a better candidate for using onion-py than
> >> challenger.
> >
> > Yes, I understand.
> >
> >> Yeah, I think we'll want to define a maximum lifetime of cache
> >> entries, or the poor cache will explode pretty soon.
> >
> > What usage patterns do we have to expect? Do we want to hit onionoo
> > to check if the cache is still valid for every request, or should
> > we do "hard caching" for several minutes? The best UX solution
> > would be to have a background task that keeps the cache current so
> > user requests can be delivered without hitting onionoo at all.
>
> That's a fine question.  I can see various caching approaches here.
> But I just realize that this is premature optimization.  Let's first
> build the thing and download whatever we need and whenever we need it.
>  And once we know what caching needs we have, let's build the cache.
>
> > In other words, unless we do something intelligent with the cache,
> > the cache is not actually going to be very useful.
>
> Valid point. :)
>
> >> Great, your help would be much appreciated!  Want to send me a
> >> pull request whenever you have something to merge?
> >
> > Will do.
>
> Great.  Thanks!
>

Hi Karsten and others,

I got to run the challenger script by chance[1], and spotted a small
mistake that was preventing Lukas' onion.py downloader code from working.
Ended up forking and creating a separate branch:

https://github.com/wfn/challenger/commits/wfn_fix_luk3s_download

Relevant commits:

  - 38d88bcb1136f97881f81152d3d883c4e9480188[2] (enables downloader)
  - 39c800643c040474402fc62d2a2db75c25889dfc[3] (this is the one with the
small thingie-fix)

(It was a very small thing with the way the 'requests' module
handles/provides json documents.)

I was doing this to be able to give Roger the 'combined-*.json' files for
currently vulnerable (re: openssl) relays (he wanted to see which part of
the combined weight fraction they comprise, etc.)

Fingerprints for those relays are here, fwiw:
http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt (the
original link that Roger gave me was http://fpaste.org/92688/ )
(count: 1024.)

If you download these fingerprints, you can just run `python challenge.py
-f vuln_fingerprints.txt`

(for anyone using virtualenv, you might need to `pip install requests`, and
then things should work. For anyone who's just cloned the thing, everything
should probably work after simply installing the 'requests' python module,
if it's not there. I see that 'python-requests' is available in the repos.)

I guess the code hasn't been tested for those amounts of fingerprints
before. Good news: it works (where 'works' means 'i opened the resulting
files and they contained all those fingerprints, and/or they contained lots
of numbers.') Kinda-bad news: Onionoo doesn't seem to share the enthusiasm,
and hiccups, and spits 502 Proxy Error some time after the lookups for the
first document (combined bandwidth) are made.

My cheap quick hack was to insert time.sleep() here and there:

  - 7425ef6fc00dedf3b2b7f2649e832fb4c93909ae[4]

(cheap hack is cheap, but it worked. Note: takes time to download
everything. Didn't time it yet - sorry.)

For anyone interested, these are the resulting 'combined-*.json' files from
all those fingerprints:

  -
http://ravinesmp.com

Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?

[Kostas Jakeliunas]

On Wed, Apr 9, 2014 at 4:06 AM, Lukas Erlacher  wrote:

> Hi Kostas,
>
> right now, we're coding challenger against what exists in debian wheezy,
> which means version 0.1.2 of the requests lib using the python-requests
> package you mentioned, where response.json is correct, and not
> response.json() to get json content from the response.
>
> I'd recommend that if you want to make your own "grab stuff from onionoo"
> script suite, to work with onion-py[1] . It's very new, very spiffy and
> uses python 3 and the newest requests lib. (full disclosure: It's my baby
> and I'm desperately looking for testers/users, but that should be obvious
> to anyone who read this thread.)
> Alternatively, convince the right people (presumably Karsten and arma)
> that challenger should switch to a more sustainable runtime than "what we
> can get from wheezy's repositories". ;-)
>

A-ha! :) That makes sense. (fwiw, i used pip under virtualenv in wheezy;
requests lib version ancient indeed; such is life. fwiw, convincing wheezy
cavepeople to use what you suggest makes sense. It's a false dichotomy
between 'ensures dependences vs. breaks dependencies.')

So

  - the timeout stuff might be useful to everyone involved; it's rough
  - the 'fix' might be useful for people using old 'requests'
  - your onion-py sounds nice

g'day


> Cheers,
> Luke
>
> [1] https://github.com/duk3luk3/onion-py
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?

[Kostas Jakeliunas]

On Wed, Apr 9, 2014 at 4:18 AM, Kostas Jakeliunas wrote:

> On Wed, Apr 9, 2014 at 4:06 AM, Lukas Erlacher  wrote:
>
>> Hi Kostas,
>>
>> right now, we're coding challenger against what exists in debian wheezy,
>> which means version 0.1.2 of the requests lib using the python-requests
>> package you mentioned, where response.json is correct, and not
>> response.json() to get json content from the response.
>>
>> I'd recommend that if you want to make your own "grab stuff from onionoo"
>> script suite, to work with onion-py[1] . It's very new, very spiffy and
>> uses python 3 and the newest requests lib. (full disclosure: It's my baby
>> and I'm desperately looking for testers/users, but that should be obvious
>> to anyone who read this thread.)
>> Alternatively, convince the right people (presumably Karsten and arma)
>> that challenger should switch to a more sustainable runtime than "what we
>> can get from wheezy's repositories". ;-)
>>
>
> A-ha! :) That makes sense. (fwiw, i used pip under virtualenv in wheezy;
> requests lib version ancient indeed; such is life. fwiw, convincing wheezy
> cavepeople to use what you suggest makes sense. It's a false dichotomy
> between 'ensures dependences vs. breaks dependencies.')
>
> So
>
>   - the timeout stuff might be useful to everyone involved; it's rough
>   - the 'fix' might be useful for people using old 'requests'
>

Actually, I might have that one kind of backwards. So timeout stuff for
everyone (who wants to use things from the
'luk3duk3-onionoo-integration'[2] branch), the 'fix' for *certain* people
(for example, for those using pip.)


>- your onion-py sounds nice
>
> g'day
>
>
>> Cheers,
>> Luke
>>
>> [1] https://github.com/duk3luk3/onion-py
>
>
[2]:
https://github.com/kloesing/challenger/commits/luk3duk3-onionoo-integration
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] "What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"

[Kostas Jakeliunas]

On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas wrote:

> Making a separate thread so as not to pollute the challenger[1] one.
>
> Roger: you wanted to know (times are UTC if anyone cares),
>
>
[22:08:35] [...] we now have a list of 1000 fingerprints, and we could
>> pretend those are in the challenge and use our graphing/etc plans on them
>> [22:08:45] they happen to be the relays vulnerable to our openssl bug
>> [22:11:43] "what fraction of the tor network by consensus weight are
>> they?"
>> [22:11:49] "over time"
>
>
> Given them[2], the challenger (with minimal changes to fix downloader and
> to make Onionoo not falter)[4] will spit out the following results:
>
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json
>   [uh oh, this one's empty. Why is it empty? Didn't look into it.]
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json
>
>
> The 'combined-weights.json' is probably the one you might be after. But
> that's all I did for now.
>
> You also said that these aren't all the vulnerable relays that there are
> out there. You linked to a more complete list[3], but it has some typos,
> etc. I haven't done anything with it, maybe someone will take over, or I
> will do something later on.
>

fwiw, I ran the script for the larger batch of vulnerable relay
fingerprints available[5], and these are the resulting files:

  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-bandwidth.json
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-weights.json
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-clients.json
[empty]
  -
http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-uptime.json

The whole thing (with the sleep delays included) took ~84 minutes to run.

(It may be that Onionoo doesn't know (at least not in a way that allows it
to provide the relevant info here) about the majority of those fingerprints
(?), so not sure if this is useful much, but it can't hurt.)

Okay, I'm probably done running and patching code I'm not familiar with for
the time being. :)



> [1]:
> https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html
> [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt
> [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b
> [4]: commits:
>   -
> https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188
>   -
> https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc
>   -
> https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae
>

[5]: fingerprints ready for challenger:
http://ravinesmp.com/volatile/challenger-stuff/1648_vuln_fingerprints.txt

--

Kostas.

0x0e5dce45 @ pgp.mit.edu
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] "What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"

[Kostas Jakeliunas]

On Wed, Apr 9, 2014 at 3:31 PM, Geri  wrote:

> Hi Guys,
>
> im running also a few guard relays and they are listed in here - but today
> i've patched and restarted all the nodes - so these logs arent actually
> anymore.
> what does it mean, available for challenger?
>

Note that this list is as unofficial as it gets. It's meant more for doing
diagnostic metrics stuff, getting aggregate (publicly available) statistics
about these relays, etc.

'challenger' is just a script meant for somewhat different purposes; it
will eventually produce graphs out of aggregate metrics data:
https://github.com/kloesing/challenger

The vulnerable fingerprints file is now somewhat outdated I'm sure. It's
useful for doing retrospective metrics inquiries ("what part of the network
in terms of bandwidth did the vulnerable relays comprise three days ago?");
don't worry too much (and sorry if the initial email sounded alarm bells,
that was not the intention, at all.)


> another thing: is it a real good idea to post public which ip/ports are
> vulnerable to that openssl bug? in my opinion it is much more getting
> dangerous for those relays being attacked - the information which of the
> relays are still vulnerable should be treatened more carefully to minimally
> get rid of the scriptkiddies trying to attack.
>

The scripts for testing out relays and any kinds of arbitrary web services
are available publicly (see:
https://blog.torproject.org/comment/reply/843/55536 ); this would be a
quintessential instance of 'security through obscurity'; people need to do
their diagnostics. But I agree that providing PoC's all over the place does
not reduce the number of scriptkiddie attacks.


> furthermore - how can i check if my tor nodes are now safe now?
>

If you upgrade your openssl and then restart tor, you're fine. I guess you
can use of them unofficial tools which do not guarantee anything. There's a
python script you might try running,

http://s3.jspenguin.org/ssltest.py
as of now, it says 'access denied', here's a copy:
http://ravinesmp.com/volatile/ssltest.py

Be careful running random scripts from the internet, of course. This whole
thread is not meant to convey things in any kind of official capacity
(quite the opposite.)


> thanks!
>

>
>
>
> 2014-04-09 5:41 GMT+02:00 Kostas Jakeliunas :
>
>>  On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas > > wrote:
>>
>>> Making a separate thread so as not to pollute the challenger[1] one.
>>>
>>> Roger: you wanted to know (times are UTC if anyone cares),
>>>
>>>
>> [22:08:35] [...] we now have a list of 1000 fingerprints, and we could
>>>> pretend those are in the challenge and use our graphing/etc plans on them
>>>> [22:08:45] they happen to be the relays vulnerable to our openssl bug
>>>> [22:11:43] "what fraction of the tor network by consensus weight are
>>>> they?"
>>>> [22:11:49] "over time"
>>>
>>>
>>> Given them[2], the challenger (with minimal changes to fix downloader
>>> and to make Onionoo not falter)[4] will spit out the following results:
>>>
>>>   -
>>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json
>>>   -
>>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json
>>>   -
>>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json
>>>   [uh oh, this one's empty. Why is it empty? Didn't look into it.]
>>>   -
>>> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json
>>>
>>>
>>> The 'combined-weights.json' is probably the one you might be after. But
>>> that's all I did for now.
>>>
>>> You also said that these aren't all the vulnerable relays that there are
>>> out there. You linked to a more complete list[3], but it has some typos,
>>> etc. I haven't done anything with it, maybe someone will take over, or I
>>> will do something later on.
>>>
>>
>> fwiw, I ran the script for the larger batch of vulnerable relay
>> fingerprints available[5], and these are the resulting files:
>>
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-bandwidth.json
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-weights.json
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-clients.json
>>  [empty]
>>   -
>> http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-uptime.json
>>
>&

Re: [tor-relays] "What fraction of the tor network by consensus weight are the openssl-vulnerable relays?"

[Kostas Jakeliunas]

On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas wrote:

> Making a separate thread so as not to pollute the challenger[1] one.
>
> Roger: you wanted to know (times are UTC if anyone cares),
>
> [22:08:35] [...] we now have a list of 1000 fingerprints, and we could
>> pretend those are in the challenge and use our graphing/etc plans on them
>> [22:08:45] they happen to be the relays vulnerable to our openssl bug
>> [22:11:43] "what fraction of the tor network by consensus weight are
>> they?"
>> [22:11:49] "over time"
>
>
> Given them[2], the challenger (with minimal changes to fix downloader and
> to make Onionoo not falter)[4] will spit out the following results:
>
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json[uh
>  oh, this one's empty. Why is it empty? Didn't look into it.]
>   -
> http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json
>
>
> The 'combined-weights.json' is probably the one you might be after. But
> that's all I did for now.
>
> You also said that these aren't all the vulnerable relays that there are
> out there. You linked to a more complete list[3], but it has some typos,
> etc. I haven't done anything with it, maybe someone will take over, or I
> will do something later on.
>

fwiw, this is a beyond-hacky-could-fail quick thing[5] that gives you
fingerprints of relays that were vulnerable in a recent
vulnerable-relay-file[6] (ideally it would pull those vulnerable relays
from some online source) that are in any consensus provided (default is
latest consensus available in Tor Metrics):

http://ravinesmp.com:/

Provide consensus using "/consensus/%Y-%m-%d %H:%M:%S" (standard UTC date
format).

Consensuses are available since ~2008. So e.g. current vulnerable relay
fingerprint list intersected with an older consensus when there were
heartbleeding openssl versions:

http://ravinesmp.com:/consensus/2012-10-20%2016:00:00 ("
http://ravinesmp.com:/consensus/2012-10-20 16:00:00")

There's also a nice concise Nick's script to get the % of network bandwidth
of any given list of relay fingerprints (bandwidth is the one in the
consensus, so parts of it will be self-reported and parts of it will be
measured)[7].

[5]: https://gist.github.com/wfn/11070928
[6]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b
[7]: https://gist.github.com/nmathewson/10309480

[1]:
> https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html
> [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt
> [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b
> [4]: commits:
>   -
> https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188
>   -
> https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc
>   -
> https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays