Re: [tor-relays] Raspberry Pi binary .debs - 0.2.4.21

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Whittleston:
> Glad you think it might be useful - I don't know why I didn't post
> it here when I first wrote it back in January.

It'll see the light of day now for sure!

> I'm happy to release it under the CC-BY-SA license for anyone to
> use and have modified the document accordingly. I agree that it
> would be fantastic to make setting up a middle relay something
> anyone could do without much technical knowledge. Have you
> considered a customised build of Raspian or something similar with
> Tor already included, and some sort of simple setup script?

That's pretty much the idea - eventually we'd like a user to be able
to write their SD card, stick it in the Pi, and use a web app to set
up and (if desired) to monitor the relay.

The project tracker is visible at:
https://www.pivotaltracker.com/s/projects/917796

If you click the 'Icebox' button you'll see some long-range plans.
It's slow going but there are tons of really useful tools that'll make
this a lot easier than it would've been even a couple years ago.

> Let me know where you end up putting the documentation, I'd be
> curious to see what else you are working on :)

Will do!  This (which is pretty much R&D stage until I write design
docs) is what we're focusing on first for Cipollini - it's a daemon
that figures out available bandwidth and attempts to intuit and avoid
congestion - thus, though it has wider potential use, it'll meet one
of the biggest goals of Cipollini - the boxes will never mess with
people's Netflix, and thus they'll leave them plugged in.

https://github.com/gordon-morehouse/peergoggles

Best,
- -Gordon M.

- -- 
http://gordon.morehouse.me/

PGP key: https://twitter.com/gmorehou/status/433481548030300161
Fingerprint: A3D2 D096 C3A7 6960 1138 E326 3FE3 A51A 1EEF FBA3

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTML39AAoJED/jpRoe7/ujFMAIAMEnaPrx8uZuS4prN9mF+p91
2ZCCEhSSjAbM2ffW75t3KUuNWCqKjK2iL/7o2galy/veG1UjLu1pXqqKFsueDskT
oll7Y7vCeQItm6yhFniQwi1yUPyH4yzA2AOPJ2XedbPGam2nrFMJ43PXemLW6Pps
v+tOJdT9BOZPX7p1/ymhzbE1MImPKmz0QLCtjO/xRN54snhl3bh+coXjiy4uMBEr
GS2FqU8gf6zNKPAIYGBWXG+LV41atFPrwVdPP3709H/ZqJzxXxr5fAu76Fy0JzWJ
w1Nb6gOC/scsLCFxmP0NEbsqV23otyjt31J5ssTr90EMbvqzXiBgM/rT7XrN41c=
=jkxn
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Raspberry Pi binary .debs - 0.2.4.21

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi, Chris!

Chris Whittleston:
> Thanks for this Gordon M - just thought I'd add that if it's useful
> for anyone, I threw a Pi Tor (middle) relay setup guide together a
> while ago - you can see it here:
> 
> https://docs.google.com/document/d/1bf_D_j1O-9ckTS9DY8ngIdiFwHta6Q5Uj_5dvOiavCQ/edit?usp=sharing

This
> 
is great documentation.

> If I've omitted anything important - please let me know. I know
> it's long (and goes through some pretty simple stuff), but the idea
> was to make it accessible to people who weren't otherwise likely to
> give setting up a relay a try.

That's the entire ultimate goal of The Cipollini Project - allow
people who aren't super technically sophisticated to *easily* set up
low-power, plug-and-forget Tor relays to bulk up the total
middle-relay capacity of the network in the event of traffic growth,
spikes (Turkey being a small example), and botnets.

Would you be interested in donating or releasing your docs under some
free license (GFDL, appropriate Creative Commons) so they could be
wikified or otherwise made collaboratively editable and presented as
part of, or as an adjunct to, Cipollini?  For now that might mean the
Github wiki, but eventually the project will have its own site so
less-experienced users can do some "one stop shopping" for documentation.

Best,
- -Gordon M.

- -- 
http://gordon.morehouse.me/

PGP key: https://twitter.com/gmorehou/status/433481548030300161
Fingerprint: A3D2 D096 C3A7 6960 1138 E326 3FE3 A51A 1EEF FBA3

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTMKDjAAoJED/jpRoe7/ujpw8IAJedtcuerLsOqTaSQURCAT9F
lp+Bqxk1grvjwiT3E9cFScSsZHafKCPm2wiNOYZsJQzck97WbRrBFjVutE06mD2M
9aT9jmj8/hlcQxaK8Jy8HQSuL2jwW6zX23z7gjmzDjHAPJA6r7nbetM3BXiBMdof
fAkbza+/40YIfCli7RzhFbWbfHHB52tXCB8HolY6EsS8OqMvMnt+A+W5TxWNnrxR
gWEcubaHGLGM4Aw8un7bX4ghMzuo1+kTGU2r7onQ3fb75QXy4mQbXn6hqensReBb
1Vr0uBQuQxJoakeyolgEEcuANfybEVLA0FTy0oG4BYmwKOwCIPJHy4imLmj0EX8=
=A6v6
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Raspberry Pi binary .debs - 0.2.4.21

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Robert,

I:
> Have you evaluated the Riotboard(.org) for your idea of plug in
> Tor relay? It looks like it uses about the same amount of energy as
> the Cubieboard but for a little more money would be a lot more
> capable.

I haven't, but it's mainly because I've been so preoccupied I haven't
been able to keep up with the (delightful) proliferation of these boards.

Eventually, what I want is to have a set of small apps and scripts
such that *any* system with at least 512MB physical RAM and about the
CPU power of a Pi (on the low end) can run a truly plug-and-forget Tor
relay.  I'm dreaming, long term, of everything from the new frontier
of ARM boards to all those doorstop G4 Mac Minis and VIA 'Eden' ITX
boards sitting in closets.

Best,
- -Gordon M.

- -- 
http://gordon.morehouse.me/

PGP key: https://twitter.com/gmorehou/status/433481548030300161
Fingerprint: A3D2 D096 C3A7 6960 1138 E326 3FE3 A51A 1EEF FBA3
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTMKGjAAoJED/jpRoe7/ujtA4H/0OqXPuLxbWl34jqEgWZmLCI
57Aya5qVljn0Wi/Spxk1x6QoL3lObAp5Yp1e066ZqjyixBpnJ0/TMrrgdY+vj0BD
0rTftv/zRZsdXZXlHVK83Uj2YWKtVLNpR6Arc5cAXNwjM9WFSh+WOmEvvBzVdJmM
xDRmdJt+klJUW4blvLAsZicz5HYNNI6orMAkjmOuoudcaRm6IwZVoI7AvjlhcPsd
tHEch4ApT0EUgahNSqW566tDALIUPM4CfR2i8kGwehCdWm3NOkA9BpFa7V37gdji
P4zm4b+nKLtK1Ry3kM3fTy4FZHcNXEMLXrG720BDvWO1ZSB3rTwVpPuomDGcSJg=
=bBTf
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Raspberry Pi binary .debs - 0.2.4.21

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello all,

I've finally released[1] signed binary .debs for Tor 0.2.4.21 for
Raspberry Pi.  All the usual "random dude's binaries" apply, but at
least these are signed with my PGP key and distributed with hashes.
They're really for temporary Pi testing or convenience, be paranoid
and build from source following the procedure alluded to in the
project README.

Check the Cipollini Project README[2] for more information about the
(very nascent) project.

Best,
- -Gordon M.

1.
https://github.com/gordon-morehouse/cipollini/tree/master/raspbian_packages/tor-0.2.4.21

2. https://github.com/gordon-morehouse/cipollini

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTLg/MAAoJED/jpRoe7/ujO+8H/3c3RJzsYEtWq8/BJcwnW0nP
awxBU3Lb0iAt9JNOw7zcdtA6WdC6eIHgKYZ0nH7Vwc4+bHn/RGyvLrD4n11pgB2I
eKz2ikQXSWb5jqNQD7sCwQeh5drLxH0VMedOtirpMlqyUteKJOMQfbxmDRA5MBtN
KXSSsbKxatnnVA/3/9GFO8oLDEfA0IXp5/RN4bjXDqzW9jHJfC7LVRxq8LK3RRif
MYTuzNV3e8CQ9+q5fyqgCBPLA7OBIhH+wVKOVwU/RLlyQTRUqtV9b9Fe7CXXj5eZ
YgUgZeNVQZ3gBtSuWWuVHGPu+ZKskSvVKu8Gcj71XCnu6LfI+3DyRWmhCXRU5i4=
=yTek
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andreas Krey:
> On Tue, 18 Feb 2014 22:02:21 +, Zenaan Harkness wrote:
>> My tor logs (running on Debian) are showing this warning: [WARN]
>> Your system clock just jumped 100 seconds forward; assuming 
>> established circuits no longer work.
> 
> It may just be that your machine completely hangs for a while 
> occasionally; that will look to tor like a clock jump in that 
> direction. Either hard disk timeouts of some kind, or serious 
> swapping. If VM then also possibly the entire VM being starved 
> occasionally.

This is the case with older versions of Tor (I haven't been active as
much recently, sadly) on the Raspberry Pi.  When the Pi gets
overloaded, Tor thinks there are clock jumps.

Best,
- -Gordon M.



-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJTBsoWAAoJED/jpRoe7/ujGIoIALuGntLCZrRKvXBQKKwg+mJQ
K0NwwGKWDOr62ZC6viAD1G41sTMWSlJjzPx4A3mkzC0fEkwGi6fucaTPMrIrOmTj
W79KoDZVmYQ5T/jmGA+uMV69Hvs+/OfzfYxZF7pgb02KN+nbEV+kykeNNpmPzQtG
znqgdurc75SHbxLh2EYs8hJ+uyRlVTOM1RKDD0TlybCFDfB1Iuie2WCrNnaPqWJM
cQeLMByz8vijyXH+x2LWlJ/gVt2wOUoMKQ2eWdwX0jTqKcedjHoY3OEq+xjOitrW
eKMaqpyG6XWPAElZXaYCBx0+PejaWGLB6Qp9OXKfix1XIIFW7GMe3r/tWKoFb+I=
=iq0R
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Hidden Service web design to speed load times

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey folks,

I've been off the list for quite a long time due to personal reasons,
and I'm aware I have a couple irons still in the fire WRT RasPi and
the SYN flood stuff - I'll get to it.

Today, though, I came across this article:

http://csswizardry.com/2013/01/front-end-performance-for-web-designers-and-front-end-developers/#section:dns-prefetching

tl;dr you can add a 'dns-prefetch' link tag in the HEAD of HTML
documents to do DNS lookups ASAP, instead of later on when the browser
parses the content which does it, or your Javascript (yeah, I know)
does it, etc.

I'm wondering if this would have any value for Tor hidden services -
would a "DNS lookup" of a .onion force Tor to start building a circuit
to the hidden service in question?

I suppose one could deliberately request a nonexistent file or a 1x1
pixel PNG or something, too, to get the circuit built, but this is
obviously a little cleaner and probably a little better for privacy
versus an HTTP request which may be logged even if the user never
takes an action to *actually* request real info.

Just a thought for hidden service operations.  It's always easier to
get one's message out the less time it takes to load.

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSztxfAAoJED/jpRoe7/ujrx8IAJyREaH6TZ2z5GjBPrZfZcir
fWi5zfwO/t/we/uQzn0IriM8DIMvLQOHS1Z9ly/qzUyoBLPRxzUqPpkzmtzXgXOy
l2bAhmRCSyGZXDgE4GAXpVXP8w2w3fb7ijJADqy+I/nqQYZX7MMzlcT8hlsqqon9
I39ITwbDoUuem+y/XG/IICcbTVBsrH3m2auhRBfHawAJW8iO6xooltyUS6JExxLB
fALfaG64YOy8mv+eyOT4tYoP67r8miEDlmTnplARUKw458lihqlnZ1TrCN+AVaJt
OJCXiDnqghvBAJE+v/5JWJOMDr90ucI/+9mitOmbbQh03JOSRsSryeffPmUN08c=
=gl1d
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Travis Northrup:
> Yes, it can. The program can spend the processor time to run that
> extra instruction set. Do we actually need or want that? Would it
> be worth spending the cpu time in exchange for just a miniscule
> effort to do it ourselves?

Are you really arguing something like 1000 cycles on a modern
processor (so, what, a microsecond, tops) vs 5 minutes of human effort?

Is this maybe an example of why crypto software UX is almost
universally god-awful?

Best,
- -Gordon M.

> On Tuesday, November 26, 2013 3:53:25 PM, Gordon Morehouse wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
> 
>> Travis Northrup:
>>> 
>>> 
>>>> This argument (Mbit/s versus GiB/month) reminds me of the
>>>> old saw about the most useless unit of velocity
>>>> (furlongs/fortnight instead of m/sec).
>>> 
>>>> Mick
>>> 
>>> I know exactly what you mean. Personally, I consider any change
>>> to be a convenience modification only. In reality the only
>>> current differences are in defining storage rate and traffic
>>> rate (1024/1000 respectively) and its defined in bits. From
>>> there all conversions are simple math that should be operator 
>>> responsibility.
> 
>> Why, when the config file can be liberal in what it accepts in
>> the numerator, and in the denominator (seconds, days, weeks, mean
>> months)?
> 
>> Calculating numbers is a job for a computer.
> 
>> Best, - -Gordon M.
>> 

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

- -- 
Sent from my thing that sends email.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSm+Y+AAoJED/jpRoe7/ujPRYH/1agvqhrhhk7/uqNr9oEW+Wi
A7fJ2Z6Dt/j+b1A9ty05regLN5q+4t9JE5A492j146v8aJEcZoAWU6718ug8n1Kq
wzX0t5oWl36UivFr99pVvKTf1YHEQ9BCx4S88bbkUn6IvYFv/z8n4o+Kw2dutYDO
Zgl0NGaPrc5IgAglGv6p2Kjc9TON8bkIYJENkbaW58kVEeCad9Sel3i2ZDrC7E2R
WJw8E51n472HpbYbCu5L/zuijzjxpYdjI0Nu3KI3Qci9Uozkpgq2N7bo3n2rzYMI
ufwSnyqAwQLH1ZCkYhYVbR4uEuNRGP2/sAUXrKdhYVNE6c3MsCY/Zm51nnDzHX4=
=GzbJ
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Travis Northrup:
> 
> 
>> This argument (Mbit/s versus GiB/month) reminds me of the old
>> saw about the most useless unit of velocity (furlongs/fortnight
>> instead of m/sec).
> 
>> Mick
> 
> I know exactly what you mean. Personally, I consider any change to
> be a convenience modification only. In reality the only current 
> differences are in defining storage rate and traffic rate
> (1024/1000 respectively) and its defined in bits. From there all
> conversions are simple math that should be operator
> responsibility.

Why, when the config file can be liberal in what it accepts in the
numerator, and in the denominator (seconds, days, weeks, mean months)?

Calculating numbers is a job for a computer.

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSlRhVAAoJED/jpRoe7/ujzC0IANGMKvdbnvOO9lebNa81ETo9
6st2Dyt8Cy3qVmWevVT3JP6GZIpLVAk4M5SeFUm3abY2kbphIJfnnKVGYR/B3ggI
5uVTUN5uFIZmePAoMxHh53Y9ss5IYizvFFli3jaeg7iJnYjQl6zeogBCp275YCR0
tbNeZ4BisXzXUDavTm5c23x0d9fo7z7b7i+SMhPs3DanZG3JLPHtTX+aYiBRjRlY
hZJE9K6i+cvYEEId24tqo/uymEw8BFeCj5Ws32Gj9fHXSn64JDUaEawmmTXXsfvA
DTUGLbRAVfdRDWrQl9JXTZLswMkis5SrrTeoehwo93cjgvl5z7uBa6/rK9WxwzY=
=MdoA
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Your system clock just jumped

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jobiwan Kenobi:
> I've been running a relay for about  months now. It runs on an 1.6 
> Ghz single core Atom with hyperthreading, 1GB of RAM. It's on my 
> home connection; I advertise only 176 KB/sec.
> 
> Under normal conditions, it pumps around 100KB/sec, it has around 
> 600 connections, it uses around 20% CPU. Everything looks very 
> healthy.
> 
> Lately I have seen a couple of incidents where the number of 
> connections suddenly goes up to over 3000, traffic increases 
> heavily, CPU usage goes well over 150% (out of possible 200). 
> Traffic can go up to between 500 and 1000 KB/sec for long periods 
> of time. Sometimes it seems that my relay just can't take it 
> anymore. In the log, the ratio of TAP handshakes goes wild, and I 
> get clock jump warnings. My clock does not jump. This is Tor 
> hanging while allocating memory.

Welcome to the world of the Raspberry Pi / BeagleBone / CubieBoard
operator, except normally we'd have crashed (without some defenseive
measures) before the clock jump thing - the Pi in particular has a
known dodgy "clock."

> Today I had a really bad episode, where the box started thrashing. 
> When it became responsive again, Tor was left in a state where it 
> was constantly downloading about 400KB/sec more than it was 
> uploading. Normally I have a little bit more up than down, because 
> I'm a directory server as well. I can not explain having a lot
> more down than up. I can fantasize that those hangs/clock jumps 
> ("assuming established circuits no longer work") could leave
> 'half' circuits.

As best I can tell, probably that's a flood of incoming TAP requests
or TLS handshakes.

> Finally I restarted my relay, (which I really don't like to do)
> and after a while it stabilized. At this point, my router shows a
> peak of almost 8000 NAT sessions.
> 
> Is this normal behavior of the network (esp. the sudden increase
> in connections) or is this another kind of attack/probe like what 
> we've seen in early September? Is this because this machine is
> just too underpowered? Should I collect/provide any diagnostics?
> Have others seen similar events?

Have a look at the Raspberry Pi threads and search for "circuit
creation storms."  I'm slowly developing a set of defensive iptables
rules for low-power relays which you might want to have a look at, but
as your machine is far more capable than a Pi, you'll need to adjust
accordingly (and then, I hope, contribute back!)

https://github.com/gordon-morehouse/cipollini/tree/master/contrib/90_slowboards/tcp_syn_limit

(Ignore the fail2ban stuff for now, I found a more efficient way to
handle the problem with the help of a list reader.)


> Nov 16 22:39:52.000 [notice] Heartbeat: Tor's uptime is 36 days 
> 6:00 hours, with 615 circuits open. I've sent 192.16 GB and 
> received 171.74 GB. Nov 16 22:39:52.000 [notice] Average packaged 
> cell fullness: 87.305% Nov 16 22:39:52.000 [notice] TLS write 
> overhead: 9% Nov 16 23:39:28.000 [notice] Circuit handshake stats 
> since last time: 6011/6013 TAP, 35/35 NTor. Nov 17 00:39:28.000 
> [notice] Circuit handshake stats since last time: 12521/12521 TAP, 
> 47/47 NTor. Nov 17 01:24:45.000 [warn] Your system clock just 
> jumped 138 seconds forward; assuming established circuits no
> longer work. Nov 17 01:39:28.000 [notice] Circuit handshake stats
> since last time: 49689/1454481 TAP, 51/51 NTor. Nov 17
> 02:28:44.000 [warn] Your system clock just jumped 174 seconds
> forward; assuming established circuits no longer work. Nov 17
> 02:33:12.000 [warn] Your system clock just jumped 268 seconds
> forward; assuming established circuits no longer work. Nov 17
> 02:35:17.000 [warn] Your system clock just jumped 125 seconds
> forward; assuming established circuits no longer work. Nov 17
> 02:39:28.000 [notice] Circuit handshake stats since last time:
> 55822/3477278 TAP, 37/37 NTor.
> 
> 
> Nov 25 06:53:31.000 [notice] Circuit handshake stats since last 
> time: 28194/28200 TAP, 32/32 NTor. Nov 25 07:29:57.000 [warn] Your 
> system clock just jumped 114 seconds forward; assuming established 
> circuits no longer work. Nov 25 07:31:58.000 [warn] Your system 
> clock just jumped 121 seconds forward; assuming established 
> circuits no longer work. Nov 25 07:53:31.000 [notice] Circuit 
> handshake stats since last time: 24207/2692265 TAP, 42/42 NTor.
> Nov 25 08:53:31.000 [notice] Circuit handshake stats since last
> time: 76451/4271579 TAP, 49/49 NTor. Nov 25 09:53:31.000 [notice]
> Circuit handshake stats since last time: 84956/3666170 TAP, 42/42
> NTor. Nov 25 10:45:15.000 [warn] Your system clock just jumped 302
> seconds forward; assuming est

Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roger Dingledine:
> On Sat, Nov 23, 2013 at 02:29:04PM -0800, Gordon Morehouse wrote:
>> Lunar:
>>> Gordon Morehouse:
>>>> Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the
>>>> config file?
>>> 
>>> That would be #9214 [1], implemented by CharlieB, shipped
>>> since tor 0.2.5.1-alpha.
>>> 
>>> [1] https://bugs.torproject.org/9214
>> 
>> Good, this is the most sensical behavior to the widest array of
>> people who type things into config files
> 
> Actually, this is alas not the case.
> 
> We now support gbits (1<<27) and gbytes (1<<30) in the torrc file,
> but we do not support "gib". Or I think more correctly, we say
> gbytes for what you want us to call gibs, and if you want to say a
> billion bytes, you need to type all the zeros.

I learned about the 'gib, kib' etc in wikipedia a while back - it'd be
best if the config file were extremely liberal in accepting what
people type, IMO.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSk5cgAAoJED/jpRoe7/ujt8IH/2ipNB52tIcxQtF9U7bw+ThN
aYim2upAF4bluDcsgYia29FgtwKW8LkFwlBH06qG0DVcifprlkfzR3iZGIfTOGE2
m1cfLkEqRvF7nF5H9ajfIwBnvgrf3stmIBMsjMhFwo1iaRWoD/qPtd14wKVWk+xH
skK48fNcCI0nCep0rBHKwC593QUVv++soNi+aLhuOOGXR0raA/hVt/nms0D4v/pZ
FEdsJfK8BOxrS43JpuQVR8AbUdbnJGs1HQ35T3HmyRoMdDj2ulQ8G9fYIG0w7u2P
cXM9+5BhfMx5M2y1YI+3t9WFBJhZO3Kwzz2X/OSOwt1vfWHcwQ1KVBrRRgGg79A=
=j66M
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Lunar:
> Gordon Morehouse:
>> Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config
>> file?
> 
> That would be #9214 [1], implemented by CharlieB, shipped since
> tor 0.2.5.1-alpha.
> 
> [1] https://bugs.torproject.org/9214

Good, this is the most sensical behavior to the widest array of people
who type things into config files, and the ability to type GiB/mo and
have it mean a line rate will be nice for those of us who, thank you
very much, do make up an important part of the peanut gallery on VPS
providers.

Centralization is death.  I'm glad we're here.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSkSwvAAoJED/jpRoe7/ujxvYIALDaDKZKA8vWXh9aJZycZjNc
3qHQVMwn96Nocl6vmFqhbB2VvpgfAkRb5+MPpZjX5UeXZ4kLcoQh14SsXXvcC2xc
HUi8/IF5a1eYUtsOGAz/+Rde0Xdhvkbf3LG7iJGoY0kX94GI4LG04uVN3j8NsKQv
2XUy3z7ifkSj+AAHwdDtVDP3eX7XZ0Nogo+x0q18Y+ZhW6JAtTncPQvojalGpNYw
qbgVLOKvzJPX8LSokfE6NNR/asjioz5K27ueodrjnlps9s3VrEDc5Xo+tush1nqm
zEd0TVZlS20xIqFTFiqqOoucM8jH35XfSv4EUSoLm5yUPwadMJND/Xm+L5wl62U=
=q9T8
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] (untrusted) Raspberry Pi binary .deb packages for Tor 0.2.4.18-rc

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've built Tor 0.2.4.18-rc for the Raspberry Pi and released
unofficial packages[1].  They are signed with my GPG key, but as
always, if you don't trust binary packages from some dude on the
internet, please see the instructions to compile them for yourself[1].

1.
https://github.com/gordon-morehouse/cipollini/tree/master/raspbian_packages/tor-0.2.4.18-rc
2. https://www.torproject.org/docs/debian.html.en#source

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSj5ghAAoJED/jpRoe7/ujpugIAL8U1aGVZQ4FSqCgRac0g4oW
pqEGYT/aHI7GYX1J0ruS5kSjB7VGBqqskvb3LmWkSjMbJwX7MqTLbfUBj/wX8db8
sHTH/cdFNin3qazjrMnS0fe6bJ/AlimPcQSQfeEPQ3w5Wqk2Lb/qxVEY0cGxwYDn
p6P4KItegJkWcT7pKHCcIkLcjUHjalS4N9xUOg0oFh1cXzA4YRrMbrmHuNuNYtOG
OV09+56jlOJm6ApsYHNiDO/3lYB8xPnaMs8EbOVWUjBsh0kraTusXvNs9IquZEXd
Pk83VhavdsiAmksz5u6q7+gVIXsBkwxTBlpybj5aWNOwze2D4DNe/eBKVzLTu2w=
=7g1s
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

krishna e bera:
> On 13-11-18 07:28 PM, grarpamp wrote:
>> A proper IEC gibibyte = GiB = 2^30 = 1024^3 = 1073741824 for data
>> storage, ram (binary bit handling) A proper SI gigabyte = GB =
>> 1E9 = 1000^3 = 10 for data transmission (packet counting,
>> rocketships)
>> 
>> https://en.wikipedia.org/wiki/Binary_prefix 
>> https://en.wikipedia.org/wiki/ISO/IEC_8 
>> http://www.swedeteam.com/kibi/
>> 
>> Thugh they may break your broken tradition, there are current
>> standards now, please use them.
> 
> The tradition may be broken but it has roots, just as feet and
> inches and acres came from real human practices.  Some of us "grew
> up with" that stuff and it is going to be a pain to unlearn, for
> example, that a KB is 1024 bytes.  Indeed this is the first i heard
> that anyone changed the definitions.
> 
> Anyway, as long as Tor docs are clear what definitions are being
> used i think we can all get along fine.  Suggest we add reference
> URLs to Tor docs.

Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file?

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSj5FKAAoJED/jpRoe7/ujtaIIAJwXML8D3JVW9t3+dHkjWZaY
+KL1sPAsJqcurlISkm2W0Mlw1wrmMAiwoK5ZfJ9kyfxBD4pA/8AOocDpLgqUCzwi
IREGIkzMLLOgJYBizPb5g5I9KWuC7gpWg5EXUuOpuHAfBvuLD6faMQ+G+l4D0yRk
Ik7D/Hw5K4aOm2/U8j1n/3FASkKLJa9k+5Y1rsLM4UaRkLoQunRURnWy31Ui4mab
bUXIQi+OWkhCRUOeX004BRVRxj5/cBQDvaM1qcpvH6R0Kj9YI2Tjp8XumrQgdzCY
k+aM8Av+agvSzQVQCn67lFbD8u4qnzDqDsru+0FUMdQlS/UQQo4emWAVtT8vGUQ=
=+lx/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit nodes on a Gandi VPS

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Eric van der Vlist:
> Hi list,
> 
> I am a (happy) Gandi customer and I'd like to support the Tor
> project by setting up an exit node on one of their VPS 
> (https://www.gandi.net/hosting/iaas).

I left GANDI with my relay node because of their new bandwidth caps.
Mind the bandwidth, unless you have the money to pay for it.

> As mentioned on the list of Good/bad ISPs, 
> (https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs
> Gandi does accept Tor exit nodes. I have contacted their technical
> support who said they did support the Tor project but wouldn't ne
> able to do specific ARIN declarations and that it would be my
> responsibility to be reactive to abuse complaints.
> 
> Despite this perspective (and Julien Robin's bad experience) I am
> still willing to give it a try.
> 
> Gandi have data centers in Paris (France), Luxembourg and Baltimore
> (US) that I can use with the same cost and efforts and I am
> wondering which of these locations would be more useful for the
> community.

I would avoid the United States like the plague when it comes to exit
nodes, but that's just me.  France is kind of iffy on free speech.
Luxembourg, I have no idea - that's new since I left.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJShki1AAoJED/jpRoe7/uj36YH/37ojA3VAYcItK1m3H/DXTzf
Vl2Wei86fMPA7/fKLwxle3I5UGA1YkJc6qsMwI00YJNlat6zTYCVdl1qC22jiuuO
7jIbAML2+SaMJIHx0mT3lSqO+R0j2VIxPwnbKjT3Wyaa/6lmFSf18PryXYbY007F
zmOmAUmakHtHQCey7oIOvIbC3MzieJGzQ22yA3FI0HQORd53x3F/nbM0FtVgixSH
QMJnIsMoTp32Q6JM/5QacGgQfbBph/zEHYc/cw84xSKKIDfG2DicmKcrW1pbn1OD
I4gg68QutbKEKk2zwbLL+FRsW+qnYeJWtsIVVhXrzIvIfVhNTj63Vh8qhLbsNr4=
=D2IT
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay in Russia

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roman Mamedov:
> On Fri, 15 Nov 2013 10:40:16 +0100 jj tor 
> wrote:
> 
>> Hi, list readers,
>> 
>> Someone has experience with russian tor relays?
>> 
>> Do you know of any legal problem for an exit relay ?
> 
> Hello,
> 
> A significant number of websites is blocked in Russia:
> 
> https://en.wikipedia.org/wiki/Russian_Internet_blacklist
> 
> Most Russian exit relays are technically BadExits. So better just
> don't. Makes about as much sense as running and exit node in
> China.

If you agree with the above, a big non-exit relay in Russia and/or
several bridges might help.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJShkkFAAoJED/jpRoe7/uj/ocIALUOpCpNBQz3XoNMSFo+zIwK
TK3YVneRDDykcjQgXwQ0EZCny08BSQL9RD6tj9OvXBFUhfwWkSXqQZRZyu3dY8tE
/yiqjoWOhhh5inWMwP6z8cRZH78ofXTQIW0zkvoaMD7sEk4js7RU7GLtuFMTyx1i
uYFmSESQjmui9uCGgCky2Disdvsr0KjS026hmZBZZ7cMIBVqheZ1UgpL8garflgV
GbcbErDDNUzrV3sRJMmTMNoZMV6vWszGnw8td2H8zEoFUZlRcx5XK5g5YePzQtEN
UeDiOsyHOL3q7JrpsjNGm8cgwF2ML8EqwLF8bovYoZNY3LQUSRGWSceqUmhJiH4=
=o3JJ
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Lars Noodén:
> On 11/06/2013 01:26 PM, mick wrote:
>> I disagree. Dropping all traffic other than that which is 
>> explicitly required is IMHO a better practice. (And how do you
>> know in advance which ports get attacked?)
> 
> Using reject instead of drop simplifies troubleshooting.
> 
> http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject
> 
> Drop tends to get in the way.

I agree with the above document, but on really low-end hardware (hi,
I'm the resident Raspberry Pi person ;)), and with consumer routers,
REJECT can also cause problems during a Tor SYN flood by consuming
resources on both the relay and the router.

Since I *do* agree with REJECTing when possible, I do a two-stage
approach and only DROP hosts which have proven themselves more
aggressive than I can deal with during an overload condition.  This
saves some resources to keep the relay alive.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSfHf6AAoJED/jpRoe7/ujyfQH/AyCj4Jh0fhOQn3nRFKibofL
C0v7cJ3pzbgQCjaeBGwdCz+EDE4/aJaU4MOFAkv+HnMJbGGu9CpgQms+GVpY3P3T
H2tmev4vNQ3dLeylRPlSa/fsXUzQxsGOFSnSMc0FD6tNQGVYljKwRGsLtM0olNee
GN8GXLuLuYtoq25gF9ElAoUkDkHPHj5/R2f/3R7czY6S3SxkQs+V2rQ/uXb8VLBj
eMNCen+kNU5fhi5MhUcixkgd7ovl8599XUnWlgeEuSzjMsWhJHjv0AfmU9eEEtIJ
Sr1jY5ihgOp33ImRBr4/fuzndFI9oSTqChL8eg4ikHxsn8odQvdI9w5cflm4s8I=
=IMno
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] exit and skype

[Gordon Morehouse]

On Tue, 05 Nov 2013 12:04:56 -0800, Zack Becker  wrote:

> I would recomend against google hangouts(even though its more widely 
> used) because google isn't private

I'll say!  Quite rather the opposite of private in all senses!

Recovering Google services addict,
Gordon M.


> 
> 
> On 11/5/2013 11:59 AM, Ryan Winner wrote:
> > Use Google Hangouts.
> >
> >
> > On Tue, Nov 5, 2013 at 9:54 AM, Lars Noodén  > > wrote:
> >
> > On 11/05/2013 09:00 PM, Jan Hendrik den Besten wrote:
> > > Boy, now I am in trouble...
> > >
> > > I run an exit node from my home address for a few weeks now, but
> > my gf
> > > starts complaining she cannot use Skype anymore to chat with her
> > mum.
> > >
> > > I understand Microsoft blocks all tor exits from accessing
> > Skype. Is there
> > > anything I can do except converting the exit into a relay?
> >
> > You could try Jitsi or Blink.  They're not the same as Skype but they
> > are freer and the sound is better.
> >
> > /Lars
> >
> > ___
> > tor-relays mailing list
> > tor-relays@lists.torproject.org
> > 
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> >
> >
> >
> >
> > -- 
> > Ryan The Winner mailto:geoffr...@gmail.com>>
> >
> >
> > ___
> > 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] Amazon abuse report

[Gordon Morehouse]

Er, the quoting on my last post was incorrect, it should look like this:

> Kevin C. Krinke:
> 
> >> On Nov 4, 2013, at 7:13 PM, Nelson 
> >> wrote:
> >> 
> >> I do believe there is a benefit to Torrents as many of us can
> >> attest to, ex: fast downloads of different Linux distros; but if
> >> your use of Torrents is in fact legit then why use Tor for
> >> downloading your legal content in the first place? This doesn't
> >> pass the smell test.
> 
> What about someone in a highly censored locale that wants to
> download a copy of Tails or TBB without "them" knowing?
> 
> >> +1 for restricting bandwidth
> 
> For the record, my exit node does limit the ports as per the
> reduced exit policy [1] and I'd happily open it up wide if I could
> throttle just the torrenting to a minimally-usable level. However,
> I honestly don't think it's realistic to spend so much effort to
> solve the throttling of torrents when those efforts could be better
> spent elsewhere [2].

One could have a wide-open exit policy and then do adaptive throttling
of all the ports not on the ReducedExitPolicy, without censoring
traffic. This can be accomplished entirely with tools that are
outside of Tor, e.g. iptables.

Also, educating any of the bigger BitTorrent software providers
(uTorrent, Transmission, librtorrent, the knuckledraggers from Vuze
probably being a lost cause) to add a *configurable option* to look up
peer IPs in a Tor DNSBL and refuse to communicate them would reduce,
uh, supply I guess it would be. That's something that can also be
done pretty independently of Tor core development - i.e. somebody else
can spend the time to do it.

Best,
--Gordon M.

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

Re: [tor-relays] Traffic in port 9050 in a relay (denial of service attack?)

[Gordon Morehouse]

On Tue, 5 Nov 2013 20:10:09 +0100, jj tor  wrote:

> Hello again,
> 
> 
> indeed, the port 9050 is closed, but not filtered. I've set up a drop rule
> in the VPS firewall( Parallels Plesk Panel) on this port, but it's not
> working fine.
> 
> I am amazed by all the amount of this kind of traffic, more than 700
> packets/second. According to Kent Backman, this is the clickfraud net
> called "Rotpoi$on" (a lot of info at
> https://b.kentbackman.com/2013/04/15/rotpoion-botnet-powered-by-thousands-of
> -servers/)
> 
> Maybe I'll be able to block all these incoming connections, but I'm afraid
> that overall relay performance will decrease drastically because all the
> filtering work...

iptables DROP is cheap.

Best,
-Gordon M.


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

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

Kevin C. Krinke:

>> On Nov 4, 2013, at 7:13 PM, Nelson 
>> wrote:
>> 
>> I do believe there is a benefit to Torrents as many of us can
>> attest to, ex: fast downloads of different Linux distros; but if
>> your use of Torrents is in fact legit then why use Tor for
>> downloading your legal content in the first place? This doesn't
>> pass the smell test.

What about someone in a highly censored locale that wants to
download a copy of Tails or TBB without "them" knowing?

>> +1 for restricting bandwidth

For the record, my exit node does limit the ports as per the
reduced exit policy [1] and I'd happily open it up wide if I could
throttle just the torrenting to a minimally-usable level. However,
I honestly don't think it's realistic to spend so much effort to
solve the throttling of torrents when those efforts could be better
spent elsewhere [2].


One could have a wide-open exit policy and then do adaptive throttling
of all the ports not on the ReducedExitPolicy, without censoring
traffic. This can be accomplished entirely with tools that are
outside of Tor, e.g. iptables.

Also, educating any of the bigger BitTorrent software providers
(uTorrent, Transmission, librtorrent, the knuckledraggers from Vuze
probably being a lost cause) to add a *configurable option* to look up
peer IPs in a Tor DNSBL and refuse to communicate them would reduce,
uh, supply I guess it would be. That's something that can also be
done pretty independently of Tor core development - i.e. somebody else
can spend the time to do it.

Best,
- -Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

gq:
> Access to tails does not depend on any specific transfer protocol
> such as torrents correct?
> 
> Could it not be made available on a hidden service, a website. an
> email or ftp server within tor?

An http hidden service with the .onion link in Tor docs might be an
obvious choice.

> 
> On 11/4/2013 11:45 PM, Nelson wrote:
>> From all that I have read in these lists not all exit nodes are 
>> configured exactly the same, so some level of traffic control is
>> being rightly exercised by the operator(s). For any given reason
>> be it moral, ethical or legal many well known ports are being
>> blocked, as was previously discussed, as an example by setting up
>> a "white-listing" config rather than blacklisting, and these
>> white-listed ports exclude known ports used by Torrent sites. The
>> choice to configure the exit node should be left to the operator
>> based on their own legitimate preference and criteria.
>> 
>> The argument to "what if" is indeed relative to the level of
>> control and access to legitimate torrents such as "Tails", and
>> therefore any argument against freedom of access to legitimate
>> content defeats the purpose of Tor. This is not really an issue.
>> I'll ask a stupid question: "what comes first, the chicken or the
>> egg?" If you have access to Tor client in the first place and
>> want to download Tails, where's the problem?
>> 
>> ..and if you don't have Tor client installed in the first place,
>> where do you get it, so "they" (mel gibson quote) don't know
>> 
>> On 11/4/2013 5:23 PM, Kevin C. Krinke wrote:
 On Nov 4, 2013, at 7:13 PM, Nelson >>> > wrote:
 
 I do believe there is a benefit to Torrents as many of us can
 attest to, ex: fast downloads of different Linux distros; but
 if your use of Torrents is in fact legit then why use Tor for
 downloading your legal content in the first place? This
 doesn't pass the smell test.
>>> What about someone in a highly censored locale that wants to
>>> download a copy of Tails or TBB without "them" knowing?
>>> 
 +1 for restricting bandwidth
>>> For the record, my exit node does limit the ports as per the
>>> reduced exit policy [1] and I'd happily open it up wide if I
>>> could throttle just the torrenting to a minimally-usable level.
>>> However, I honestly don't think it's realistic to spend so much
>>> effort to solve the throttling of torrents when those efforts
>>> could be better spent elsewhere [2].
>>> 
>>> Just my 0.002BTC
>>> 
>>> Cheers!
>>> 
>>> -- Kevin C. Krinke mailto:ke...@krinke.ca>> 
>>> GnuPG - 851662D2 - 0x18C67F61851662D2 
>>> http://kevin.c.krinke.ca/851662D2.asc
>>> 
>>> 
>>> [1]
>>> https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
>>>
>>>
>>> 
[2] No idea what would be better deserving but I'm sure there's plenty
>>> of work in Tor-project-land that doesn't involve throttling
>>> hard-target services.
>>> 
>>> 
>>> ___ 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
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSeRnjAAoJED/jpRoe7/ujdScIAMMZldiP5IFc+7xuAiHc8E8r
MSxsXTRVbKCeDLrqAKOqvMwOZg8Et+/IweUW3hXId85PcHp2qlEHf8mT/4/fiSvj
h8JaoScccDXDyOqi7t9U2qa4o6fk8b/na/uSnRjfptkG1veHsByrw5NowrwjvMg4
s6rWDTJmZPrxVNPLZxb2XDW/yxW70LHK9Rjy2V5rJEt+LJEmEpqba+0eOmjWPIja
y+fAIAZc9cWvX1gn9ZFol843jkrXOPp3lhG1h7etVewVBUYMNV1E9wvFCLxXMwj0
LQs06vIcKXNP4sQgXXS+NOqJ2xPuFumk8cRw4bS5IIAIZUX3T6fmHcj26toOU44=
=Six9
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

On Sat, 02 Nov 2013 21:58:57 +, Paritesh Boyeyoko  
wrote:

> On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
> 
> > Completely aside from the ethical and censorship-related buzzsaw you're
> > about to run into for posting this (perennial) question, I believe some
> > actual developers on Tor have written a paper about the problems with
> > Bittorrent et al (and I think there's a more specific one than the Why Tor
> > Is Slow[1] paper) but I can't currently find it.  Anybody know?
> > 
> > 1. 
> > https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
> > 
> > NB: the above paper is from 2009.
> 
> I've just had a quick scan of that paper and it makes for an interesting 
> read. 
> :)  I'm going to go away and read it properly but a couple observations.

Here are some more links:

https://trac.torproject.org/projects/tor/ticket/9368

http://www-users.cs.umn.edu/~jansen/papers/throttling-sec2012.pdf

https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-clients-entry-guards

Finally found em just as another user brought some of them back to my 
attention.  :)

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

On Mon, 4 Nov 2013 14:38:40 -0500, Paul Syverson  
wrote:

> On Mon, Nov 04, 2013 at 08:18:29AM -0800, Gordon Morehouse wrote:
> [snip]
> > > 
> > > That's just plain silly.
> > 
> > Not as silly as you think, but the outright blocking vs finding ways
> > to throttle is more a discussion worth having.  I suspect most of the
> > Silent Majority(tm), if polled, would rather throttle than block.
> > 
> > I *swear* there was a paper on this other than the 2009 one I posted
> > the other day.
> > 
> 
> Are you perhaps thinking of "Throttling Tor Bandwidth Parasites"?
> Available at http://www.syverson.org/ or
> http://www-users.cs.umn.edu/~jansen/publications.shtml

That's one of them, here are a couple sources of information on throttling 
bandwidth hogs:

https://blog.torproject.org/blog/research-problem-adaptive-throttling-tor-clients-entry-guards

https://trac.torproject.org/projects/tor/ticket/9368

> Throttling is tricky and not a panacea. This is noted in the
> above paper and analyzed in some detail in
> "How Low Can You Go: Balancing Performance with Anonymity in Tor",
> also available at 
> http://www-users.cs.umn.edu/~jansen/publications.shtml

Indeed. I suspect it's also better than doing nothing, and better than any 
attempt to block certain types of traffic altogether.

Thanks!
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Lukas Erlacher:
> Let me chime in here in regards to torrents to be perhaps not the 
> devil's, but the radical's advocate.

A lot of the people wishing to handle bittorrent are aware of these
arguments and may not wish to block it so much as throttle the hell
out of it.

And thus we find ourselves sort of considering to act like Comcast,
except in a good-faith defense of our network.  m(

> I'm sure everyone here will agree that a good case can be made
> that copyright laws as they stand today are a perversion of, and 
> counter-productive to, their original stated intention of
> "advancement of the arts and sciences", and just as leaking secret
> information and evidence of wrongdoing is a protest and defense
> against governments that try to hinder freedom and transparency, so
> is distributing copyrighted cultural goods a protest and defense
> against content industries (that are often justifiably compared to
> criminal organisations ("MAFIAA") due to their frequently corrupt
> and abusive conduct) that attempt to censor culture in order to
> excise maximum profit from it. Cultural goods that should be
> preserved and made available to everyone rot away every day because
> they were not allowed to be preserved and distributed.

Yes, and I'd actually love to see a sort of 'Torrent Library of
Congress' bots that downloads stuff from various trackers in order of
lowest # of seeds, so it doesn't vanish.  One of my many ideas I'll
never have time to do until I'm 80.

> Do not indict torrents because it's all "movies and porn of
> horrible quality" - that is defamation. The hollywood movies and
> the porn may not have much "cultural value", but who is the arbiter
> of what "cultural value" is? And even if it was found unanimously
> that porn does not concern culture (hah!), then for every TB of
> porn and hollywood shite you block, there are Megabytes of bona
> fide culture liberated from the shackles of copyright that you
> throw to the wolves, saying "it's just torrents". And doesn't
> wikileaks use mostly torrents for distributing their releases?

Yes, yes and yes, but I would vastly prefer if Little Bobby Torrents
from Schenectady downloading the testament to American culture that is
"Bang Bus 32" didn't impact the bandwidth of people trying to use Tor
to get important information around.  Yeah, I just made a judgement
about relative quality of information there, and that's ... okay.  See
http://radioornot.com/site/?p=5181

> When you block torrenting, you're making a decision to censor 
> information and speech based on it being done using a method that
> is predominantly used for "illegitimate", "illegal" activity; in
> that case, why not shutter Tor entirely? We all know it's mainly
> used by fraudsters and other criminals, and right now at this time
> we know that 80% of Tor clients are zombies from a botnet.

Who said anything about blocking?  Maybe others.  I'd prefer
throttling.  There are many legitimate uses for torrents.  Throttling,
maybe based on amount of data transferred (if that could ever be known
at the edge(s) of the Tor network) is a better, though not perfect
solution.

> Censor torrents because your provider will shut you down if you 
> generate DMCA complaints and C&D's; censor them because you truly 
> believe that the torrents are a necessary sacrifice to allow the
> Tor network to continue to function; don't censor them because they
> don't contain worthwhile speech that deserves to be protected.

Not trying to censor anything, personally, not that I run an exit node
(yet).

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSd8d6AAoJED/jpRoe7/uj2BkIAIHdEJNdo0KCpJzHDAZ9q7fl
zb2PFYTAUirgNUk5L5qNi96kLdb6wT1N9ohRC7LpV1Y1hE80h7quA2DSGYKe3qfB
+bQnChtso0mfywCWz2dB0anoFRfR8hyqpbPNy0pDoN7/RoJ/HXmRczrT2zkLTAS+
7qrEGyxz/LB3doYiEbwgmA9ygxMcSNOlTY+YBJ/3/9eFCHngnm4iW0xyfaXeNvU1
xtjdykfkqw+WdpPWKFUAigS/UWfoqN7iAOW/aN/oEfbQtsciNC2UISNPmm8wVuF/
duy4JfDDrn7EG9HPv2U+o5bYgEaVtloQX3u1V/SvKZE1Oyc67+YR+1+/2nWReqg=
=GG2O
-END PGP SIGNATURE-


0x1EEFFBA3.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Lukas Erlacher:
>> your refusal to pay for content people create.
> 
> That's a silly smear.

If an endless tsunami of torrent traffic makes it so Tor users can't
buy music off bandcamp - a site where the artist gets the lion's
share, and where some small indie artists are getting enough to wait
tables 32 hours a week instead of 40, and thus spend 8 more hours a
week on music - is that a problem?

>> not related to tor
> 
> That's just plain silly.

Not as silly as you think, but the outright blocking vs finding ways
to throttle is more a discussion worth having.  I suspect most of the
Silent Majority(tm), if polled, would rather throttle than block.

I *swear* there was a paper on this other than the 2009 one I posted
the other day.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSd8jTAAoJED/jpRoe7/ujNaAIAJqwnQ2xlwBJGcdXTCxbpVBy
XZA+dQwiPYZEf0qE+OlZDBv8pu02KBRs+rV+t8QDY6AVnVbHRtZ22grumdBTr7vE
VrfEEct7vfY0jwNl8uXC0zJ2F+pFi7OX7EKyPGXmKgeqzJFlSkLxSTlHR/QcpQWP
o7thM/9X+/K3aawEwQh/G2CQudDDiFdXsQyxJ3A6mC75dovkjD0LNUZwS+S3Gyoz
wwlSkfyK9P/JKCZxQL5iT8sP5EIfXH8e1JJ2uLPQ2SchN72+0c/REMzOzcWo8XIk
8j0H09Ukg4vQV5Nmib9Phn1M8HQo9Yg2ZEtLG8wGEb7WH4waNudiAXqddcek3QQ=
=cWBe
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dan Staples:
> I am also running on a Pi Model B, 512MB RAM. How are you logging
> SYNs?

Ah yes, that's right.

You will find all the magic (very pre-alpha at the moment - it's
iptables commands in /etc/rc.local) in contrib/90_slowboards as part
of Cipollini:

https://github.com/gordon-morehouse/cipollini/tree/master/contrib/90_slowboards

I wouldn't bother with fail2ban right now, I've turned it off pending
some other experiments with total connection limits on the Pi.  I have
an open story to investigate making it work, right now it's just too
slow on the Pi:

https://www.pivotaltracker.com/story/show/59590860

So, try the iptables rules, change the ports to your ORPort (and
DirPort if any).  You'll note that there's a LOG target in there - for
me it appears in kern.log.

Best,
- -Gordon M.


> 
> On Sun 03 Nov 2013 11:25:26 AM EST, Gordon Morehouse wrote:
>> * *BEGIN ENCRYPTED or SIGNED PART* *
>> 
>> Dan Staples:
>>> This morning I got my first Tor traffic flood since upgrading
>>> to 2.4.x. Logs didn't say anything about not being able to
>>> handle the amount of circuit creation requests, but it showed a
>>> 200x increase in active TAP circuits (~400k/hour) and the
>>> traffic pattern is the same: Advertising 100kb bandwidth, but
>>> slammed with ~2Mb traffic.
>>> 
>>> When I saw it, I checked my relay's flags, and it has the
>>> stable flag, and has been tagged stable for at least 3 days.
>>> It's been up for 7 days.
>>> 
>>> I would love to contribute data to help correlate w/ your
>>> findings Gordon. Any metrics or logs that would be particularly
>>> helpful? I currently use NTop to measure traffic, but it's not
>>> very granular.
>> 
>> I'm still trying to scratch together enough time to analyze the
>> logs from the two floods I caught as they began in the past 10
>> days or so. One thing I am logging, which you're definitely not,
>> is hosts that send SYNs above the limit on my Raspberry Pi.  Are
>> you running on a slow machine or a VPS or what?  That might not
>> apply to you if you're not running on a slow machine - you may
>> have no need to limit SYNs or anything else, and that's probably
>> the case if your relay did not crash as a result of the flood.
>> 
>> During my last two floods, the relay survived the first (poorly,
>> with fail2ban becoming useless and chewing up half the CPU), and
>> was headshotted by the second - crash in less than 5 minutes.
>> 
>> I'm looking forward to getting the data together and providing a 
>> report for the community, but time ... my kingdom for the time to
>> do anything beyond work, sleep, eat, sh*t.
>> 
>>> I also currently don't use any iptables rules to throttle, but
>>> am happy to experiment with that if you want me to try out any 
>>> particular configurations.
>> 
>> Depends on the capacity of your hardware.  All my experimentation
>> has to do with low-end ARM boards, so the logs most useful to the
>> report *I* am planning to prepare on these events are logs of SYN
>> exceeds, and fail2ban logs.
>> 
>> Thanks very much for staying up to date and offering to
>> contribute - there is a real problem someplace, but it seems to
>> be mostly a Problem with a capital P for low-end hardware with
>> 512MB physical RAM, since those are the relays likely to actually
>> crash as a result of the floods.
>> 
>> Best, -Gordon M.
>> 
>> 
>>> 
>>> Dan
>>> 
>>> On 11/01/2013 05:30 PM, Gordon Morehouse wrote:
>>>> huh, well, near as I can tell, I didn't get Stable for any
>>>> time represented yesterday (2013-10-31) for the node
>>>> VastCatbox.
>>>> 
>>>> So maybe that theory is incorrect.  In that case I don't
>>>> know what would trigger the SYN flood behavior other than
>>>> Roger's idea about becoming an introducer for a popular HS,
>>>> but... eh... seems like a stretch, a node offering 2.5Mbps
>>>> that isn't flagged Stable?
>>>> 
>>>> -Gordon
>>>> 
>>>> On Fri, 1 Nov 2013 13:10:17 +0100, David Serrano 
>>>>  wrote:
>>>> 
>>>>> On 2013-10-31 10:04:02 (-0700), Gordon Morehouse wrote:
>>>>>> 
>>>>>> I can't verify it, but my suspicion is this is happening
>>>>

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dan Staples:
> This morning I got my first Tor traffic flood since upgrading to
> 2.4.x. Logs didn't say anything about not being able to handle the
> amount of circuit creation requests, but it showed a 200x increase
> in active TAP circuits (~400k/hour) and the traffic pattern is the
> same: Advertising 100kb bandwidth, but slammed with ~2Mb traffic.
> 
> When I saw it, I checked my relay's flags, and it has the stable
> flag, and has been tagged stable for at least 3 days. It's been up
> for 7 days.
> 
> I would love to contribute data to help correlate w/ your findings 
> Gordon. Any metrics or logs that would be particularly helpful? I 
> currently use NTop to measure traffic, but it's not very granular.

I'm still trying to scratch together enough time to analyze the logs
from the two floods I caught as they began in the past 10 days or so.
 One thing I am logging, which you're definitely not, is hosts that
send SYNs above the limit on my Raspberry Pi.  Are you running on a
slow machine or a VPS or what?  That might not apply to you if you're
not running on a slow machine - you may have no need to limit SYNs or
anything else, and that's probably the case if your relay did not
crash as a result of the flood.

During my last two floods, the relay survived the first (poorly, with
fail2ban becoming useless and chewing up half the CPU), and was
headshotted by the second - crash in less than 5 minutes.

I'm looking forward to getting the data together and providing a
report for the community, but time ... my kingdom for the time to do
anything beyond work, sleep, eat, sh*t.

> I also currently don't use any iptables rules to throttle, but am
> happy to experiment with that if you want me to try out any
> particular configurations.

Depends on the capacity of your hardware.  All my experimentation has
to do with low-end ARM boards, so the logs most useful to the report
*I* am planning to prepare on these events are logs of SYN exceeds,
and fail2ban logs.

Thanks very much for staying up to date and offering to contribute -
there is a real problem someplace, but it seems to be mostly a Problem
with a capital P for low-end hardware with 512MB physical RAM, since
those are the relays likely to actually crash as a result of the floods.

Best,
- -Gordon M.


> 
> Dan
> 
> On 11/01/2013 05:30 PM, Gordon Morehouse wrote:
>> huh, well, near as I can tell, I didn't get Stable for any time
>> represented yesterday (2013-10-31) for the node VastCatbox.
>> 
>> So maybe that theory is incorrect.  In that case I don't know
>> what would trigger the SYN flood behavior other than Roger's idea
>> about becoming an introducer for a popular HS, but... eh... seems
>> like a stretch, a node offering 2.5Mbps that isn't flagged
>> Stable?
>> 
>> -Gordon
>> 
>> On Fri, 1 Nov 2013 13:10:17 +0100, David Serrano
>>  wrote:
>> 
>>> On 2013-10-31 10:04:02 (-0700), Gordon Morehouse wrote:
>>>> 
>>>> I can't verify it, but my suspicion is this is happening when
>>>> I get my Stable flag (I have no idea if I'd gotten it back
>>>> this morning or not) or shortly thereafter.
>>> 
>>> You can use https://metrics.torproject.org/relay-search.html
>>> and enter your IP address to figure that out.
>>> 
>>> 
>>> -- David Serrano GnuPG id: 280A01F9 
>>> ___ 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
>> 
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdnj0AAoJED/jpRoe7/uj/H4H/3XYsVHbX9eYXAR/iEXAeSa4
NeBTSeD4oevmHjPeaoNUrbVsT0Da62KYSxaZUg2BOv1GCfNGXps1+uyYhsOOYXwf
QpoF0DR1aDImC2rT7EZ8N26CuOFOw8tGHjBAhXb0Is7RYSzcHPTknCGumNPJjurX
fzMMAioZXl6GjM8m3l3Bclf05duM0rgvpau3JUKI/AaPVedy1jnrPSZatWjQk2F3
GxkpfPxxvh801ye6nOqOMS3SqDpgtepUo4HGjYt5HRPR1EgYnxJQ1tlVmJzz6pLt
QgBh46afQFr7KFKdgiohj3mXa8MyX48jPqFk8scaWCLl4DslBU9/iZHvf9B/alg=
=sYUu
-END PGP SIGNATURE-


0x1EEFFBA3.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Paritesh Boyeyoko:
> On Friday 01 Nov 2013 14:39:28 Gordon Morehouse wrote:
> 
>> Completely aside from the ethical and censorship-related buzzsaw
>> you're about to run into for posting this (perennial) question, I
>> believe some actual developers on Tor have written a paper about
>> the problems with Bittorrent et al (and I think there's a more
>> specific one than the Why Tor Is Slow[1] paper) but I can't
>> currently find it.  Anybody know?
>> 
>> 1. 
>> https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf
>>
>>
>> 
NB: the above paper is from 2009.
> 
> I've just had a quick scan of that paper and it makes for an
> interesting read. :)  I'm going to go away and read it properly but
> a couple observations.

And I swear there's a more bittorrent-specific paper but I can't find it.

> 2.3 Throttle certain protocols at the client side I agree this is
> not a good idea BUT it sparked off another idea in my head.  In 
> order to get better utilisation of slower relays, would it be worth
>  introducing a behaviour whereby "slow" circuits are deliberately
> built for low volume traffic?
> 
> For example, sending email and IM messages doesn't (usually)
> require a huge amount of bandwidth, so when the Tor client detects
> that a user wants to send/receive data on certain slow ports such
> as POP3, IMAP4, MSA and Jabber it deliberately builds a "slow"
> circuit to handle that traffic.  Obviously it would have to be port
> based, but since people tend to send data on well-known ports, it
> shouldn't be an issue.

That might have at least been thought about, but it's a good idea.
It'd also help with better allocating bandwidth offered by "slow" or
"fast but at the bottom end" nodes, which I've seen devs in here say
they are well aware is not optimally allocated.

> 
> I think this would play well with the circuit-bonding work here
> 
> http://freehaven.net/anonbib/#pets13-splitting
> 
> 
> 3.1.2 Better Support for relay operators This caught my eye: "We
> lose relays when the operator reboots and forgets to set up the
> relay to start on boot."  Does installing the .deb package (for 
> example) not configure Tor to start on boot, in the same way that
> Apache would be?  I ask because I haven't rebooted my VPS yet. :p

I've not seen this with .debs, but Windows?  If so, maybe the "restart
on reboot?" dialog - if there is one, and not a hidden checkbox -
should be front and center when opting to relay traffic.

> 3.1.3  Facebook app to show off your relay I liked this bit:
> "Opportunities for expansion include allowing relay operators to
> form “teams”, and for these teams to be ranked on the contribution
> to the network. (Real world examples here include the SETI 
> screensaver and the MD5 hash crack challenges.)"

I'd go for an embeddable badge, first.  Then maybe a Facebook app.
It's only a hunch, but I think we'd get a lot more mileage out of an
embeddable badge (for web sites, tumblr, and anything else tumblr-like
that allows embedding) than out of a Facebook app, though if there
were time, money and spoons[1] to do both, I'd certainly do both with
the Facebook thing coming second.  Well, maybe.  Nobody should be on
Facebook, least of all anybody who is running Tor for the right
reasons, but we have reality to contend with here.

My hunch is based on demographics, BTW. :P

> What would be really interesting would be to find sponsors (read:
> hosters) willing to put their name to it and gain/risk some
> publicity.

Start by asking XMission, GANDI and maybe even (though they don't do
VPS) NearlyFreeSpeech.net if this ever happens.  Also, dig back into
news articles about industry response to the NSA wiping its butt with
the Fourth Amendment, and see which VPS providers were yelling the
loudest, especially the mom-n-pop to mid-tier providers.  $.02.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdnZyAAoJED/jpRoe7/uj0ywH/3c9d5uTsVJWtSkwd/YSuVpU
+Q5Az2Wd1Pes45z8Zx/fRtvhlJ7/qtZloXxVyDLg7KjUjJktiCgJaDO7j8mw9/NO
S5W2JFHtr8j8AukDdMzCpocD06O1Chhq7cmq+DzdZji+jENR2iB4jbKzvNNkVCNg
duAiPnNPiEl/6m5ViiFuO38P+qag0nNN4lnnOnHcvodXfmU4Qxgzd/zwEoKpF0ET
qKOmb3zKsxF3bqq1Ab2+hLafhdkJYThOszbJuiCwA+q+D94lDIJ5nFftq4lhWqN2
WcGASJpzOLR9CnkykMPiTYHVuM2RZZWTEeVlN10eAynpzO9qeNYFHk2KTeUoZsY=
=Owji
-END PGP SIGNATURE-


0x1EEFFBA3.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] dynamically adjusting bandwidth

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

starlight.201...@binnacle.cx:
>> The question is, should I put in an adjustment for 
>> 'MaxAdvertisedBandwidth' during the backup window or make any
>> other change to advise remote relays to de-prioritize the node
>> for the duration?
[snip]
> So the answer here is definitely DO NOT lower
> 'MaxAdvertisedBandwidth' during intervals when 'RelayBandwidthRate'
> is reduced for events like offsite backups. Doing so will probably
> cause the Guard flag to be removed when it is present.

Thank you, this is really useful to know for Cipollini[1].  We're
working currently on automatic bandwidth tuning and congestion avoidance.

1. https://github.com/gordon-morehouse/cipollini

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdnQyAAoJED/jpRoe7/ujKLAH/1Y8zvahIDDrbTqPzRN0HsOP
C+TIuqpbR9VDjPhLHgcywbiEBEr6gTLbezh+EnCZeky0bO3WZ1ZHlTZ0Szow3X4P
tG7wY47Q34G+g78oKk8jfzYUlq1M2Mo3Lbkce/lkHe3hGece1nqItgLmXGswXP8h
AaYUpDEQy6y1jXGTDtwMPQadZ2Qg7oZg4sXrIQ3yZlDWuBVLXzXK+I/GsO40Yd2n
1XGdXkV1r6D095ofBuLXSriO+kKs1qpE9HHb1mvlKYDPe5w2KebUJo1OmzWeDuHE
lsLETbf4QUOf0B8opkBGK8VjqjRYDII/dNp9OJbUGVy6hFxVrYxmAXWYRBMNEoY=
=Wtgz
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Paritesh Boyeyoko:
> On Friday 01 Nov 2013 20:02:29 Gordon Morehouse wrote:
> 
>> 
>> What if someone inside a totalitarian state is attempting to
>> upload evidence of a massacre to a service which runs on port
>> 80?
> 
> Yeah, I did think of this but I thought I'd put it out there
> anyway. Unfortunately, too many sites/services don't use SSL.
> Well, it's a no-no.

That's changing, not fast enough, but the NSA did a great job of
raising awareness (even if they *can* crack it)...

>> I'd love to get the bandwidth back from the 16 year olds
>> downloading movies and terrible porn over Tor, too, but this
>> won't fly, and y'all are gonna get flamed into cinders in about
>> 5... 4... 3... for the types of reasons I just mentioned above.
> 
> So would I, hence my looking at this to try and knock such 16 year
> olds off of the network. :)  However, yourself and Lunar make good
> points especially concerning the legal position over traffic
> redirection and/or manipulation.

Well, plus, there are ethical questions about managing the traffic
itself, and the fact that if tampering is detected, you'll get a
BadExit flag.  It's mostly ethical questions, IMO.

> So what's the answer?  Education?  Educating torrent users to not
> use Tor isn't going to work - if they know enough to use Tor
> (thanks Azureus, NOT) - then they're gonna use it, so that's pretty
> much out.

Education does help - I've crashed many a thread suggesting Tor for
BitTorrent and explained why it's harmful.  I mean, I guess I don't
have any metrics to back me up, but a lot of the people seem to say
"oh, jeez, well in that case maybe I won't."

> Publication of sample exit policies?  Would that encourage exit
> node operators to run restricted exit policies, and save themselves
> loads of bandwidth and DMCA headache?

That's been done, but a link in the default torrc above those config
areas would be *great*.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdSGpAAoJED/jpRoe7/ujn9cH/0C6/pI3TVXthpzu1DfMyqi0
un3tPtt3ZAhGgzJHeZ8Z1fXf/ihUtK0R1c9KBEPDZ3xW11yoWsqRF3+yD8kYFx5h
CjlTH5E5dqth0pg5OnVtauX9HYrI7ppmynp7b/gDSvs9UvhkM7cIeHgKu7OgUidE
pjpNVymQXmCcYN9E+x1/9EM4Oy6X1bi29nH0oSJBaYyGWHwd7FfF21oB2sIFFVbE
6kxDJ74s1XUmHRj/viBOs6vCI3dWgr8kEvz99Tm59q2g/45T4O/Q8hB3ZXMECmAe
Iy0RMT/CbcgMaIJLX4CuglM8cUgZI9IwvId26hNzI0Z8H00RufCB/2xmk/JU62g=
=x4lg
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] connecting to obfsproxy bridge from OSX10.9 and TorBrowser-Pluggable-Transports-2.4.17-beta-2-pt3-osx-i386

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Paul Garrett Hugel:
> Please steer me to the correct list if off topic here
> 
> Remote machine is Ubuntu obfsproxy bridge on amazon ec2 using ARM
> 
> My local machine running 10.9 Mavericks with
> TorBrowser-Pluggable-Transports-2.4.17-beta-2-pt3-osx-i386
> 
> I read the  trouble ticket #10030 
> https://trac.torproject.org/projects/tor/ticket/10030
> 
> changed the torrc file entries as indicated below
> 
> ClientTransportPlugin flashproxy exec ./flashproxy-client
> --register :0 :9000 ClientTransportPlugin obfs2,obfs3 exec
> ./obfsproxy.bin managed

Try the absolute path to flashproxy-client and obfsproxy.bin[1]
instead of what you've got in the above lines.

1. That's odd, why's it named .bin?

Best,
- -Gordon M.


> 
> Still cannot get the Browser to use the proxy
> 
> Nov 01 22:55:58.740 [Warning] Could not launch managed proxy
> executable at './flashproxy-client' ('No such file or directory?). 
> Nov 01 22:55:58.764 [Warning] Could not launch managed proxy
> executable at './obfsproxy.bin' ('No such file or directory?).
> 
> Ok If I want to get serious and access my Ubuntu obfsproxy bridge
> on amazon ec2
> 
> what Tor components on local machine  do I use and configuration
> 
> Tor builds the circuits but browser can?t connect to proxy so Its
> non-functional for web browsing
> 
> Thank you
> 
> D922 B7B1 3A4D 9BF9 0927 DCA1 7A14 4B7D A3F4 8305
> 
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdSBOAAoJED/jpRoe7/uj4+EIAKnBRcbV6iGlUZKt5ObRUfjt
N3NYxGFScOiW0YamB0FUWapaoHXaf8PNcDs/F1S6uwLbqkj8xo+vW8AAWQtgrIAr
dqaiGUPlzYfn8GsCpFw1QJDVZl9wwp2+SsyCk2DCd/WSOXjoNwiU7cqxxsFaS57T
3EENLxSNIHHrEOcQejzPxPjdjHXX4BWCn6SdL2mP3Ud+Odo6a0bRE2d1l3DRjvf5
RZyfxVNQtxltSjTIq2xXs/LNgUREU8+wKOkmPZ7x9TFF/UJNhIfVlCDwLU0BoTpL
NkR5EioMAVRCy/DtVtHngblOaAODsuhMd2hl4SFVHx8Sfm2A5MuYM+uL4+d0EoE=
=kqbe
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Paritesh Boyeyoko:
> On Friday 01 Nov 2013 19:36:11 krishna e bera wrote:
>> On the other hand, i had a reduced exit policy and still got
>> DMCA complaints just for the .torrent file being downloaded via
>> HTTP through my exit.
> 
> Let me run a couple ideas past you:
> 
> 1.  Configure Squid as a forward proxy with Squidguard and
> configure Squidguard to reject any URL with "announce" in it.  Use
> IPTables to transparently redirect anything destined for ports 80,
> 2710 and other well known tracker ports to Squid.
> 
> 2.  Do not exit port 80.  While security and anonymity are separate
> things, they are tightly coupled, so why not exit only secure
> ports: HTTPS, POP3S, IMAPS etc.
> 
> Obviously some protocols use TLS on the same port as the clear
> traffic, but how detrimental do you think restricting to SSL/TLS
> enabled protocols (with a few exceptions) would be?

What if someone inside a totalitarian state is attempting to upload
evidence of a massacre to a service which runs on port 80?

I'd love to get the bandwidth back from the 16 year olds downloading
movies and terrible porn over Tor, too, but this won't fly, and y'all
are gonna get flamed into cinders in about 5... 4... 3... for the
types of reasons I just mentioned above.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSdGtBAAoJED/jpRoe7/ujgOkH/0H7GZwBM2SBqJ1lNtkr0M7/
SnEmxGjxoaoRpNWr/mm+Z/x6DP8lTRGiPZ2SJ5NYCz3eeCuI4Tn2rdMbWJ9+T2NP
LV7n75vfk1qFOroCgtPlUL7EOEVOXmiRYIaGuNK4bPwXdBQ/bdKVhBy42jD8uCCj
Sor1/eHC2O+2Pfqg61SGyuFuGpziUI3uZeuMFWXHTh0DY2BsehTrRHTJqmH3data
6rCYr0k2NhHcnik35MW2LYejnBAckOfuEdbQ2GyOZDpBw2pGmKZrx15rvuGxg2yd
4JJX/lBm8XIgLElxcZI+wkMUDh/B2Ee2r9oyjU3Fn1PYfXAZ5FLO7DDMKXjyQw8=
=f/SA
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

On Fri, 01 Nov 2013 11:22:19 -0700, Nelson  wrote:

> Please excuse my ignorance operating Tor relays, but if I run an exit
> node on Windows 7 and use something like Peerblock and correspoding
> block lists of P2P sites, wouldn't this be somewhat effective in
> stopping this sort of undesired traffic on Tor?

Completely aside from the ethical and censorship-related buzzsaw you're about 
to run into for posting this (perennial) question, I believe some actual 
developers on Tor have written a paper about the problems with Bittorrent et al 
(and I think there's a more specific one than the Why Tor Is Slow[1] paper) but 
I can't currently find it.  Anybody know?

1.  https://svn.torproject.org/svn/projects/roadmaps/2009-03-11-performance.pdf

NB: the above paper is from 2009.

Best,
-Gordon M.


> 
> 
> On 11/1/2013 10:48 AM, Paritesh Boyeyoko wrote:
> > On Friday 01 Nov 2013 05:37:14 I wrote:
> >> The advice on how to manage exit problems seems to
> >> be very sound and Tor is defensible because it is being abused by
> >> torrenting also.
> >>
> > 
> > ...and this is something else I don't quite understand.  People who know 
> > about 
> > Tor (which obviously includes exit operators) are well aware of the stress 
> > that BitTorrent puts on the Tor network.
> > 
> > The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 
> > 54.48% 
> > of the traffic passing through the sample exit nodes was BiTorrent traffic.
> > 
> > Myself and others (I'm sure) look forward to the day when the Tor network 
> > comprises 100,000+ 100Mb/s nodes.  However, until that time comes I would 
> > think that exit node operators would (wrong choice of words incoming) make 
> > more effort to use a whitelisted exit policy, thereby starving BitTorrent 
> > of 
> > bandwidth, and forcing those users away from this "free VPN".  The likes of 
> > Vuze (Azureus) don't help the situation by offering Tor as an option.
> > 
> > Would it be worth putting together selection of template Exit Policies 
> > which 
> > exit node operators can cut & paste into their torrc?  Or (and this is more 
> > a 
> > dev question) have an "include" directive where separate policy files can 
> > be 
> > specified (and therefore substituted), something like this:
> > 
> > ExitPolicy include /etc/tor/mail.exit
> > ExitPolicy include /etc/tor/rdp.exit
> > ExitPolicy include /etc/tor/web.exit
> > ExitPolicy include /etc/tor/chat.exit
> > 
> > Combine this with a default reject *:* policy and it *may* lead to a change 
> > of 
> > culture and squeeze BitTorrent out.  It may even help reduce the number of 
> > DMCA notices that exit operators get.
> > 
> > Thoughts?
> > 
> 
> ___
> 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] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

huh, well, near as I can tell, I didn't get Stable for any time represented 
yesterday (2013-10-31) for the node VastCatbox.

So maybe that theory is incorrect.  In that case I don't know what would 
trigger the SYN flood behavior other than Roger's idea about becoming an 
introducer for a popular HS, but... eh... seems like a stretch, a node offering 
2.5Mbps that isn't flagged Stable?

-Gordon

On Fri, 1 Nov 2013 13:10:17 +0100, David Serrano  wrote:

> On 2013-10-31 10:04:02 (-0700), Gordon Morehouse wrote:
> > 
> > I can't
> > verify it, but my suspicion is this is happening when I get my Stable
> > flag (I have no idea if I'd gotten it back this morning or not) or
> > shortly thereafter.
> 
> You can use https://metrics.torproject.org/relay-search.html and enter
> your IP address to figure that out.
> 
> 
> -- 
>  David Serrano
>  GnuPG id: 280A01F9
> ___
> 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] Amazon abuse report

[Gordon Morehouse]

On Fri, 01 Nov 2013 17:48:44 +, Paritesh Boyeyoko  
wrote:

> On Friday 01 Nov 2013 05:37:14 I wrote:
> >The advice on how to manage exit problems seems to
> > be very sound and Tor is defensible because it is being abused by
> > torrenting also.
> > 
> 
> ...and this is something else I don't quite understand.  People who know 
> about 
> Tor (which obviously includes exit operators) are well aware of the stress 
> that BitTorrent puts on the Tor network.
> 
> The paper http://planete.inrialpes.fr/papers/TorTraffic-NSS10.pdf shows 
> 54.48% 
> of the traffic passing through the sample exit nodes was BiTorrent traffic.
> 
> Myself and others (I'm sure) look forward to the day when the Tor network 
> comprises 100,000+ 100Mb/s nodes.  However, until that time comes I would 
> think that exit node operators would (wrong choice of words incoming) make 
> more effort to use a whitelisted exit policy, thereby starving BitTorrent of 
> bandwidth, and forcing those users away from this "free VPN".  The likes of 
> Vuze (Azureus) don't help the situation by offering Tor as an option.
> 
> Would it be worth putting together selection of template Exit Policies which 
> exit node operators can cut & paste into their torrc?  Or (and this is more a 
> dev question) have an "include" directive where separate policy files can be 
> specified (and therefore substituted), something like this:
> 
> ExitPolicy include /etc/tor/mail.exit
> ExitPolicy include /etc/tor/rdp.exit
> ExitPolicy include /etc/tor/web.exit
> ExitPolicy include /etc/tor/chat.exit

I *love* the idea of an conf.d/ style exit config.

> Combine this with a default reject *:* policy and it *may* lead to a change 
> of 
> culture and squeeze BitTorrent out.  It may even help reduce the number of 
> DMCA notices that exit operators get.

I would very much like to see the default policy to be no-exit, because as I 
mentioned before I suspect we're losing some nodes started up by noobs who then 
get screamed at and just shut them down, without ever really becoming part of 
the community.  It needs to be as easy as possible to run a relay, and given 
that one *can* face legal consequences in some jurisdictions over what goes 
into and out of a computer one rents, no-exit should be the default.

Best,
-Gordon M.

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

Re: [tor-relays] Amazon abuse report

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roger Dingledine:
> On Thu, Oct 31, 2013 at 06:12:47PM -0700, Andy Isaacson wrote:
>> That's correct, it takes a deliberate action on the part of the 
>> administrator to become a relay; and another deliberate action to
>> become an exit relay.
> 
> Actually, that second part isn't true. Once you decide to become a
> relay, the default is to exit to most popular ports.

I don't think this is a good enough reason these days, when people who
haven't read the fine fine print are putting them up on VPSes.  A
friend of mine did it and had to get his Linode IP changed after
getting on a bunch of blacklists in like two days.

> (If you're using Vidalia to configure your relay, it makes you
> choose whether you want to be a non-exit relay or an exit relay.
> But just Tor by itself, the default exit policy is in the man
> page.)
> 
> The main reason for this choice is the number of people who've told
> us that they are only able to run exit relays because "it's what
> Tor does when you run a relay", and their institution wouldn't let
> them do it if it required a manual config change to become an
> exit.

Yeah... you guys would know better than me about that, but speaking
from the perspective of a small fish, the exit-as-default torrc is a
serious "WTF?" and always has been, given potential legal trouble in
privacy-hostile countries.

$.02

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJScxIWAAoJED/jpRoe7/ujHZsIAIoedsRc9ZY1xtcEBPFzJvCl
NS7kJKDBvLJJKl7W5RjF5y3/iSBmBJzSHUm10mJDn81hQB+wlbwud4mRjQUXhsFl
+xC85z5PB65k8AvPALsMtOpw6A9XOL7ure9Gua7uUDGkn/bLaiu70sFCiy6aY5dB
24HVgppSL6K6zGAE6rEFNaYsdTOvf3MSBCUTvAVA2Vhya8oQKMaE92dUrYr9I95n
k7RSQdgNN93c2K2e1wV1WoSXsSqahCtf2FiG2ZtXmf6arp2Zdc9ONy7iKsfkrbR6
jj24lJ45bVx3rDlShhNGxpGZ4LMFUirpaZh0+LemIWiXU4PH6HsjjVSD4FCF1Fo=
=r+c5
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Tor CPU usage has dropped way back to 15-40% in the last few minutes,
even as I was increasing my total inbound connection limit to 150
connections.

This is a hell of a log line on a Raspberry Pi, which also just popped
out:

Oct 31 10:13:49.000 [notice] Circuit handshake stats since last time:
61533/218956 TAP, 30/30 NTor.

Wow.

Best,
- -Gordon M.



Gordon Morehouse:
> I've just seen the most amazing headshot of my Tor relay by a
> sudden massive SYN flood yet. I was online and started noticing
> problems with DNS on my local router. I checked my so-called
> monitoring setup, a window with a permanent ping to my router, and
> noticed a lot of timeouts. Obviously, that means trouble.
> 
> Checked my Raspberry Pi tor relay setup, and there was an
> incredible SYN flood just starting. I have attached an image where
> the vertical scale reaches up to 5 megabits per second and where is
> column is two seconds. This is absolutely not established tor
> connection behavior. I don't know what *all* of it is, since once
> the Tor daemon dies, the SYN traffic seems to be steady at about
> 50KB/sec (of *just* SYNs inbound, and 100+KB/sec of outbound ICMP
> port unreachable packets).  But that huge tsunami marks when the
> flood / circuit creation storm really got going.
> 
> My relay crashed faster than I've ever seen it crash before, even
> with my newer protections in place. In under 5 minutes the out of
> memory killer reaped Tor.  In previous situations, I've observed
> during floods that Tor's share of physical memory doesn't seem to
> increase. I could be wrong about that, but I think the thing eating
> all the RAM is TCP open/half-open sockets and/or associated tables
> in the Linux kernel - once RAM pressure becomes too intense, Tor is
> just the biggest thing around, so the oom-killer picks it and bam.
> 
> The truly amazing and disturbing thing is that it's an hour and a
> half later now, and my router is still under extreme load from the
> incoming SYN packets. It hasn't yet crashed.
> 
> In the meantime I added an iptables rule right under the
> "ESTABLISHED" rule suggested by David Serrano:
> 
> 
> Chain INPUT (policy ACCEPT) target prot opt source
> destination
> 
> ACCEPT all  --  anywhere anywhere
> state ESTABLISHED
> 
> DROP   tcp  --  anywhere anywhere tcpflags:
> FIN,SYN,RST,ACK/SYN #conn src/0 > 75
> 
> SYN_THROTTLE  tcp  --  anywhere anywhere multiport
> dports 31923,31924 state NEW
> 
> 
> (those weird params are from a connlimit suggestion I found for 
> limiting the total number of TCP connections which may be handled
> over a chain.)  I started off at 50, and am now up to 100.  This
> is obviously a stopgap solution for an ongoing event, but it
> suggests some further ways that slower single-board computers can
> be made to weather such storms, possibly without (see earlier
> discussion on this thread) using fail2ban at all, which is very
> inefficient.
> 
> What's quite alarming is that when I raise the limit a bit, to get
> the restarted Tor relay better connected, the SYN flood logs go
> crazy for a minute or two before instantaneously stopping when, I
> presume, the connection limit has been reached.  Since the dropped
> packets above the global inbound connection limit are not logged,
> the sudden start/stop of the SYN flood logging (in the SYN_THROTTLE
> chain, they're logged) tells me I am still under intense SYN
> flood.
> 
> After adding connection limits on the Tor box, my router recovered
> and is seeing ping times, ballpark 2x normal (0.8-1.2ms is normal,
> now it's more like 1.0-2.0,s), but things are working handily.  I
> have also been able to connect to other services through the Tor
> relay again, with considerable difficulty.
> 
> I notice that Tor is consuming all available CPU, even though it
> is, for the moment, relaying a pretty consistent 50-80KB/sec.  I
> suspect that this is mostly circuit creation requests coming in
> over established Tor connections, which Tor is ... processing, I
> don't know how, but unless there's been some turnover and they get
> lucky, once another peer attempts a TCP/TLS handshake, its packets
> are likely to be dropped.  This is probably not ideal.
> 
> As long as the Raspberry Pi manages to stay up and keep logging
> I'll have all the data to go through later. (I already captured a
> lot.) I also have the logs from the other incident that I caught
> and watched in real time. I'm planning to do an analysis on the
> number of IPs involved, whether they are Tor relays are not, and
> other interesting things 

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've just seen the most amazing headshot of my Tor relay by a sudden
massive SYN flood yet. I was online and started noticing problems with
DNS on my local router. I checked my so-called monitoring setup, a
window with a permanent ping to my router, and noticed a lot of
timeouts. Obviously, that means trouble.

Checked my Raspberry Pi tor relay setup, and there was an incredible SYN
flood just starting. I have attached an image where the vertical scale
reaches up to 5 megabits per second and where is column is two seconds.
This is absolutely not established tor connection behavior. I don't
know what *all* of it is, since once the Tor daemon dies, the SYN
traffic seems to be steady at about 50KB/sec (of *just* SYNs inbound,
and 100+KB/sec of outbound ICMP port unreachable packets).  But that
huge tsunami marks when the flood / circuit creation storm really got
going.

My relay crashed faster than I've ever seen it crash before, even with
my newer protections in place. In under 5 minutes the out of memory
killer reaped Tor.  In previous situations, I've observed during
floods that Tor's share of physical memory doesn't seem to increase.
I could be wrong about that, but I think the thing eating all the RAM
is TCP open/half-open sockets and/or associated tables in the Linux
kernel - once RAM pressure becomes too intense, Tor is just the
biggest thing around, so the oom-killer picks it and bam.

The truly amazing and disturbing thing is that it's an hour and a half
later now, and my router is still under extreme load from the incoming
SYN packets. It hasn't yet crashed.

In the meantime I added an iptables rule right under the "ESTABLISHED"
rule suggested by David Serrano:


Chain INPUT (policy ACCEPT)
target prot opt source   destination

ACCEPT all  --  anywhere anywhere state
ESTABLISHED

DROP   tcp  --  anywhere anywhere
tcpflags: FIN,SYN,RST,ACK/SYN #conn src/0 > 75

SYN_THROTTLE  tcp  --  anywhere anywhere
multiport dports 31923,31924 state NEW


(those weird params are from a connlimit suggestion I found for
limiting the total number of TCP connections which may be handled over
a chain.)  I started off at 50, and am now up to 100.  This is
obviously a stopgap solution for an ongoing event, but it suggests
some further ways that slower single-board computers can be made to
weather such storms, possibly without (see earlier discussion on this
thread) using fail2ban at all, which is very inefficient.

What's quite alarming is that when I raise the limit a bit, to get the
restarted Tor relay better connected, the SYN flood logs go crazy for
a minute or two before instantaneously stopping when, I presume, the
connection limit has been reached.  Since the dropped packets above
the global inbound connection limit are not logged, the sudden
start/stop of the SYN flood logging (in the SYN_THROTTLE chain,
they're logged) tells me I am still under intense SYN flood.

After adding connection limits on the Tor box, my router recovered and
is seeing ping times, ballpark 2x normal (0.8-1.2ms is normal, now
it's more like 1.0-2.0,s), but things are working handily.  I have
also been able to connect to other services through the Tor relay
again, with
considerable difficulty.

I notice that Tor is consuming all available CPU, even though it is,
for the moment, relaying a pretty consistent 50-80KB/sec.  I suspect
that this is mostly circuit creation requests coming in over
established Tor connections, which Tor is ... processing, I don't know
how, but unless there's been some turnover and they get lucky, once
another peer attempts a TCP/TLS handshake, its packets are likely to
be dropped.  This is probably not ideal.

As long as the Raspberry Pi manages to stay up and keep logging I'll
have all the data to go through later. (I already captured a lot.) I
also have the logs from the other incident that I caught and watched
in real time. I'm planning to do an analysis on the number of IPs
involved, whether they are Tor relays are not, and other interesting
things that can be gleaned from the logs. I promise some graphs and
charts, punch and pie not so much. Unfortunately my life is quite busy
right now so the report may take a while although it's kind of a high
priority thing for me at the moment.  This is pretty crazy.  I can't
verify it, but my suspicion is this is happening when I get my Stable
flag (I have no idea if I'd gotten it back this morning or not) or
shortly thereafter.

Node is VastCatbox, flood started around 8am Pacific.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSco2BAAoJED/jpRoe7/ujPS0H/0Hc8IGiQfpVL7gfB1PPAaSc
v2vocpj74czmQJSev/mYkKJbvRT/YdNm9bCE/CH6suFFvNgBqHmx4WWEFiBbzudH
DmBXO8OTKj5oEvb3IJLxuoiPyljzTQzrk7FoUkqnieDl1et4uB8RhSGe5GpDkoYZ
0+jVB8WqEJJg2EJUghHAXVPzvgOMa9yaW4jfBWHZWM5CZ9FsDMxFC5wFMMJ8A0mL
vtY5YMxNdaQPmz6btfsAT+HM/hnTZ1kOT+WnryKlShKtEOhyHXTrWw3QC3Xd60n3

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
> On 2013-10-27 16:35:43 (-0700), Gordon Morehouse wrote:
>> 
>> And, after the boot, I've simulated an aggressive host from
>> another machine using hping, and here's the output of 'iptables
>> -L' after fail2ban banned the host (LAN IP partly redacted to
>> settle my paranoia): http://pastebin.com/1L62z23b
> 
> That resulting ruleset will break circuits. Packets from flooding
> hosts won't have a chance to reach the '--state ESTABLISHED' rule
> since they are dropped before that, from within the
> fail2ban-tor-syn-flood chain.

Thanks - I really don't understand yet with iptables how to tell in
what order the chains are processed.


>>> However, do you need fail2ban now that you are throttling SYNs 
>>> without affecting circuits?
>> 
>> Uncertain.  I'd added it as an adjunct to the throttling, hoping
>> a temporary placement into the DROP chain would save cycles and
>> memory as REJECT ICMP packets would no longer be sent
> 
> But you can drop packets in the SYN_THROTTLE chain instead of
> rejecting them, without fail2ban. Or you can accept them until a
> threshold is reached, then log/reject them up to a second
> threshold, then silently drop them.

Currently this is how it works:

1. accept to the 3/sec burst 6, then reject (iptables)
2. 4 logs of iptables reject in 75 sec = 90 sec ban (fail2ban)

I'd love to do all of the above purely in iptables and eliminate
fail2ban, but is it capable of maintaining state like that (e.g. the
75 second 'watch time' and 90 sec 'ban time')?

This is very new to me, I've always used off-the-shelf iptables-based
packages.  If there are docs I should read which cover this use case
without me having to read for 2 hours before I get there, I'd really
appreciate a link.  And I say that not to be a jerk, but because my
time is stretched really really thin.

Thanks for all your iptables help.  You'll definitely be credited.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSb82hAAoJED/jpRoe7/uj/OwH/jaw/7+nkllmcmeambEDZv42
Xr1MYb/6oL22iQm1y7YmioNP4rBh2Vwp2zRSK6c/ZBkxAp9+DQnNqs2DOdeG/cC5
3KJ0ho6cRJDEQXYbRXjU10nH/fF0WHuIbGaWAy0GU3xcTWxSclfkBkk/PblMPHWi
1bqBloVnKFbSFd+I1sOSji9aguNJlmdk4GUOEbh/MFlfRm9wrhUvK4eEr88i57nR
rSbUkiaZ9BSo+93IP+7JWAQkw2emPH61kUg4zonPO5sncrGPbNl5/WCVrbZlh/j0
4Lvc/v5ING401SmJSctDXgL9EUXlY1bxRIKez13tagEY3UwNw2ozNQgzMh6rApI=
=y8kL
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traceroute measurement from Tor relays

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Das, Anupam:
> Hi Gordon, Thanks for the questions. We have put up a small 
> description of the project and FAQs (including your posted 
> questions) at the following link-
> 
> http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html
> 
> Hope you find the page helpful.

Yep, I read it, but I still had the two questions - particularly
whether non-exit relays should run the script or not.

Anyway, I'll run it on any of my relays with the Guard flag.  Thanks,
and thanks for doing this research!  :)

Best,
- -Gordon M.

> Das, Anupam:
>> So we have received some questions about running our traceroute 
>> measurements. Let me answer some of the questions:
> 
> Here are two more:
> 
> 1. Is the traffic to go *through* tor, or just clearnet off the 
> machine running the relay?
> 
> 2. Is this only applicable to exit relays?  That's not clear at 
> all, whether results from non-exit relay boxes (or bridges) are 
> useful or wanted.
> 
> Best, -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbcTnAAoJED/jpRoe7/ujFKUH/RhiKcI2z/1Sv8bveANHzNiV
nJJFsnyf+hd9Zu4KIDrc44PcONHliVCPXh9ORVkiQkn/nk0oqRpTvRNGFU8uhD98
jZnA2AVmgqTRbXLsFE223b2gzGct5ZI/6QsnxKyyQrrAdoe41Ng5b1L21ChE7ZOn
VDSVBktX7t6B6gyJTEWSZ0joKcaRA4RREFBTBYZuA7Woc/SruOvYMc33RICNpI9E
6kRAYVXuYFUvhTN5mNA2QqF7CJKxCeK+SX7XrHStxEZPXbZFhIqqTOYc79OQeKXg
O0qbfdwC+jYmefZsNLVWttlWjzEXX6djQEIBHStgcaLt0pIE91PVI+pwEtAleto=
=Sq9Q
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Roger, I was hoping you'd get to this eventually. :)

Roger Dingledine:
> On Sun, Oct 20, 2013 at 09:42:01AM -0700, Gordon Morehouse wrote:
>> With the slower computers, sometimes too many attempts to connect
>> to the ORPort (I am almost positive as part of TAP circuit
>> building, but not *really* sure) can eventually cause Tor to
>> consume more physmem than available and cause the oom-killer to
>> kill Tor.  Also, depending on the crappiness of the user's
>> router, it's effectively a SYN flood, and can crash or impair
>> consumer routers.
> 
> This doesn't sound like circuit building. It sounds like TLS
> handshakes.

Very good to know.

> You see, a new circuit handshake (TAP or NTor) is simply a 512-byte
> cell sent along an already established TCP connection. So if you're
> getting flooded by circuit handshakes, it will be traffic (which
> causes cpu load) but it won't be any new TCP connections.
> 
> If you're seeing a bunch of new TCP connections, that sounds like 
> clients trying to establish a new OR connection with you. (And
> those TLS handshakes are done in the core Tor thread, so having a
> weak CPU while handling a lot of TLS handshakes will cause your
> other Tor operations to hiccup.)

This is what's going on, and it's often relatively soon after I get my
Stable flag.

>> My solution, so far, is to define (through trial and error on a 
>> per-machine basis, since [1] is only officially supporting 3
>> SBCs right now) limits on how many SYNs may be sent to the ORPort
>> and the DirPort per second.  This is done with iptables.  I
>> experimented, tuned the parameters and watched traffic for weeks
>> and came up with a pretty good set of limits for a 950MHz
>> Raspberry Pi:  4 SYNs/sec burst 10.  (For those about to say the
>> Pi is thus too slow to be used as a relay, it's quite capable of
>> relaying *at least* 2.5Mbps, but *not* when it's getting SYN
>> flooded.)
> 
> My first question is to wonder if this flood of clients connections
> is coming from a few IP addresses or many IP addresses. And to
> wonder if it's coming from Tor relays or not.

I was lucky enough to catch a "storm" just starting a couple mornings
ago, and am going to try to dissect the logs and my realtime
observations and provide a report - I expect it'd be useful to more
than just me and my single-board computer project.

>> After watching the data, I noticed that some hosts just try to
>> connect once or twice, or try to connect (during overload
>> conditions) at reasonable intervals of tens of seconds to a few
>> minutes.  Other hosts will quadruple-tap the ORPort with SYNs,
>> four in a row, and otherwise be much more aggressive with sending
>> SYNs.
> 
> Sounds like you are seeing variations in TCP implementations.

Yep, that's what I figured.

>> Currently, if a peer violates the 4/sec burst 10 SYN limit more
>> than 5 times in 60 seconds, that peer will be banned for 90
>> seconds.  I'm trying to trim this down to the minimum that will
>> protect the relay, and 90 seconds is a guess given some of my
>> fears, read on...
> 
> That brings up a second question: if you *do* let them establish a 
> TLS connection with you, do they stop hammering you? Or do they
> always want more? How long until they hang up on a connection that
> you allow to establish.

I'm not entirely sure yet, and I need to do some log-data crunching.
Do you know offhand how long it will take Tor to give up on connecting
to a peer if it seems down for a while?

>> First, during a SYN flood type overload, some peers which have 
>> *existing* circuits built through the relay and are sending SYNs
>> as normal traffic, will stochastically get "caught" in the filter
>> and banned for a short time.
> 
> Wait, what? SYN packets are not part of normal traffic for an
> established connection.

I incorrectly assumed that new circuit requests began with a TCP
handshake.  However, *if* the peer were being flooded, and a peer that
was already connected to the relay happened to send 4 SYN packets
which arrived after other hosts had exceeded the limit for that given
second, the unlucky peer would still get banned.  David Serrano
suggested an amendment to my iptables rules, which I've implemented,
which *may* immunize ESTABLISHED connections from the fail2ban ban;
he's helping me piece out whether that actually works or not.

What would be good to know from you is how often already-connected
peers would be TCP handshaking to a relay's ORPort or DirPort.

>> So here's the $64,000 question:
>> 
>> If a 

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
> On 2013-10-27 15:00:10 (-0700), Gordon Morehouse wrote:
>> 
>> Here's my 'iptables -L' output, on pastebin because it's a mess
>> when formatted for email:  http://pastebin.com/f1VZNeTF
>> 
>> That's not a fresh boot, though, I did:
>> 
>> 'iptables -F' 'service fail2ban reload'
>> 
>> and then ran the iptables commands by hand, in order.
> 
> Things may potentially be different after a reboot, so I'd
> recommend rebooting now and see how the firewall ends up. Right now
> it seems that fail2ban would ban and break existing circuits. It
> all depends on what rules it inserts into its chain.

Here's the output of 'iptables -L' after a fresh boot:
http://pastebin.com/b0PUbJJX

And, after the boot, I've simulated an aggressive host from another
machine using hping, and here's the output of 'iptables -L' after
fail2ban banned the host (LAN IP partly redacted to settle my
paranoia): http://pastebin.com/1L62z23b

Incidentally, this experiment confirmed that once fail2ban has banned
a host, further packets are not logged such that fail2ban must parse
them, which was an open question and is now answered, and answered the
way I wanted.

> However, do you need fail2ban now that you are throttling SYNs
> without affecting circuits?

Uncertain.  I'd added it as an adjunct to the throttling, hoping a
temporary placement into the DROP chain would save cycles and memory
as REJECT ICMP packets would no longer be sent; in the only major Tor
SYN flood I've experienced since adding fail2ban to the mix (and
reducing the SYN limits from 4/sec burst 10 to 3/sec burst 6),
fail2ban eventually fell far enough behind in parsing logs of those
SYNs exceeding the limits that it could not catch up and stopped
banning hosts.  The node survived the flood for the first time without
crashing, but fail2ban was working for the first 20-30 min or so IIRC,
so that may have helped, or it may have just been the reduction in the
SYN throttle limits.

I have an open bug in the project tracker[1] regarding figuring out
what to do with fail2ban, and one of the options is to get rid of it,
but I don't know enough yet.

1. https://www.pivotaltracker.com/s/projects/917796

Thanks a ton for your help!

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbaNMAAoJED/jpRoe7/ujSngH/1B1u3C1PjQHa77/YtvRRUy9
ZmzGmbNmZFOwNIdFA/VRCBPsTmluN5FemVzjRVTpPBFhlVmBbc6V4pgvtdyWGVUg
Obs+za5ZZU1ccws+ZfG5pqvwB6UPpMY3mf38JwUuiUvQAVKNCLqvk9HulhCF9Ams
F/kexeotFYm6nFUq4CJ0nA6Z3O8KQhCFEHMY8Ercj92UgfeTMvP/GxTS9qoGt2c6
Fyy+4xYO1v8PHY6NhcU9bPOscngWLj3Wq6DsmNYqCOv5B5aYuM+ycVpqjYsRT5hr
gF6eFZvl37BnQvS2fnXhw7ppT5wUbzgF0O3LDuM5Bv5Rj8P/397oE6Mfuu5RMXo=
=IiEm
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

krishna e bera:
> On 13-10-27 05:32 PM, Gordon Morehouse wrote:
>>> Also, to what extent would/could the Tor network (or a small
>>> group of nodes) count as a "high availability cluster" for
>>> entry firewalling purposes?  Would clustering help protect
>>> against timing attacks on relays or hidden services?
>> 
>> You mean, if you have a circuit, sending some bytes of I/O over
>> entry node A, some over entry node B, etc?  Not quite sure what
>> you're asking.
> 
> Yes, essentially load balancing. I noticed someone was working on
> bonding tcp connections at the back end, so why not the opposite as
> well.

That is one for the folks who can develop proofs or theories about
anonymity to answer - and I hope they might at some point if they
haven't already in a paper they'll point out to us. :)

>>> (I lack expertise or resources to answer any of the above, but 
>>> reading Gordon Morehouse's project got me searching and
>>> curious.)
>> 
>> I'm glad it's doing somebody some good, or taking up time that 
>> could've been otherwise wasted on Buzzfeed or something ;) Not
>> that you'd do that. ;)
> 
> Never heard of Buzzfeed but i will check it out, thanks!

Oh, no, please don't.  :(

;)

- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbYwTAAoJED/jpRoe7/ujZ0YH/21BMOfemse2gCqNg0gqVtyN
/vz9dIKVRjPue4mrCjODumHEuMmRWU1H9yb66V6zd0k3UPOMKtLDN0+qZO/hrgqZ
ylJ2aWNQOkUNcZXGcvTWVLd8nd/ny5YOEmMj17TQ74hycJLSRJIgty5+VaSe61Rn
Y2nhrGdYNQVbhrQto4joDVT7uEbQCy49ZWWyNAdaTAuqwqJIuWNhOIgIeKggIkVG
fSJncTxl69RPXn8RmgLzHc2YPRpQI8ChbvblP9XtXdhu7rQMwiGbcBbGgvp92rju
6oC6909VVsLMLO/os7BvCzsG04F8Xh0Ty7bp/fAqQRIhXf0KjgIRYgZzudi+xHI=
=TH/K
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
> On 2013-10-27 12:29:33 (-0700), Gordon Morehouse wrote:
>> 
>> I've implemented these and I'd really love for anyone who's great
>> at
>>  iptables to sanity-check my rules[1] because I am an iptables
>> relative
>>  noob.
>> 
> 
>> 5: # TODO: don't know if fail2ban will override this if a host
>> with established
>>  6: # connections gets temp banned. We don't want it to. Need to
>> find out.
>> 
> 
> It depends on the spot fail2ban inserts the new firewall rules. If
> it's before
>  the '--state ESTABLISHED' rule, then the ban will be enforced.
> Otherwise, the
>  kernel will let the packets through when they reach that rule.


Here's my 'iptables -L' output, on pastebin because it's a mess when
formatted for email:  http://pastebin.com/f1VZNeTF

That's not a fresh boot, though, I did:

'iptables -F'
'service fail2ban reload'

and then ran the iptables commands by hand, in order.


>> 12: iptables -A INPUT -p tcp -m multiport --dports 31923,31924 -m
>> state --state NEW -j SYN_THROTTLE
>>  [...]
>>  17: /sbin/iptables -A SYN_THROTTLE -m state --state NEW -j LOG
>>  18: /sbin/iptables -A SYN_THROTTLE -m state --state NEW -j
>> REJECT
>> 
> 
> You don't need '-m state --state NEW' in lines 17 and 18 because
> all packets in that chain are already known to be new.

Ah, right - thanks! That might save a few cycles, assuming iptables
wouldn't optimize it out.  Important for the Raspberry Pi!

> I recommend to use always --log-prefix for easy future grepping.

Another good idea, thanks again.  I've committed these changes to the
repo.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbYznAAoJED/jpRoe7/ujaicH/AzF3WcvrTIGKopEB/XLyStc
IWEyhh7HD773RrbgpoZ9G2BCQUT5hyoMy8ezKxm9xEfbkZn5aDyA9Kv+kNGuHPYZ
uWXbjCGfW7FPaj/Adje2rpAMl9azt9hiyPvY38dXvXnVrnHIK1rvCM4AuNqEwkLp
Z94/BGKlY6b9ttKYU10NDGVb0hllIyZRXveTjpDaocMeokGEuhHAenAPeWcY04yf
hgZdD5Mqm+3lofOEtJ38UaPu2LUS75bO2DpVRK7H0dByhMlyRM6gDb1SmfT57hy6
OR/qGvrl6gjDVEapmwTJTFVu1oGCCkntPbZpy8qTL1hlAFX3nnHMnKw1Am/PqtY=
=5+Kw
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

krishna e bera:
> On 13-10-20 12:42 PM, Gordon Morehouse wrote:
>> First, during a SYN flood type overload, some peers which have 
>> *existing* circuits built through the relay and are sending SYNs
>> as normal traffic, will stochastically get "caught" in the filter
>> and banned for a short time.  If these hosts already have
>> circuits open through the relay which is overloaded, I would
>> prefer to preserve those circuits rather than break them.  My
>> defensive strategy versus overload here is to throttle new
>> circuit creation requests, *not* to break existing circuits. ... 
>> If a tor relay has a circuit built through a peer, and the peer
>> starts dropping 100% of packets, how long will it take before the
>> relay with the circuit "gives up" on the circuit and tears it
>> down?  I want to set my temp ban time *below* this timeout.
>> Thus, unlucky peers that were caught in the filter and have
>> circuits already built through the relay they will experience a
>> brief performance degradation, but they won't lose their active
>> circuits through the overloaded relay, and in the meantime
>> hopefully the overload condition is becoming resolved.
>> 
>> Is there such a timeout?  There must be.  Can someone tell me
>> what it is?
>> 
> 
> Would something like an conntrack-tools help? Maybe it provides
> more direct connection control than trying to game the timings. 
> http://conntrack-tools.netfilter.org/

Probably would, though it might be faster to slink over to tor-dev and
ask, get a dev to notice in here (which is what I'm trying to do ;)),
or dig through the source code myself - I'm not a C programmer but I
can read it okay.

> Also, to what extent would/could the Tor network (or a small group
> of nodes) count as a "high availability cluster" for entry
> firewalling purposes?  Would clustering help protect against timing
> attacks on relays or hidden services?

You mean, if you have a circuit, sending some bytes of I/O over entry
node A, some over entry node B, etc?  Not quite sure what you're asking.

> (I lack expertise or resources to answer any of the above, but
> reading Gordon Morehouse's project got me searching and curious.)

I'm glad it's doing somebody some good, or taking up time that
could've been otherwise wasted on Buzzfeed or something ;) Not that
you'd do that. ;)

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbYaFAAoJED/jpRoe7/ujqNkH/iq89otAE4S6VUmUPrgFlSSg
dLisPP6LiAPMT6+dwCJ/Lg+YdHuzOfuq428+fDyel7Aemg6J3kPPBDDnKp1kMbCX
39pM0RFCKRsj6LWQTSsOtFQfTbljDBhkhf/HscLkQv76myRVeA9zqh1mxwUGmpKx
EXLC2bBY+tFZeuSx3/7a9IXt4JOSuuBIR+JPQEwigTfHtWSBO/JUuxIWXlVvASqZ
26GHqMeWJm7jPgv3PPt3CbeZpMlufqEZ+RGyCQLXXnNdU5Fs2EUy2C5N4Y9RsL8z
9tGJnEMhm6DQW46kR1bLboW7VrJSHvDPVIHptbfxZg0uDAUaAOFtOADgUWCqmXY=
=Wy0W
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Traceroute measurement from Tor relays

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Das, Anupam:
> So we have received some questions about running our traceroute
> measurements. Let me answer some of the questions:

Here are two more:

1. Is the traffic to go *through* tor, or just clearnet off the
machine running the relay?

2. Is this only applicable to exit relays?  That's not clear at all,
whether results from non-exit relay boxes (or bridges) are useful or
wanted.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbYQlAAoJED/jpRoe7/ujJW4IAIJcR9JaT+IM53gAR5kvfcB6
Zojv3qzSJIycKBelfLP/A50u8ha0N3UwMM2aMaOPF9kqKirCJUwNEQX5v/4JzDWF
7TrU9LXgHnMbHkDJMjNchEvnGNHLQSMb2hDyQs5yzbY2KVcnfuGfIs1njAsRN7gE
rvVuQB9VhiLY0iP91FJPVe20598BsPT9yc8cfSDiZJipvNqtC3Wl9cVwMIE3vWaJ
dUuqR2keXSANcIKnjgflOGfgsHxC4G/sTHzFRV288HSNqhZ+WG9XOsaQy7ZRAJaG
IYYOyqWfpHKBcCOLfrwawul0mOo0QKZxXkx9BpqjW2j+/ZJd4bUlDueLHNEKfjo=
=svH0
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] minimum useful ram

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I:
> Gordon,
> 
> Thanks.
>>> To see if it was possible just now I set up an obfsproxy bridge
>>> as best I could but it failed to download properly.
> 
> I reinstalled Ubuntu 11.10 64 and free -m brought this.. total
> used   free sharedbuffers cached Mem:   256
> 38217  0  0 26 -/+ buffers/cache:
> 12243 Swap:0  0  0

That looks good for the RAM - a bridge should be fine with that, and
that's actually a darn good set of numbers for Ubuntu!

> Again following the instructions
> https://www.torproject.org/docs/debian.html.en#development apt-get
> install tor deb.torproject.org-keyring brought this...
> 
> Get:1 http://archive.ubuntu.com/ubuntu/ oneiric/main libevent-2.0-5
> amd64 2.0.12-stable-1 [132 kB] Err
> http://deb.torproject.org/torproject.org/ experimental-oneiric/main
> tor amd64 0.2.4.17-rc-1~oneiric+1 404  Not Found [IP: 82.195.75.101
> 80] Get:2 http://deb.torproject.org/torproject.org/ oneiric/main
> deb.torproject.org-keyring all 2012.08.29 [4138 B] Err
> http://deb.torproject.org/torproject.org/ experimental-oneiric/main
> tor-geoipdb all 0.2.4.17-rc-1~oneiric+1 404  Not Found [IP:
> 82.195.75.101 80] Get:3 http://archive.ubuntu.com/ubuntu/
> oneiric/universe torsocks amd64 1.1-4 [69.7 kB] Fetched 206 kB in
> 0s (290 kB/s) Failed to fetch
> http://deb.torproject.org/torproject.org/pool/main/t/tor/tor_0.2.4.17-rc-1~oneiric+1_amd64.deb
> 404  Not Found [IP: 82.195.75.101 80] Failed to fetch
> http://deb.torproject.org/torproject.org/pool/main/t/tor/tor-geoipdb_0.2.4.17-rc-1~oneiric+1_all.deb
> 404  Not Found [IP: 82.195.75.101 80] E: Unable to fetch some
> archives, maybe run apt-get update or try with --fix-missing?

This appears to happen because nobody has put a binary package
0.2.4.17-rc-1~oneiric+1_amd64.deb into
http://deb.torproject.org/torproject.org/pool/main/t/tor/ - this is a
problem on the Tor Project's repo, not with how you are attempting to
install.

You could attempt to build the package from source, the instructions
are at https://www.torproject.org/docs/debian.html.en#source - this is
how I install Tor onto the Raspberry Pi, for example.

Any tor .deb repo-master reading: has there been a discussion of a
package autobuilder?  Is there such a thing?  Missing packages like
this - not good :(

> If there are $12USD a year servers available can't a package be
> set-up to utilise them.

Yes, this is merely an unexpected (and fixable) problem :)

> I'm burrowing through the Linux lingo as well as I can but it's a
> real test of mettle!

Having used Linux since the mid-1990s, I agree. ;)

> Have you looked at the Cubie 2 board?

I own two of them, and my project to make the Raspberry Pi into a
super-reliable Tor relay has expanded to have a goal of supporting
BeagleBone boards (as Josh Dakto mentions) and Cubieboards.  The
Cubieboard 2 is very, very new and there are still a large number of
bugs and many firmware releases, but it's a very capable machine -
more than double the Pi (and with 1024MB of RAM and SATA!) for less
than double the cost.

> To seek finance to distribute a devoted board with the best balance
> of components and cost would lead to more Tor network I reckon.

The goal of my project[1] (which is very very pre-alpha right now) is
to make it really easy for people to run reliable, trouble-free relays
and bridges on these inexpensive machines, and then maybe some angel
will come along and buy $10,000 worth of them and give them away :)

1. https://github.com/gordon-morehouse/cipollini

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbYBjAAoJED/jpRoe7/ujDMoH/iJ3sFRieGcxmScl/e8Gs04i
7rdSmXBfiudt/DFty9kRHULhln6WGLg0uZhy/FVXbBMliYLNCHk14L88qcXeOW/2
jXHQ8opYH3asLDKdcdwLbov7aWZ+MK/svLhMTMByxAXgdz4k0fXjMOwj3Tf6Fpjz
z/c37u2X0YtngG1aXozOMoVPWVq0pyrv4EP8BLtE8AuDe+ImeHxFqcn9bzr3/TuQ
KkaN5txLRewWyFjsXL2h0gKvkKXHYPEYXtcBoYRa2ae7oMrzZo6cMiDWZJCA5woJ
ZsJwVDWiOqq2gXvIlM515MGn2sjbHjgoQ0vR5+OkX29n0eKT03RYaZYlMzN5VqQ=
=jGW/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
[snip]
> On 2013-10-20 09:42:01 (-0700), Gordon Morehouse wrote:
>> 
>> First, during a SYN flood type overload, some peers which have 
>> *existing* circuits built through the relay and are sending SYNs
>> as normal traffic, will stochastically get "caught" in the filter
>> and banned for a short time.  If these hosts already have
>> circuits open through the relay which is overloaded, I would
>> prefer to preserve those circuits rather than break them.  My
>> defensive strategy versus overload here is to throttle new
>> circuit creation requests, *not* to break existing circuits.
>> 
>> So here's the $64,000 question:
>> 
>> If a tor relay has a circuit built through a peer, and the peer
>> starts dropping 100% of packets, how long will it take before the
>> relay with the circuit "gives up" on the circuit and tears it
>> down?  I want to set my temp ban time *below* this timeout.
>> Thus, unlucky peers that were caught in the filter and have
>> circuits already built through the relay they will experience a
>> brief performance degradation, but they won't lose their active
>> circuits through the overloaded relay, and in the meantime
>> hopefully the overload condition is becoming resolved.
> 
> I can think of two approaches to your problem:

I've implemented these and I'd really love for anyone who's great at
iptables to sanity-check my rules[1] because I am an iptables relative
noob.

I'm also quite happy to report that my Raspberry Pi node weathered a
pretty intense SYN flood (20-30 SYNs per sec, I'm going to post a log
deconstruction of the event with graphs if possible) with the old
rules.  It didn't weather it *well*, specifically fail2ban got bogged
down and stopped working after a while while chewing up half the
available CPU cycles, but the node survived without crashing.

There are stories on the Pivotal project tracker[2] for The Cipollini
Project[3] regarding these problems - I luckily happened to catch the
SYN flood ("circuit creation storm") event just as it really got
started and was able to observe it in real time.

1. http://v.gd/1TV9mz (link to file on github)

2. https://www.pivotaltracker.com/s/projects/917796

3. https://github.com/gordon-morehouse/cipollini

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbWmcAAoJED/jpRoe7/ujvboH/RHEqHP/JRI8T5UNphT9Xvmh
KtYZvsNGRbveSBCNbPZSCyoGo6nh29grIOvSaAIaU0F2q2NRyZLrWjgnmIVlRiNi
J8QK0fDbguzhhici5bmRX5DtaQcC/Uq8UX3x1uNYxTQ3z70OAomLB+qlc1OzGreo
+3tyLb9vSAY/5s84KD2j/dBlwGF6AJ9ZuQyN5Pj+O4Z1IlCACEfQKhEPKDEg8PEV
WURXHxkbJWQHBbzMN5ls4qFoOU/iqOOtEagpXWrV4fhL737GSqb+owQEtV2TaN+X
HNluIj+B4UY45ScmuBk52QDAGKWNLhYFS3RuCraCX4DCCkMtVk2dTtbzIO5xI9U=
=q1Oo
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
> - You can 'iptables -m state --state ESTABLISHED -J ACCEPT' early
> in your [snip] - Besides this, you can 'iptables -p tcp --syn -J
> SYN_THROTTLE' and populate a

I think we're using different versions of iptables!  A lot of these
options don't work with Raspbian's version - 1.4.14.  I am puzzling
out the equivalents this morning.  :)

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSbWMoAAoJED/jpRoe7/ujxO8H/3424IYaGpkYC6t4+yunFSJI
mtEicMcvgu8cX/q9vVZMvZ9lkN6OymKJ2Kfd2UIcixykorscanTlo1qezscv82gd
rMCQZeqD52spgYGk0t9RDuwJ+w9yAp0H4Fd99qL4Gy/lmFkOl30iDlwRpDQBuZkU
Mm8QfaEOza6edeXyzKK5HnYVmpg9fxIsT2+/MDCL/No8DnytHjC9TuUzWGDIfJRg
FoHKLyUjnEtVMr2NMtRrb490ohjm/AgtFhEebx7hDSlQcpB46jlhfbNGlea1f4oL
sa3VsBwp79+pnjX2yNdb4CCPHoyX2jQjQJuVE91nHqJarYvLRnu6wrAO5ju8P9E=
=Yx4C
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

David Serrano:
> First post to this mailing list. I joined the network 3 days ago
> with a Via Nehemia system, 1 GHz, 256 Mb RAM, RelayBandwidthRate
> 500 KB.

I suspect that'll have the CPU to handle things, but RAM... guess
you'll find out!  Unsure.

> On 2013-10-20 09:42:01 (-0700), Gordon Morehouse wrote:
>> 
>> First, during a SYN flood type overload, some peers which have 
>> *existing* circuits built through the relay and are sending SYNs
>> as normal traffic, will stochastically get "caught" in the filter
>> and banned for a short time.  If these hosts already have
>> circuits open through the relay which is overloaded, I would
>> prefer to preserve those circuits rather than break them.  My
>> defensive strategy versus overload here is to throttle new
>> circuit creation requests, *not* to break existing circuits.
>> 
>> So here's the $64,000 question:
>> 
>> If a tor relay has a circuit built through a peer, and the peer
>> starts dropping 100% of packets, how long will it take before the
>> relay with the circuit "gives up" on the circuit and tears it
>> down?  I want to set my temp ban time *below* this timeout.
>> Thus, unlucky peers that were caught in the filter and have
>> circuits already built through the relay they will experience a
>> brief performance degradation, but they won't lose their active
>> circuits through the overloaded relay, and in the meantime
>> hopefully the overload condition is becoming resolved.
> 
> I can think of two approaches to your problem:
> 
> - You can 'iptables -m state --state ESTABLISHED -J ACCEPT' early
> in your ruleset, so all existing circuits will be allowed. I
> understand this is pretty standard practice and I'm somewhat
> surprised that you're not already doing it. Your SYN throttling
> would appear later in the ruleset. You could be aggresive at this
> point since you know that you won't break any circuit.
> 
> - Besides this, you can 'iptables -p tcp --syn -J SYN_THROTTLE' and
> populate a new SYN_THROTTLE chain with your desired rules to tell
> peers to calm down. Only SYN packets will enter this chain, the
> established circuits won't match this rule and will traverse the
> rest of the ruleset unaffected.
> 
> Since I run a new node and discovering this new world I'm somewhat
> concerned that once I gain the Stable flag I'll be SYN flooded too
> so I'll pay attention to this too.

This is greatly helpful, thanks.  The reason I've overlooked some
obvious things is because I'm an iptables noob.  :)

If you like, have a look at The Cipollini Project[1], which is
essentially a collection of tidbits aiming to eventually be a set of
packages that can be distributed or otherwise used to turn very
inexpensive and/or low-end boxes into "plug and forget" relays.  It'll
soon have its own mailing list.

1. https://github.com/gordon-morehouse/cipollini

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZ10uAAoJED/jpRoe7/uj3o4H/jwcQcYk0Kdiu5QaeucXLPAo
LXQdhK688xkqbadrGbFUTnsJyRGI/hZ8sJbNYZDi0iIT4BTALnRFdLaDdyF40txR
ow4AYMLLmWNno0wTwn5qgPY8v6nC4cbXpHIBWArxDDBcJfYcYIv7YzM738qyKtRk
4m7elOACQgWcP0YRZNs6ZpQxQ53asrCaVO9yCf9LS/RehJW/XlChvMWfqAOkUKYD
fiziX2ZpYd1SrZ8guUNiKfp/8zLojyjO1rknNjRer/51aHub4nADvZm3z9dDMDBJ
6bNEhU01g9ss/TJS9MffRMLRJ2cu2uqb7FNcB6jZmQvQLJDftm5OtV6IsC4PhQY=
=dV1H
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gordon Morehouse:
> Gordon Morehouse:
>> I'm still waiting for another "storm" to test the 60 sec findtime
>> / 90 sec bantime guesses that I made (and just pushed to my
>> repo, BTW). Every time my relay crashes due to a storm, it takes
>> me that much longer to get Stable back, and the storms are
>> almost nonexistent until you have the Stable flag in my
>> observation.
> 
> Another circuit-creation storm (detectable as SYN flood on ORPort) 
> happened last night soon after reattaining my Stable flag
> (argh!!!) and the following limits on SYNs to the ORPort were not
> enough to save Tor from the oom-killer:
> 
> 1. Absolute limit avg 4 SYN per second with burst of 10 to ORPort,
> with an iptables REJECT (as opposed to DROP) for hosts that send
> SYNs when this limit has been reached.
> 
> 2. 90-second iptables DROP ban for hosts which exceed the above
> (and are thus logged) in any 60-second period.

I should have said "exceed the above 5 times" here.

> 
> Sigh.  More trial and error and another (figurative) century before
> I get my Stable flag back.

I'm going to try dropping the total SYN limit to 3/sec burst 8, extend
the watch time from 60 to 75 seconds, and decrease the max # of
exceeds from 5 to 4 and see how that does.

This is fairly Pi-specific.

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZou8AAoJED/jpRoe7/ujrBYH/jJesRC0xRzo8lAf/UVKCMPf
PCN+8HAbMxFcMJw6nd0/OQQKdA3wGU6YUv3BlfgeyP/a2Ro+g9f5MZo3rCR7bvNG
dLjMG3oB4rDAmwcFAxHbJlZumPjWNcFGVOFkkxIrY+sSIhQAssDMjqTlj+YTdDJF
sh69FRl01WwghP2ivzAUZaL/NKEKEAIhPmHLMyL62qbFNhdPAbL0JV+Z/EO0Y5Sg
QGXazl7MLyvqBFUrkftQukkbn2tPkWWXOQv8gbCXhlq9UHw1TTtDbcgJpOEcwltS
TJPWXKemE/AeV06+5Aa2GQ9PdMmfwoMd9v4GFu/sFIJScN1p4JaOcA4EF69sr1E=
=DGXF
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gordon Morehouse:
> I'm still waiting for another "storm" to test the 60 sec findtime /
> 90 sec bantime guesses that I made (and just pushed to my repo,
> BTW). Every time my relay crashes due to a storm, it takes me that
> much longer to get Stable back, and the storms are almost
> nonexistent until you have the Stable flag in my observation.

Another circuit-creation storm (detectable as SYN flood on ORPort)
happened last night soon after reattaining my Stable flag (argh!!!)
and the following limits on SYNs to the ORPort were not enough to save
Tor from the oom-killer:

1. Absolute limit avg 4 SYN per second with burst of 10 to ORPort, with
   an iptables REJECT (as opposed to DROP) for hosts that send SYNs when
   this limit has been reached.

2. 90-second iptables DROP ban for hosts which exceed the above (and are
   thus logged) in any 60-second period.

Sigh.  More trial and error and another (figurative) century before I
get my Stable flag back.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZorpAAoJED/jpRoe7/ujVc0H/1w3cteInSXCNekjn76OgDMx
o/RYfiCnlVqOd6ubKOzGXn5nsYqJJpRrIwWE9j2R5/1PqZA6XAR3AbZ9ENPLP9GY
+xxY4ELn4wiQB4zSHuV/OOEwkvxq15XyDTv7mFTVhHwjC5nVV2z3g3rjGIM3735I
HMDQ5mBF9URfn4vTKXrpZ2EWzX44EsP4oAPQqMSwGSpQQ2+cdMlOWmHg257VIDcu
mrYm+lBMOqVq/ns6NMhWE/I9gwkEREK4VvpyIVANk5se+er/fL7cdKenIjciXQem
7fDDZMNov3cNa9M6dHn1yPo2r6lJkuw94M+knmexd7F+rij+vznZ524DQgrOPeI=
=lmst
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] minimum ram

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I:
> To see if it was possible just now I set up an obfsproxy bridge as
> best I could but it failed to download properly.

Can you be more specific about what this means?  What exactly happened?

> The instructions say set up Tor then the obfsproxy software which
> seemed to use up the ram. (I've reinstalled the OS from Ubuntu 11..
> to Quantal)

I generally use Debian for very low-end servers as it's pretty easy to
have a pared-down install that uses very little RAM for the OS.

When you first boot your VPS and don't have *anything* else running -
no Tor, no obfsproxy - what is the output of 'free -m'?

> Have I misunderstood something? Is there an easier way to set up a
> bridge like the Amazon ECC ones on a 256mB VPS that ab initio Linux
> people can try?

Not yet, although it's a worthy project - the difference is that
bridges need to be long-lived - you want it to be up for months or
years, which AFAIK is not the case with the "free" Amazon EC2
instances, they're temporary relays unless you decide to pay for EC2.
 (The free usage amount on EC2 does not allow you to operate even for
a whole month, fine for relays in some sense, sort of, not good for
bridges).

> If the Tor Project wants to be really big it would seem to be
> better to be easier to provide resources such as your idea of a box
> anyone can plug in.

Well, they only have a few really smart people working on the core
anonymity and crypto problems that people like me could never hope to
understand, so it's up to me and you and other people who understand
the importance of Tor to help provide those solutions.  :)

A plug-and-forget bridge package with a list of "known good" microVPS
providers would be a great thing, though.

My Raspberry Pi/single-board-computer project will definitely end up
in more bridges if I complete it, because it will urge the user to be
a bridge if they're really too slow to be a relay (and automatically
reconfigure itself if their link becomes too slow and stays that way
for a long time - at least, that's the plan).

Best,
- -Gordon M.


> 
> Robert
> 
> 
> 
>> -Original Message- From: gor...@morehouse.me Sent: Sun,
>> 20 Oct 2013 19:37:11 -0700 To: tor-relays@lists.torproject.org 
>> Subject: Re: [tor-relays] minimum ram
>> 
> I:
 Gordon,
 
 It seems useful to run obfsproxy bridges on $1 a month VPSs
 then. Can weather.torproject.org be used to monitor whether
 they're running or not?
> 
> That's a very good question - I hadn't tried monitoring my bridges 
> with it because I had other means.  Fortunately, a reboot to a
> bridge doesn't set it back like it would a relay.  Users of the
> bridge are inconvenienced (maybe) while it's offline, but cheap
> VPSes are *great* for dedicated bridges, and 128MB RAM is currently
> enough.
> 
> Best, -Gordon M.
> 
> 
 
>>> Is there any utility in the very cheap VPSs with 128mb
>>> of ram?
>> 
>> I did some testing quite a while ago and found that 256MB
>> was the minimum amount of RAM for a relay. It works for
>> some time with 128MB, but it then runs out of memory, and
>> it is not very good to have it restart all the time.
>> 
>> I say "was" because currently, with more than 3 million
>> clients in the network, a relay might even run out of
>> memory with 256MB RAM. I don't have any current data on
>> that though.
>> 
> 
> A 128MB VPS can comfortably support an obfsproxy bridge -
> just get a provider that doesn't reboot you a ton.  I've
> run a number of such bridges.
> 
> I would not go below 512MB RAM for a relay that is going
> to handle more than 2Mbps (about 200KB/sec) - you will
> eventually run out of RAM and Tor will be killed, and
> that's not great for the network.
> 
> My source for the above is a lot of blood, sweat and tears
> with Tor on the Raspberry Pi model B.  :)
> 
> Best, - -Gordon M.
 
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZUUeAAoJED/jpRoe7/ujFsEH/je6IY9pCpxSLN8PrHVhmOfA
oS9Yd9Fo7JyTkZqHfjSZIV6V/hsyB6StuGmTM3ga+y/Hz7LDnMCpEqbMOh54gVZN
FTb7ylAndD8dfxtRjkFnIkdZ02w33l21z/mE5VijDEmxzTGqsAoqvGjd/5JfEmPL
nz06mzfLjI8WvbhliEO1883fbrozjOYOALCO+1cErx7KN2gDPV1ZAXxL6ZSEzpdC
W0e3Xf9qnn5GkcnaQvK3GZVLNAMer0r0lxMgIivOrc8r3cyIhw1buBC4Kgk1ZrnA
jcm/WjJZCvJc/B+NehR+nCZDQnaXBUFca2xMe/WK9NNmsJ/tIQAjvc/rVyftBSU=
=jkv+
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] minimum ram

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I:
> Gordon,
> 
> It seems useful to run obfsproxy bridges on $1 a month VPSs then. 
> Can weather.torproject.org be used to monitor whether they're
> running or not?

That's a very good question - I hadn't tried monitoring my bridges
with it because I had other means.  Fortunately, a reboot to a bridge
doesn't set it back like it would a relay.  Users of the bridge are
inconvenienced (maybe) while it's offline, but cheap VPSes are *great*
for dedicated bridges, and 128MB RAM is currently enough.

Best,
- -Gordon M.


> 
 Is there any utility in the very cheap VPSs with 128mb of
 ram?
>>> 
>>> I did some testing quite a while ago and found that 256MB was
>>> the minimum amount of RAM for a relay. It works for some time
>>> with 128MB, but it then runs out of memory, and it is not very
>>> good to have it restart all the time.
>>> 
>>> I say "was" because currently, with more than 3 million clients
>>> in the network, a relay might even run out of memory with 256MB
>>> RAM. I don't have any current data on that though.
>>> 
>> 
>> A 128MB VPS can comfortably support an obfsproxy bridge - just
>> get a provider that doesn't reboot you a ton.  I've run a number
>> of such bridges.
>> 
>> I would not go below 512MB RAM for a relay that is going to
>> handle more than 2Mbps (about 200KB/sec) - you will eventually
>> run out of RAM and Tor will be killed, and that's not great for
>> the network.
>> 
>> My source for the above is a lot of blood, sweat and tears with
>> Tor on the Raspberry Pi model B.  :)
>> 
>> Best, - -Gordon M.
> 
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZJNVAAoJED/jpRoe7/ujdnAH/3mQfHgbIUdPdMFBVcDQwXCp
iP4etMKPyE0HC9GyDcUedXqehh6QXlU8SjHEWAs/cEa7V4CigOzSlkciyrNxdv4q
YDvtNr1R6adqG1PdGHQK8/cK1UM5tYNZgv/mPI0sV3GBrHzP8NE/bJjBvIfCnGtk
UAmw0Z1r8kcEhqGyHvBrZANW/X8XHGnSr8sM7zrk6ZQlc5sUtK9NGgJMHZvLUFHh
soNpxi9l6Sd7f5pDGUSVtCumhEkdDDQ0Y44lsC9mEkAcuGYtIyc08gF1WyQW7HcM
K8QWpnzLhMWndmKVA/SSrAYwsv4pu8myX9vfltkHEzZQjS3wceWNuMpJ0hfpyPM=
=cPFd
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] My Relay speed has dropped nearly to zero - Why?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Moritz Bartl:
> On 2013-10-20 11:19, Gordon Morehouse wrote:
>> That's nearly everybody on "broadband" in the US.  There are a
>> lot of us that would rather run relays.  3, 5, 7Mbps is still
>> reasonably respectable IMO
> 
>>> A relevant ticket is 
>>> https://trac.torproject.org/projects/tor/ticket/1854
>> 
>> Thanks for the link!  :)  I'll poke around and maybe make my
>> point there.
> 
> There's no "point" to be made. Everyone agrees that Tor should be 
> able to utilize slow relays better, but there is no final protocol 
> redesign yet that achieves that.

s/make my point/add my input/

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZJOEAAoJED/jpRoe7/ujS2kH/3r8bkE9ltvXXh+MMJSKIQiy
C3w6KyHywKXL9cy32UYCAZQRn1gPOwbsux4mO4aCuNtKSBqY+QynRRfXPcIgLrXl
NsE8v2JqyuOYXm/iHHeCZt79KT5+GrIyAVufr5GHHw0g5MUWz64Kuh8nXgPSu2nD
HTUNh8VdmHPLptg7gqrOqCAXdFvzklEZKHkwfPOTy00Ugtwl4RQClIEiWfBOUy9q
Ej78VtIKcceH6331z3FJKqtiCsaefQGSeLLwugcaiBFClkDPQV3San0DM/V1/VKo
tDp1rnKnT01E+12ppomNOy3zP7K7u0zQ5ckBQj8Du+ACYfTa6ARJAWpUEa8pze0=
=Mzu/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] My Relay speed has dropped nearly to zero - Why?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Moritz Bartl:
> On 2013-10-20 10:55, Gordon Morehouse wrote:
>> I suspect another user's assessment that Tor middle-node
>> bandwidth is now abundant, and thus nodes below a certain
>> consensus fraction are left out in the cold, may be correct.
>> Just my hunch though.
> 
> The current routing algorithm is not utilizing low-bandwidth relays
> as well as it should. This is a known problem but difficult to 
> solve. If you can provide below 10 Mbit/s, it might be better for
> now to go with a bridge instead (with going through the additional
> steps necessary to set up a 'modern' obfs2/3 bridge).

That's nearly everybody on "broadband" in the US.  There are a lot of
us that would rather run relays.  3, 5, 7Mbps is still reasonably
respectable IMO (and provides headroom when things happen, such as
botnet invasions, if those botnets send a lot of data unlike the
current one).  I run my bridges either piggybacked on VPSes used for
other purposes, or on micro-VPS instances; I feel like my ability to
offer even 3Mbps *reliably* shouldn't be overlooked.

> A relevant ticket is
> https://trac.torproject.org/projects/tor/ticket/1854

Thanks for the link!  :)  I'll poke around and maybe make my point there.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZB6+AAoJED/jpRoe7/ujk40H/RmKhytR5MfP5/yly2yHK4cH
ic9100zEjWYXkXyeNYhG/4G9CCcHatYLhEVLu22Z6ey9UeIX+9y7uce7lWjdjMCg
QJ3qaR9IUPyqNS67AT3ZF+k7yrnL3fGLTvQFjaohlu/SnWiFE0duZG0OYynTaq0X
2bm0iPBK2GSoG1dkxETbgaMdQAHcBCoevdI4aPDENZvKaZASlNYKeokyeFwLgySt
icRrHKU9KtpVVhFlVK6pxQHCg8qvcBrXcz1QHJJ9Gwm8pknrUYoHdxAIU//Uf3kn
r4869I0HuS8vnZwmhA+pFRFRGqd2iCE0V1u0vD1ZzwEMumQnm/Irdy1i2CXSSR8=
=qhrv
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Botnet issues and upgrading to 0.2.4.x

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Chris Whittleston:
> Do you think it might help to restart tor every 24 hours or so
> using cron Dan - or would that adversely affect the network too
> much/not actually help?

Generally restarting a Tor relay is something you want to do as little
as possible.  I'm not sure if a quick graceful restart will ruin your
Stable flag, but if you do have a Stable flag, you're killing every
circuit through you when you restart.

So, try to keep tor up 24/7 rather than restarting it a lot.

Best,
- -Gordon M.


> On 14 Oct 2013 22:32, "Dan Staples"  wrote:
> 
>> In my experience, setting the bandwidth advertising options does 
>> nothing to stop the "storms" of circuit creation requests. It
>> *will* affect the *average* bandwidth used by your relay, but
>> every once in a while, I'll still get circuit-creation storms
>> that completely overwhelm my RPi and knock it offline (I'm
>> talking continuous 3Mbps bandwidth use for several hours when
>> MaxAdvertisedBandwidth is 200 kbps). It seems from past
>> discussions on the mailing list, this is still an unresolved 
>> issue.
>> 
>> On Mon 14 Oct 2013 04:43:50 PM EDT, Chris Whittleston wrote:
>>> Thanks Logforme - yeah I was trying that before I sent the
>>> first email in this chain, but maybe I didn't go low enough
>>> with the advertised bandwidth. When the 0.2.4 compilation is
>>> done (it's still chugging along) I'll try going lower and see
>>> if it helps.
>>> 
>>> Chris
>>> 
>>> 
>>> On 14 October 2013 21:38, Logforme >> > wrote:
>>> 
>>> On 2013-10-14 22:01, Chris Whittleston wrote:
 I see - so I'll probably still see the problem with a huge
 number
>> of
 circuits being created after I've finished building 0.2.4. Is
 there any way to limit this, I'm guessing reducing the
 bandwidth wouldn't actually help? I guess I'll look into how
 much further I can
>>> overclock
 the CPU...
>>> Only option that I know of is to reduce the bandwidth you
>>> advertise
>> to
>>> the network. The more bandwidth you advertise the more
>>> circuits the tor network will throw at your relay. The
>>> following flags in the torrc file can be used (with my current
>>> understanding of them): BandwidthRate : The max bandwidth you
>>> provide over a long period of time BandwidthBurst : The max
>>> bandwidth you provide over a short period of time 
>>> MaxAdvertisedBandwidth : The max bandwidth you tell the tor 
>>> network about So you can set BandwidthRate to the real max you
>>> want to provide and then set MaxAdvertisedBandwidth to a number
>>> low enough to prevent circuit overload.
>>> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZBrOAAoJED/jpRoe7/ujnf0H/i+LnIirKcAaceALJOuBasQX
LczVJiuIG027mqEA6xid6lkiMMVyhIbYbLCL965RJiVm/P8OYfb6woxxUCaOG2s4
N+pzFDZpg5toZOYgp378oq84GDYpvXdeTxTwx+itATsoGBPg28bYA3YTXGfmTiJr
/K+cn7j+0QlJsJEgv2taTcnHVgpm4/pm0cfji7/Gg2sGJTuQmRH/V1QMy95fdLUR
9dklGpCHEFNOWcDR+MGRTqrks3qG3iMvxuw0HgQ6l5wJSGi1g1ovV3yI0JZNJKQq
vBAHIaZ+yqUHkGux0cd1FxUe+HOVbLfuKFFBNTuuu2riXdboMyI65aepezRqSQU=
=h+np
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] VPS

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Eduard:
> I rented a VPS with 256mb ram and unmetered bandwidth. Ubuntu
> 12.04. Can someone please tell me how to configure it as a non-exit
> relay for Tor? Acess via PuTTy.

256MB RAM and unmetered bandwidth is going to get you into trouble
very quickly.  That's not enough RAM.

If you're on a 10Mbps port and set your limits to about 5Mbps
RelayBandwidthRate, you're going to need more than 256MB - probably
more like 768MB and a cron job to restart Tor if it chews up all RAM
and gets itself killed.

(Restarting Tor is something you want to avoid, BTW, but I understand
the cost of RAM resources.)

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZBm6AAoJED/jpRoe7/uju6IIAIp/v83kTENBtNjzy3d4UNfz
edP51kntxDFATpUO2j7zzKoTGQgJ8Z9/1QHzH6Ik1+erJBYfKR09xXArPT3afGI4
PsIDxaA9tBW2FeCHyKQKu+mLtARTxW0UYwvii1i3vESJk3M3itojdHqDLrxISpbN
eybwNDVMzaBcObv7dNXdrOCYxGjk/M9v/de+lBEuudaes2KdUTSx6qiE4mVrgXTI
RHaXT4k66IEXurxT6X2KfPhVvpMiSYH/6uN6DeAVqfP533Zen1SmFK1WJA/ZBtFj
34CecKroEX2XKFDOOG+oTlU6W+JlWOjlBoGY6ruSdFv5WHscT91bpXJuccvGN0Y=
=sq22
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dan Staples:
> 
> 
> On 10/20/2013 12:42 PM, Gordon Morehouse wrote:
>> If a tor relay has a circuit built through a peer, and the peer 
>> starts dropping 100% of packets, how long will it take before
>> the relay with the circuit "gives up" on the circuit and tears it
>> down? I want to set my temp ban time *below* this timeout.  Thus,
>> unlucky peers that were caught in the filter and have circuits
>> already built through the relay they will experience a brief
>> performance degradation, but they won't lose their active
>> circuits through the overloaded relay, and in the meantime
>> hopefully the overload condition is becoming resolved.
> 
> Might it be better to actually cause the connecting client to tear 
> down the circuit instead of degrading performance? If your relay
> is already being swamped by circuit-creation requests, it might be
> better to cause clients to build new circuits, hopefully not using
> your relay, no?


My reasoning here is that the Pi can push at least 2.5 Mbps of traffic
comfortably.  If a Pi-based relay gets the Stable flag, and peers
start building long-lived circuits through it (correct me if my
understanding is weak please, BTW), the traffic flowing through those
existing circuits isn't doing the most loading of the relay; it's the
SYNs/circuit creation requests, and thus, those are what I want to shed.

The issue is that a peer with circuits which already exist may send
some SYNs at the wrong time and get banned - I'd prefer to temporarily
degrade service than to force that peer to tear down the circuit,
because the circuit itself isn't causing much load.  The ban of a peer
with pre-existing circuits is collateral damage, essentially, and I'd
like to limit that.

Let's pretend (I have no idea) that Tor will give up after 90 sec if a
circuit's peer starts dropping all packets.  If I choose only to drop
packets for anyone caught in the short-term ban filter for 75 seconds,
that's probably a pretty strong signal to peers looking to build *new*
circuits to try elsewhere, but the peers with existing circuits will
be degraded for 75 seconds and then get to keep their active circuits.
 If the storm abates or even slows, they may not see this degradation
much at all.

I'm still waiting for another "storm" to test the 60 sec findtime / 90
sec bantime guesses that I made (and just pushed to my repo, BTW).
Every time my relay crashes due to a storm, it takes me that much
longer to get Stable back, and the storms are almost nonexistent until
you have the Stable flag in my observation.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZBaGAAoJED/jpRoe7/ujx6UH/AytoSztsFBgbV4rB47wSnTo
oM0AyDa08jTWcwtnMVpaTVg0v57a6JdCMeA1HLi16XqRolor+WYpQBUL56nmxLge
yq4/jNJn7zDLUKJVtNY3mzWF8ZxdERqkHXFjsif6JlenCtLSpZarmNCO9YDGuror
ZbYlJYMAFxeZN/+OUh0ve1ANIXiU7uHXGNm9j3cgkAuWHZpRbN5os3GCxirTMxEi
A4T3JzIbj6QwFGs4QRf0yDqStRm43esTIT7MtQo5G++/d+NHO6LchTdQ+UWvIcXN
AY599l8izwCabRWtqWGqJ8FN6a87cKD3cN4IOZVQwNMNqT7CzHYs0hTQ5AOIclo=
=slcD
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] My Relay speed has dropped nearly to zero - Why?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Jesse Victors:
> 
>> 
>> On 10/18/2013 11:46 PM, David Carlson wrote:
 On October 8 something caused my non-exit relay speed to drop
 from around 50 KB to less than 10 KB according to Atlas
 graphs.  I have checked with my ISP and run speed tests that
 verify my upload speed to be .96 Mb and download to be over 3
 Mb, as they have been for years.  I am running Tor
 0.2.4.17-rc on Windows 7 and my consensus weight has dropped
 to 26.  What could have caused this?
 
>> Same here. See the below and do the math on how much data I was
>> and am now pushing per 24 hours, as well as open circuits.
>> 
>> 
>> Oct 07 09:04:41.242 uptime 15 days 22:00 hours, 791 circuits
>> open. I've sent 55.41 GB and received 57.06 GB. Oct 08
>> 09:04:41.237 uptime 16 days 22:00 hours, 1255 circuits open. I've
>>  sent 63.95 GB and received 65.80 GB.
>> 
>> Oct 17 23:04:41.236 uptime 26 days 12:00 hours, 87 circuits
>> open. I've sent 90.08 GB and received 92.16 GB. Oct 18
>> 23:04:41.259 uptime 27 days 12:00 hours, 87 circuits open. I've
>> sent 91.85 GB and received 93.96 GB.

I've seen very similar logs (with occasional fluctuations upward,
pushing much more traffic for a short time) on my Pi relay, which is
struggling to get its Stable flag back.  :(  I just figured it was the
lack of the Stable flag.

> I've been seeing the same. My bandwidth limit is around 3 MB/sec,
> but it's been consistently at 400-600 KB/sec. I don't think it
> started that early for me though, not sure though. I was going to
> blame it on psad, but I can't see any evidence of that. The fact
> that all three of us experience this is interesting.

I suspect another user's assessment that Tor middle-node bandwidth is
now abundant, and thus nodes below a certain consensus fraction are
left out in the cold, may be correct.  Just my hunch though.

I also wonder if this behavior is non-optimal.  I'd prefer a better
spread of traffic to nodes above some absolute floor (mainly to avoid
well-meaning people on DSL connections with 128Kbps outbound, heh).  I
can push a couple hundred KB/sec very reliably - that ought to be
worth something.

If nothing else, cutting traffic to near zero on
slower-but-not-glacial nodes is problematic for a couple reasons:

1. If the operators are also using them as their entry point to Tor,
it might make them more vulnerable to traffic analysis, since there's
less "cover" traffic (just my hunch)

2. It may discourage node operators with very usable bandwidth, and
cause them to shut down their relays.  In the future, those relays may
become very necessary.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZBj6AAoJED/jpRoe7/uj284H/0TToHzf1s4a+Wbh5He2/ZNR
AJt/OFS9t8ncQCS9rUuxVD2O+sUAr0Y00PUFNPMhYuuSnmxWaxa3AHdcaRv+HjMD
5k53Ho7sfLA2cmFsfogPAQrPSpg2GdMjCTg8wCqEvnQv4lJ2NDQ8VHkWjXLTifIq
qYtkK3k9Ie8NTe8u594d9YR8ki/RI6VEg0GlFwaLoWf7oeHFz2Cl8oZI8pL7cirR
fj9Jor9Vksr6z058uSADByMM/eYTPPA078opZOMFL47dNe6tNK+k+jRTO8zZSt0j
u2lv23V4TvEqreKKTC/TQwK909hX5L6gsbHiOeuZn0umFKZjnr6XYME1sJQPtcc=
=AGcz
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Botnet issues and upgrading to 0.2.4.x

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dan Staples:
> Thanks Gordon, I've been following your posts about the 
> circuit-creation storms with interest. I recently upgraded my Pi
> to Tor v0.2.4, and haven't witnessed a storm yet (they are
> relatively rare for me). But I am certainly interested in trying
> out your mitigation strategies.

They certainly got rarer (or stopped rising to the level of being
noticeable in logs so often) with the upgrade to 0.2.4.17-rc.

> Regarding your deb packages, have you considered talking with any 
> Debian or Raspbian devs? Getting them to sign your public key, and 
> possibly even accepting your packages upstream, would create a web
> of trust so folks would be more willing to install what you build.

It's on the list[1].  :)

1. https://www.pivotaltracker.com/s/projects/917796

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZBOmAAoJED/jpRoe7/ujal8H/AlVlqnJfJQa4EEjS9/8a8Yq
XqQcOhmjNq5tO8ZBwea6evh4IkhAYX246SqWNkXnIwg79JdJI6DFHWbmqjZ0WQ50
hH55JV/7XyKwfyn182jcxB7IAZKDQYBSgWbnWnTDEjJFwZOrmOxjy7ozmp/qgw2g
gKPsCXOfrEdGddk4sJABEQiIEyV4fGx7c4h2XIvpuN2ZQ8EdfLCvJ88UoWcSMmGM
6S6CB1IWEesLR9EtNFN87iNXitocq7EzlmIUN3bQbUm0qUdTWLm+dYXdFuvJK6Df
KSvVLT27+4gZSDyQWptNW77/OGzUkd1vGVIoiV0pTarJSPv1PdHZwt0SQLIYHzk=
=7Coz
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Botnet issues and upgrading to 0.2.4.x

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dan Staples:
> In my experience, setting the bandwidth advertising options does 
> nothing to stop the "storms" of circuit creation requests.

This is absolutely correct, and I've been working on this problem with
the Pi for months now.


> It *will* affect the *average* bandwidth used by your relay, but
> every once in a while, I'll still get circuit-creation storms that
> completely overwhelm my RPi and knock it offline (I'm talking
> continuous 3Mbps bandwidth use for several hours when
> MaxAdvertisedBandwidth is 200 kbps). It seems from past discussions
> on the mailing list, this is still an unresolved issue.

Correct.

I have an ongoing project to support Tor on small single-board
computers, including the Raspberry Pi.[1]

In the contrib/90_slowboards dir, I've included some iptables rules
that drastically reduce, but *do not eliminate*, Tor's vulnerability
to running out of physical RAM and being killed during a SYN
flood/circuit creation storm.

I've also included some fail2ban[2] rules that ban hosts for short
periods of time when they ignore the iptables SYN throttling.  However
(and I'll push a commit in the next hour changing this), I'd suggest
you use a "findtime" of 60 and "bantime" of 90, not 300 and 600 as I
first pushed to the repo.  Please see this post[3] for more technical
talk/questions, which I *just* made before reading yours and writing
this reply.  Please be aware that the fail2ban fallback is much less
battle-tested (on my relay) than the iptables SYN throttling.

Incidentally, I host binary .debs compiled *for Raspbian* at [1] as
well, if you trust random internet dudes and don't want to compile it
yourself.  A deterministic build is a (very long-term) goal.

1. https://github.com/gordon-morehouse/cipollini

2. http://www.fail2ban.org/wiki/index.php/Main_Page

3.
https://lists.torproject.org/pipermail/tor-relays/2013-October/003074.html

Best,
- -Gordon M.

> 
> On Mon 14 Oct 2013 04:43:50 PM EDT, Chris Whittleston wrote:
>> Thanks Logforme - yeah I was trying that before I sent the first
>> email in this chain, but maybe I didn't go low enough with the
>> advertised bandwidth. When the 0.2.4 compilation is done (it's
>> still chugging along) I'll try going lower and see if it helps.
>> 
>> Chris
>> 
>> 
>> On 14 October 2013 21:38, Logforme > <mailto:m7...@abc.se>> wrote:
>> 
>> On 2013-10-14 22:01, Chris Whittleston wrote:
>>> I see - so I'll probably still see the problem with a huge
>>> number of circuits being created after I've finished building
>>> 0.2.4. Is there any way to limit this, I'm guessing reducing
>>> the bandwidth wouldn't actually help? I guess I'll look into
>>> how much further I can
>> overclock
>>> the CPU...
>> Only option that I know of is to reduce the bandwidth you
>> advertise to the network. The more bandwidth you advertise the
>> more circuits the tor network will throw at your relay. The
>> following flags in the torrc file can be used (with my current
>> understanding of them): BandwidthRate : The max bandwidth you
>> provide over a long period of time BandwidthBurst : The max
>> bandwidth you provide over a short period of time 
>> MaxAdvertisedBandwidth : The max bandwidth you tell the tor 
>> network about So you can set BandwidthRate to the real max you
>> want to provide and then set MaxAdvertisedBandwidth to a number
>> low enough to prevent circuit overload.
>> 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org 
>> <mailto:tor-relays@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:
>> cs...@cam.ac.uk <mailto:cs...@cam.ac.uk> Tel: +44 (0)1223 336423
>> 
>> 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> -- http://disman.tl OpenPGP key: http://disman.tl/pgp.asc 
> Fingerprint: 2480 095D 4B16 436F 35AB 7305 F670 74ED BD86 43A9 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZAsYAAoJED/jpRoe7/ujsNsH/3CtN72LfrRXe8qFmj7QmVkO
8bQRZh0d2Wtp6cV9YhEzIvQxK74snzQiK4p

[tor-relays] max TCP interruption before Tor circuit teardown?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I'm working on building support scaffolding[1] for Tor on Raspberry Pi
and other small ARM single-board computers (SBCs).

With the slower computers, sometimes too many attempts to connect to
the ORPort (I am almost positive as part of TAP circuit building, but
not *really* sure) can eventually cause Tor to consume more physmem
than available and cause the oom-killer to kill Tor.  Also, depending
on the crappiness of the user's router, it's effectively a SYN flood,
and can crash or impair consumer routers.

My solution, so far, is to define (through trial and error on a
per-machine basis, since [1] is only officially supporting 3 SBCs
right now) limits on how many SYNs may be sent to the ORPort and the
DirPort per second.  This is done with iptables.  I experimented,
tuned the parameters and watched traffic for weeks and came up with a
pretty good set of limits for a 950MHz Raspberry Pi:  4 SYNs/sec burst
10.  (For those about to say the Pi is thus too slow to be used as a
relay, it's quite capable of relaying *at least* 2.5Mbps, but *not*
when it's getting SYN flooded.)

So, sometimes hosts exceed this limit.  Once the limit is exceeded, my
current strategy is to use iptables REJECT to send an ICMP Service
Unavailable (or whatever it's called, sorry no coffee yet) back to the
hosts that triggered the filter.  This is on a per-SYN basis.

After watching the data, I noticed that some hosts just try to connect
once or twice, or try to connect (during overload conditions) at
reasonable intervals of tens of seconds to a few minutes.  Other hosts
will quadruple-tap the ORPort with SYNs, four in a row, and otherwise
be much more aggressive with sending SYNs.

I'm currently testing fail2ban[2] as a way to ban aggressive peers by
changing that iptables REJECT to a DROP for a short period, in order
to accomplish two things:

1. Encourage them to knock off their bad behavior (i.e., go away for a
   little while).

2. Free up CPU time, RAM and bandwidth because we don't have to
   construct and send ICMP packets to banned peers.

Currently, if a peer violates the 4/sec burst 10 SYN limit more than 5
times in 60 seconds, that peer will be banned for 90 seconds.  I'm
trying to trim this down to the minimum that will protect the relay,
and 90 seconds is a guess given some of my fears, read on...

During an overload condition, my primary priority is to protect the
relay, but of course I wish to do so with as little disruption to the
Tor network as possible.  So, here is a potential problem with my
approach that I can think of, which could degrade service (mildly, for
a few end users) on the Tor network.

First, during a SYN flood type overload, some peers which have
*existing* circuits built through the relay and are sending SYNs as
normal traffic, will stochastically get "caught" in the filter and
banned for a short time.  If these hosts already have circuits open
through the relay which is overloaded, I would prefer to preserve
those circuits rather than break them.  My defensive strategy versus
overload here is to throttle new circuit creation requests, *not* to
break existing circuits.

So here's the $64,000 question:

If a tor relay has a circuit built through a peer, and the peer starts
dropping 100% of packets, how long will it take before the relay with
the circuit "gives up" on the circuit and tears it down?  I want to
set my temp ban time *below* this timeout.  Thus, unlucky peers that
were caught in the filter and have circuits already built through the
relay they will experience a brief performance degradation, but they
won't lose their active circuits through the overloaded relay, and in
the meantime hopefully the overload condition is becoming resolved.

Is there such a timeout?  There must be.  Can someone tell me what it is?

Or, is there a better way to protect low-resource machines (slow CPU,
512MB RAM) against the SYN flood "circuit creation storm" conditions
which occasionally arise on the Tor network?  Again, I must reiterate,
machines with specs like these can be very good relays for home
broadband users.  The true goal of my project[1] is to build a set of
software which enables a "plug and forget" relay for home broadband
users that costs well under $100.

[1] https://github.com/gordon-morehouse/cipollini
[2] http://www.fail2ban.org/wiki/index.php/Main_Page

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZAfXAAoJED/jpRoe7/ujGQ4H/jUUjdufoWw1qthjsqdf4ICO
ejJXBuZ60O8TpuiT07EtZq9tSDsb5hLqjJMORNJWPJe3ffD7/BHv/6St0y0fkjFh
svEFBwVMmkNfaDd65z2JaFBRnSQTsgtiOeOnQFQt1evWQMeVmFsvoMvVIbqGSkf6
NipJnfFeoAtt/6cCMl7+yIxmGGb1Udl0ZEmlVacIYtFr8MjgIo59vT94k7SuzV1N
4Na9PNeQ9WIBlZf9vyesHgnuzJA8hEkFyoP5Fc3bPT/e3WYdAIifswE6rhZVT+AQ
9rHRvBUVoYpMNyy0fqMY34rLYegelIYstsy26dmW+robJKDxGVC3zBeGbOtcEOE=
=mSYu
-END PGP SIGNATURE-
__

Re: [tor-relays] minimum ram

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Moritz Bartl:
> On 2013-10-19 03:50, I wrote:
>> Is there any utility in the very cheap VPSs with 128mb of ram?
> 
> I did some testing quite a while ago and found that 256MB was the 
> minimum amount of RAM for a relay. It works for some time with 
> 128MB, but it then runs out of memory, and it is not very good to
> have it restart all the time.
> 
> I say "was" because currently, with more than 3 million clients in
> the network, a relay might even run out of memory with 256MB RAM. I
> don't have any current data on that though.
> 

A 128MB VPS can comfortably support an obfsproxy bridge - just get a
provider that doesn't reboot you a ton.  I've run a number of such
bridges.

I would not go below 512MB RAM for a relay that is going to handle
more than 2Mbps (about 200KB/sec) - you will eventually run out of RAM
and Tor will be killed, and that's not great for the network.

My source for the above is a lot of blood, sweat and tears with Tor on
the Raspberry Pi model B.  :)

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSZAigAAoJED/jpRoe7/ujGs0H/3XB/6CeJvHY+ee7Qq5781Ag
IUwF5ykSzsLL3QkR8tZzbcG14J/O14DKimIUC/R3d0fX6z5tFfreAGgKqKVY0ZrQ
Fw8/xTDF2f3F6FlQL/YqyidY7RH40axAs5Megwk42PSGkmEMPeQVBPlao3f2jTSt
RqUtlbqp0nU71aXbgqUpyDXNxAF9OHmc7RrPWALyRkmJodtbyZpdVFQvfBRObjzh
KAMbHva37uKuuTxo1QuaaySSFFSJZM6c5wjkBL2KY5xoOrkmd+uJ+Zqu22YAjl7t
v5wZllUanel/vVYGIDeIaNdWRAclmks+KWFvZ5apYogqS2Q9h9dGtMzEnRQ4XJE=
=gWI3
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running more nets than Tor?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

grarpamp:
> Anyone also offering up vpngate, i2p, mail mixes, other 
> p2p/networks, etc to the public on their relay platform?

The Raspberry Pi is probably too limited for I2P or Freenet, but I am
investigating running these applications on the A20-based Cubieboard 2.

I will run Bittorrent on a Raspberry Pi, generally for the purpose of
seeding socially important torrents.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSTt+lAAoJED/jpRoe7/ujHcoH/jQLunmsCDNUV8TyFh6Ebzp/
UM998uVd9M5jMZ/WiSgmh05YNIJUHyCmfbgoAIIlWWi8ncGwSICMneuItnRjKV/D
DM47YvI50H318/fF/QDHUCt17nI05ZZ56pfAaOxHruOW5WzqOlc9ifbjSXx9h97n
ssPkG1Dp4hE6L3CCXKuVpgTiBN/z5YRX4+WxNf61pZKsgT6+rtgpk600nUU5lkU4
LVhDMIlOKILu+GBG7FR5us2Hsz51wM4l8iH9Rkr3ZVh9K2MKG7y5FhpJDsFkIXmG
JsKtLRzqngZgaWVt8oxJpiSAL93Vk4D0Xzj8XR+WSkMs7gfLh6ODn6nt7cdeKSY=
=jeQz
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] hardware accelerated crypto

[Gordon Morehouse]

Happily, it DOES appear that there may be some hope for the Allwinner A20 based 
Cubieboard 2 (I haven't checked for the original Cubieboard yet):

"The Security System (SS) is one encrypt/ decrypt function accelerator that is 
suitable for a variety of
applications. It supports both encryption and decryption. Several modes are 
supported by the SS
module.

It features:

AES, DES, 3DES, SHA-1, MD5 are supported by this system
ECB, CBC, CNT modes for AES/DES/3DES
128-bit, 192-bit and 256-bit key size for AES
160-bit hardware PRNG with 192-bit seed
32-word RX FIFO and 32-word TX FIFO for high speed application
Support CPU mode and DMA mode
Interrupt support"

http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf

So, it may be a little help, anyway.

The Cubieboard 2 is great for small Tor relays - it'd definitely be more 
capable than a Raspberry Pi model B as it has double the RAM and 2 more 
powerful cores with ARMv7 instead of ARMv6.

It's also almost double the price (for considerably more than double the 
computer), but I don't expect that to last long.

Best,
-Gordon M.

On Tue, 01 Oct 2013 19:02:37 -0700, Gordon Morehouse  
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> I'm interested if there are any hardware accelerators in either the
> Raspberry Pi (which needs all the help it can get) or the Cubieboard 2
> (A20-based).
> 
> Best,
> - -Gordon M.
> 
> 
> Joshua Datko:
> > I was looking into this for the BeagleBone black [1], which has 
> > on-chip accelerators for AES, SHA (1 I think), and md5.  The TI 
> > processor also has a HWRNG.  My belief was that by using the
> > cryptodev kernel module [2] I could get this working, but I ran in
> > some issues building the kernel and then I was caught up in other
> > things.
> > 
> > I'm not sure if my approach was flawed or what, but maybe it helps
> > someone here.
> > 
> > Josh
> > 
> > [1] http://datko.net/2013/09/22/quest_bbb_crypto/ [2]
> > http://cryptodev-linux.org/
> > 
> > On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote: I
> > would love to do all this actually but I never managed to get the
> > hw accelerated crypto (ssl/tls) bits working to experiment with.
> > I'd be up for restarting this if I knew I could consult with one or
> > two others who had a genuine interest in this. -Jason
> > 
> > On 10/01/2013 08:26 PM, Jeroen Massar wrote:
> >>>> On 2013-10-01 21:20, Andy Isaacson wrote:
> >>>>> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
> >>>>>> I'm not sure why I missed this first post but I'm very 
> >>>>>> interested in working on this project with whomever is 
> >>>>>> interested. I  bought a pogoplug v2 specifically to test
> >>>>>> it's usefulness as a tor exit or relay.
> >>>>> 
> >>>>> First step is, run "openssl speed rsa" and post the output
> >>>>> to the list. While you're at it you may as well post the
> >>>>> AES and SHA results as well. Heck, just run the whole
> >>>>> "openssl speed" test (should take less than 20 minutes) and
> >>>>> post the whole thing. :)
> >>>>> 
> >>>>> Also details on what CPU/RAM it has, and information about
> >>>>> the kernel and OpenSSL package you are testing, would be
> >>>>> useful. "dmesg" output and the contents of /proc/cpuinfo
> >>>>> may be helpful.
> >>>> 
> >>>> Maybe a good idea to put the output in the wiki somewhere?
> >>>> 
> >>>> Greets, Jeroen
> >>>> 
> >>>> ___ 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
> > 
> 
> - -- 
> Sent from my thing that sends email.
> -BEGIN PGP SIGNATURE-
> 
> iQEcBAEBCgAGBQJSS366AAoJED/jpRoe7/ujyREIAKb2xTXWR8xLdVpj2K8Dub9W
> jSuMtWycMgSW5nkJAOCwA+uJuX47/v7tzejNut1E76oRaAHwEn1fufiWGdT+Dbju
> f4BycdI5Pl3NTRuYcFBas32+lbFeyw+gLClczUjfE+fe/pmHiaXAXra6Alai40z8
> 77B/xGQwrpVyla4S8JHP4CY/p6FHuI5JDs+ghvVESUEK2DHJdNt5R2oLSBy4ZNQw
> BTzAf6qvflFUWhpWOkIkzIzo0c5FsJ/nYiVWpWyAjdV1NgufPdZ8ZKIoNx92iJBP
> aD1G7h9fQh3E2AU/6VHPvPdekQ5NPzehXtH8ywNFMw16oFbXkZ6/eUYUpJ50YZ8=
> =3Yig
> -END PGP SIGNATURE-
> ___
> 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] hardware accelerated crypto

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I'm interested if there are any hardware accelerators in either the
Raspberry Pi (which needs all the help it can get) or the Cubieboard 2
(A20-based).

Best,
- -Gordon M.


Joshua Datko:
> I was looking into this for the BeagleBone black [1], which has 
> on-chip accelerators for AES, SHA (1 I think), and md5.  The TI 
> processor also has a HWRNG.  My belief was that by using the
> cryptodev kernel module [2] I could get this working, but I ran in
> some issues building the kernel and then I was caught up in other
> things.
> 
> I'm not sure if my approach was flawed or what, but maybe it helps
> someone here.
> 
> Josh
> 
> [1] http://datko.net/2013/09/22/quest_bbb_crypto/ [2]
> http://cryptodev-linux.org/
> 
> On Tue, Oct 1, 2013 at 2:35 PM, jason  wrote: I
> would love to do all this actually but I never managed to get the
> hw accelerated crypto (ssl/tls) bits working to experiment with.
> I'd be up for restarting this if I knew I could consult with one or
> two others who had a genuine interest in this. -Jason
> 
> On 10/01/2013 08:26 PM, Jeroen Massar wrote:
 On 2013-10-01 21:20, Andy Isaacson wrote:
> On Tue, Oct 01, 2013 at 06:45:52PM +, jason wrote:
>> I'm not sure why I missed this first post but I'm very 
>> interested in working on this project with whomever is 
>> interested. I  bought a pogoplug v2 specifically to test
>> it's usefulness as a tor exit or relay.
> 
> First step is, run "openssl speed rsa" and post the output
> to the list. While you're at it you may as well post the
> AES and SHA results as well. Heck, just run the whole
> "openssl speed" test (should take less than 20 minutes) and
> post the whole thing. :)
> 
> Also details on what CPU/RAM it has, and information about
> the kernel and OpenSSL package you are testing, would be
> useful. "dmesg" output and the contents of /proc/cpuinfo
> may be helpful.
 
 Maybe a good idea to put the output in the wiki somewhere?
 
 Greets, Jeroen
 
 ___ 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
> 

- -- 
Sent from my thing that sends email.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSS366AAoJED/jpRoe7/ujyREIAKb2xTXWR8xLdVpj2K8Dub9W
jSuMtWycMgSW5nkJAOCwA+uJuX47/v7tzejNut1E76oRaAHwEn1fufiWGdT+Dbju
f4BycdI5Pl3NTRuYcFBas32+lbFeyw+gLClczUjfE+fe/pmHiaXAXra6Alai40z8
77B/xGQwrpVyla4S8JHP4CY/p6FHuI5JDs+ghvVESUEK2DHJdNt5R2oLSBy4ZNQw
BTzAf6qvflFUWhpWOkIkzIzo0c5FsJ/nYiVWpWyAjdV1NgufPdZ8ZKIoNx92iJBP
aD1G7h9fQh3E2AU/6VHPvPdekQ5NPzehXtH8ywNFMw16oFbXkZ6/eUYUpJ50YZ8=
=3Yig
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] MaxOnionQueueDelay

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

nsane:
> Hello,
> 
> there is a Tor setting "MaxOnionQueueDelay" in torrc (see 
> https://www.torproject.org/docs/tor-manual-dev.html.en) with a
> default of "1750 msec".
> 
> As operator of a Tor relay 0.2.4.17-rc (on Debian) I would like to
> know were I can find the current processing time for onionskins to
> set "MaxOnionQueueDelay" different from its default value (1750) in
> the torrc. Where can I find the current processing time?
> 

Is this tuning for high speed, low resources, resiliency...?

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSSuu7AAoJED/jpRoe7/ujfHAH/12UZbrAVeCiCdx/tM0f8mEc
vVmfSyh3hRoYrWgygBfOc+P2dqq46Bhn5I9NtS9chOYelHvg7BrZt8/CGz/c3vTX
ULgzbBJfdJesxylxhtsxo5Dhhwe119dIWbeuV6Vi3ZO9od2DAlKAVy/O2ZvjKDbx
TlB52RuCiBYpDaFtQ7U0thiyq/cO5RwwiwtDZB4qbShFiOVL+WcMSk4v9cT2+6U9
vl/MD+CgQNHagFCtQYm7PWwYYaT4UBbgE+y5FGrs/f56LCAKCCTrnN2gz8iy3xmd
v6uRTVghF5ff7UZ44VCnwv5y/lgWl4Kg12qJvELnktsrQ6jIsOKp4Eplojvc+kY=
=CQCp
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] tor 0.2.4.x on the Raspberry Pi. How to?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Martin Kepplinger:
> In order to run an obfsproxy bridge on my Pi, I need tor from git
> or tor's experimental repos; raspbian's packages are too old
> right?
> 
> I got confused with recent discussions on raspberry pi here. What's
> the simples way to run a obfsproxy bridge on my Pi and keep it up
> to date as well!

I can help you with Tor itself for Raspberry Pi.

Keeping it up to date will be a little problematic until the Cipollini
Project[1] can get a .deb repo together, but there is both a link to
instructions and binary .debs for Raspbian here:

1. https://github.com/gordon-morehouse/cipollini

However, I don't have obfsproxy packages - I'll need to evaluate how
it's packaged and replicate the latest ones for Raspbian.

There may be further instructions, if you want to avoid the 'setup.py
install' method mentioned by tor_bridge and stick to the Raspbian
package manager, at the link present above.  I know they cover
building base Tor packages, not sure about obfsproxy.

I'll add a task to the project[2] and do my best to get to it soon.

2. https://www.pivotaltracker.com/s/projects/917796

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSSusGAAoJED/jpRoe7/ujEe0H/3tZFZUJEITEjbeHRCI6VIOs
bSihACpZx/KH5OZbEAUSUOY7jI7kR2z/nXIO0eYepE4dU6hpSqi4yNQioL1nYPjJ
Rsb0VI4ozWP9czDJue1AxBbRbNVvG2iiWLdsnbYokNIwEKNK5uUWhogONfosrnFT
bks30kEAIqqNMGXWQBT67XRag0Z4mzxryYPe4SBTRwOVQAzu1Uy4GTJ4fO3zLVOa
PKppotsEhUvJQJSKyMArrndGZuJ5lD8tEXuseNCbLQsslWub6cmiLM5s5ZgWGINb
G1iAQajKtx2vOA9Tdv8bnrp7NAaqPSDNAjYe67wfhaowCnqRkXCapb1XuFSiHTM=
=Mf8+
-END PGP SIGNATURE-


0x1EEFFBA3.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] State of the art in NAT busting?

[Gordon Morehouse]

I have a question which relates to my ongoing groundwork to build a Raspberry 
Pi (and hopefully Beagle and Cubie) friendly set of Debian packaged programs 
which can turn one of these small, low-power machines into a plug n' forget Tor 
relay.

What is the start of the art in NAT hole punching if one does not have a UPnP 
or (other-standard-mumble) compliant router?  If I'm behind such a router, 
what's the best I can do to help the Tor network if, for any reason, the user 
is unable to port forward?

Sub-questions:

1. What's the best I can do without any outside help?

2. What's the best I can do with minimal outside help, e.g. STUN+ICE, TURN, 
etc?  Does Tor itself support any of those?  Could a Tor relay or bridge + 
not-yet-written scripts make use of those?

3. Are there any options I'm forgetting to consider, other than wholesale 
relaying of traffic (eg IP_A:portN -> hole-punched NATed Tor instance where 
IP_A is another machine handling some or all of the NATed relay's traffic)?

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] safeguard operators (was: Reimbursement of Exit Operators)

[Gordon Morehouse]

On Thu, 19 Sep 2013 07:45:17 +0200, Konrad Neitzel  wrote:

> Hi all!
> 
> On Wed, 2013-09-18 at 19:29 -0400, t...@t-3.net wrote: 
> > Also. It makes me wonder things when, for example, you say "Think
> > bigger" while pointing to a couple of potential dollars in someone's
> > pocket. Safeguarding the operators of the exit relays is a bigger deal
> > than chump change. I'm not making an honest accusation but, to the
> > people who are the most vocal in approving of this - you don't work
> > for the NSA, right? :)
> > 
> I am quite new to tor but I decided a few days ago that it is not just
> "something for people in far far away countries". I simply decided that
> I have to support this if I do not want to be in the risk that I am
> asked later: "What did you do when they took the control over the net?".
> 
> So I started a tor node on a dedicated root server. But now you scared
> me a little bit: Is there a need to be safeguarded as a tor node
> operator?
> - At least the hosting company might know me. At least it should be easy
> for the government to track me down even if I tried to hide because all
> they have to do is follow the money.
> - I even used my Name and Email address inside the contact information.
> Just check out the "idkneitzel" Node.
> - Reverse DNS even points back to my private domain.

I do all the same things, and only recently *started* using real contact 
information and my real name on these lists, as a principled stand.

> Was this something that I shouldn't have done? Is it something that I
> should change?

If you are an exit node operator, you have some things to consider.  If you are 
a relay node operator, likely far fewer things to consider.  Then again, I only 
operate relays and ran into my first website block (retailmenot.com) today due 
to the site blocking *all* Tor nodes, exit or otherwise.  :P

> Would be nice to hear your opinions on this topic.

You're probably fine, especially if not running an exit.  You didn't list your 
home country, though; I'm assuming United States.

If you are concerned, arrange transactions to purchase a server offshore with 
anonymous means and run an anonymous node there.

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

On Wed, 18 Sep 2013 18:28:18 -0700, Andy Isaacson  wrote:

> On Wed, Sep 18, 2013 at 05:43:13PM -0700, Gordon Morehouse wrote:
> > Thanks, Roger.  I'm still not sure what finally caused the OOM-killer
> > crash this morning after almost a couple weeks (?) of uptime.  I was
> > also seeing additional clock jump messages but didn't have time to
> > diagnose it.  The Pi does not have a battery-backed RTC so it requires
> > a clock set at each start, accomplished by 'ntpdate' and kept in time
> > with, in my case, 'openntpd'.  But, 'openntpd' wasn't complaining at
> > the time of the clock jumps that were reported by Tor, and AFAIK
> > 'ntpdate' is not scheduled to run periodically, so I don't know what's
> > causing it yet.
> 
> The "Your system clock just jumped 100 seconds forward" messages are
> unlikely to be due to NTP.  Much more likely the Tor daemon was blocked
> for a significant time period, due to swapping or similar.

I figured it might have been a really bad clock, but that seemed unlikely.  I 
wouldn't remotely be surprised if what you are saying is true as the Pi is 
pretty memory-constrained.  I'll try to correlate/reproduce it.

When the Pi goes to swap, it's getting desperate - it's swapping to a Class 10 
microSD card.  :/

> What does top show?  In particular the "Mem" and "Swap" lines, and the
> process line for the Tor process.  Here's a large Xeon server running 4
> Tor daemons:
> 
> top - 18:26:40 up 16 days, 18:18,  1 user,  load average: 3.79, 3.95, 3.96
> Tasks:  99 total,   4 running,  95 sleeping,   0 stopped,   0 zombie
> Cpu(s): 69.0%us,  5.1%sy,  0.0%ni, 19.4%id,  0.0%wa,  0.0%hi,  6.5%si,  0.0%st
> Mem:   8176824k total,  6361748k used,  1815076k free,36336k buffers
> Swap:0k total,0k used,0k free,   183736k cached
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
> 14567 debian-t  20   0 2003m 1.8g  21m R  109 22.7   4477:00 tor
> 30171 debian-t  20   0 2390m 1.8g  20m R  100 23.6  13544:10 tor
> 18891 debian-t  20   0 1800m 1.5g  23m R   86 19.8   3134:31 tor
>  8798 debian-t  20   0  324m 149m  31m S   21  1.9  36:48.05 tor
> 
> A similar picture from your RPi might shed some light on the situation.

*Typically,* tor consumes about 25-40% of all available RAM to handle 300-800 
circuits and 0.5-2Mbps of traffic (it boots with 485MB physical available after 
all is said and done).  It always seems to get OOM-killed when I'm sleeping.

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Reimbursement of Exit Operators

[Gordon Morehouse]

On Wed, 18 Sep 2013 08:10:25 -0400, t...@t-3.net wrote:

> The OP I saw said:
> 
>  The Wau Holland Foundation can currently only
> reimburse via wire transfer.
> 
> This seems to be end-of-story in terms of who, in the end, is 
> ultimately getting liability/risk, and points to practically no chance 
> at anonymity within our currently hacked banking system. It's not 
> related to taxation or what organization may or may not be trusted. 
> It's about what information is being gathered from the system by 3rd 
> parties for possible use tomorrow.

I suspect the methods of value transfer can be added to in the future.

> There's another perspective to this as well. Speaking objectively and 
> without knowledge of the organization involved, and nothing personal 
> intended. It may be worth noting that certain presumably-Tor-hostile 
> and well-funded agencies are known to infiltrate the tech 
> organizations/efforts which they wish to weaken, and influence them 
> from the inside. In this context, seeing Tor's exit node operators 
> being offered cash via bank transfer is waist-deep into creepy.
> 
> 
> On Wednesday 18/09/2013 at 7:38 am, Tom Ritter  wrote:
> > create or work with a trusted organization who is willing to shoulder 
> > liability, risk, and expense of investigating the legality and tax 
> > consequences, and then actually executing, reimbursing people through 
> > anonymous means.It's not easy. May not even be possible. But there is 
> > a rigid but not inflexible framework of tax law that must be worked 
> > within.

Bitcoins, until they're banned, from the entity receiving the bank transfer and 
delivering a middle finger to whoever's askin'. :P

> > IMO, this is net gain. Excited to see it happen, and congrats to all 
> > whose hard work has brought it here.

+1.

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

On Wed, 18 Sep 2013 13:16:48 -0400, josh  wrote:

> You may be able to increase the ip_conntrack_max on your router. I had 

I can, and have, but eventually its 16MB of RAM becomes a problem.  ;)

The bigger deal, though, is I'm attempting to cobble together a set of scripts 
and best practices to allow a Raspberry Pi model B (512MB) to be turned into a 
plug-and-forget relay.  Thus it can't be crashing consumer routers - even 
crappy ones - or messing up DNS or video streaming or or or.

> a terrible verizon dsl router that would have its connection tracking 
> capacity exhausted by pings to games servers. I was able to partially 
> resolve the problem my telnetting (yea I know) into the router and 
> setting the ip_conntrack_max from 1000 to 65000.  You might also want to 
> reduce the amount of time TCP spends in TIME-WAIT.

Definitely shortened the TCP timeouts at the router, with the intent to 
eventually move that into the Pi itself if feasible and useful.

> Ultimately I replaced the router with a pi based solution with much 
> greater resources.

My old WRT54G is pretty long in the tooth these days... still amazingly capable 
though.

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Reimbursement of Exit Operators

[Gordon Morehouse]

While I believe you have a good point

On Wed, 18 Sep 2013 19:29:26 -0400, t...@t-3.net wrote:
> 
>  Think bigger, say what?
> 
> Certain of the world's biggest and most well-funded intelligence 
> agencies hate personal privacy on the internet so much that they've 
> been going to extreme efforts to destroy it. They are packet sniffing 
> the NAPs and fiber backbones to pull out everything they can, they 
> hacked/broke HTTPS, they are backdoored into the big content 
> providers, they hacked the banking system, they are apparently 'in' 
> some hardware crypto chips - the list goes on -
> 
> They infiltrated the tech groups which were designing software and 
> hardware and sabotaged their work, making their crypto be 
> weaker/breakable and their systems easier to hack into. They use the 
> vulnerabilities they created to their own ends.
> 
> As of today, Tor appears to provide privacy, at least as far as the 
> .onion sites goes. Maybe it even works for it's entire function of 
> providing anonymous internet browsing.
> 
> 'They' would definitely want to be IN this thing, because they either 
> want to compromise it, or if that doesn't work well enough, destroy 
> it. 'They' are known to infiltrate and be influential in getting what 
> they want. Literally, they are professionals at this. 'Getting to 
> know' the exit relay operators and identifying their bank accounts 
> would help facilitate things when it came time for them to make their 
> move.
> 
> In the context of September 2013, this whole thing is scary. It was 
> perhaps not scary in September of 2012, when we didn't know anything.
> Also. It makes me wonder things when, for example, you say "Think 
> bigger" while pointing to a couple of potential dollars in someone's 
> pocket. Safeguarding the operators of the exit relays is a bigger deal 
> than chump change. I'm not making an honest accusation but, to the 
> people who are the most vocal in approving of this - you don't work 
> for the NSA, right? :)

this is probably about making it easier for big exit operators to afford 
lawyers for when 'they' come around using the law as 'their' tool.  :/  If your 
BW bill is paid, more $$$ to keep you out of jail.

Best,
-Gordon M.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

On Wed, 18 Sep 2013 16:43:25 -0400, Roger Dingledine  wrote:

> On Wed, Sep 18, 2013 at 06:50:46AM -0700, Gordon Morehouse wrote:
> > The replay has settled into a fairly steady state (after losing its
> > flags except Named) of sending 5-10KB more per sec than it gets.  I
> > have a feeling this is literally due to the TAP replies being bigger
> > than the TAP requests.
> 
> TAP replies and requests are both packaged in normal 512-byte Tor cells.
> 
> Typically extra write bytes happen because of people fetching directory
> information from your relay. That trend has increased over the past month,
> with five million more Tor clients online (and updating their directory
> info) than before.
> 
> You can compare by turning your dirport to 0. Unless you did that already?

Nope, but that sounds about right - I definitely am running the directory 
service.

> 
> > Sep 18 05:30:43.000 [warn] Your system clock just jumped 101 seconds
> > forward; assuming established circuits no longer work.
> > 
> >  Shouldn't Tor be shedding
> > memory if it closes all its circuits, not acquiring more?
> 
> Ah -- that log message about established circuits is talking about client
> circuits. It doesn't close circuits that it's relaying for other people.
> 
> (In fact, it doesn't even close all the circuits which it had created. It
> leaves open the ones that have streams on them, in hope that the streams
> will still work.)

Thanks, Roger.  I'm still not sure what finally caused the OOM-killer crash 
this morning after almost a couple weeks (?) of uptime.  I was also seeing 
additional clock jump messages but didn't have time to diagnose it.  The Pi 
does not have a battery-backed RTC so it requires a clock set at each start, 
accomplished by 'ntpdate' and kept in time with, in my case, 'openntpd'.  But, 
'openntpd' wasn't complaining at the time of the clock jumps that were reported 
by Tor, and AFAIK 'ntpdate' is not scheduled to run periodically, so I don't 
know what's causing it yet.

I'll continue to work on the Pi relay tuning, watch it closely, and report 
back.  It is working better than ever with the latest 0.2.4.x but starting to 
hit CPU limits around 2Mbps (with little to no intensive optimization, I might 
add).

Best,
-Gordon M.

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

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Addendum to addendum: the router fail is definitely caused by Tor
connections filling up the router's ip_conntrack table - once it gets
near full, it somehow interferes with a couple other services on my
router (especially DNSmasq) even if there is free RAM.  I will need to
figure out some iptables tricks for the Pi, which I've long known, to
prevent this, just no time yet.

Note that somehow, due to a brief enough hiccup I guess, my Pi relay
retained Named, Stable and Fast this morning, so as soon as I
restarted it it was instantly slammed with thousands of connections.

I may need to do the kludge of rate-limiting incoming connections to
the Tor ports for now, using iptables.

Also of note: regarding the ntp and time/clock issue: it appears that
because I was using a particular stripped image of Raspbian, some
spurious .conf and init.d files were left for the Raspbian 'ntp'
package, which I purged, and ensured that only 'ntpdate' (for setting
the clock at startup, run in /etc/rc.local) and 'openntpd' are installed.

Best,
- -Gordon M.


Gordon Morehouse:
> Addendum: restarting tor instantly puts my router into a tailspin 
> this morning.  This is a WRT54G (old school, 3.0 hardware, 200MHz 
> MIPS). While that's old, there are many, many consumer routers out 
> there with similar specs and worse firmware.  In this case it 
> causes major problems with DNS.
> 
> I'd like to figure out what is going on with this in order to 
> prevent it from happening as part of the Cipollini project[1] so 
> (when the time comes) we're not distributing images for Raspberry 
> Pi which crash people's routers.  :(
> 
> Request timeout for icmp_seq 847981 64 bytes from 192.168.1.1: 
> icmp_seq=61550 ttl=64 time=1.136 ms Request timeout for icmp_seq 
> 847983 Request timeout for icmp_seq 847984 Request timeout for 
> icmp_seq 847985 64 bytes from 192.168.1.1: icmp_seq=61554 ttl=64 
> time=0.917 ms Request timeout for icmp_seq 847987 64 bytes from 
> 192.168.1.1: icmp_seq=61556 ttl=64 time=0.929 ms Request timeout 
> for icmp_seq 847989 Request timeout for icmp_seq 847990 64 bytes 
> from 192.168.1.1: icmp_seq=61559 ttl=64 time=0.929 ms 64 bytes
> from 192.168.1.1: icmp_seq=61560 ttl=64 time=0.922 ms Request
> timeout for icmp_seq 847993 Request timeout for icmp_seq 847994
> 
> Best, -Gordon M.
> 
> 
> 
> Gordon Morehouse:
> 
> 
> ___ tor-relays mailing 
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
Sent from my thing that sends email.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSOcEIAAoJED/jpRoe7/ujY6QIAImt9T6uaH6OYIZsLkmNAwTm
3d+QyDVAz/tewS732QOqhnqqB4eMAnWsec7wNQB0ZmD5H1pkqFDlZqNxQqeAF/Zv
VNNM2IG8nCJGLuvkKE24ta/qpwpLAZY6LvObzTNh9IxYfIteMY4+zU06XRd5jS1J
QN5+RPMOAhL50kaGjVW65r2lDB5/XQdBEoIA3LI4yVCaEUCtBEzC3S3jlzPIxqR7
LVrBACMi0W6A43m3OMvxpejFWMahoATYiZVYmZWc/LysGgmyn70rav47rh9/0psh
gRvnHAF+5YHytgSrDxW1+H9fmA0PnAlbv8YGNkvwLCXGo39oChUc9W34Im9kuSc=
=x7pi
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Addendum: restarting tor instantly puts my router into a tailspin this
morning.  This is a WRT54G (old school, 3.0 hardware, 200MHz MIPS).
While that's old, there are many, many consumer routers out there with
similar specs and worse firmware.  In this case it causes major
problems with DNS.

I'd like to figure out what is going on with this in order to prevent
it from happening as part of the Cipollini project[1] so (when the
time comes) we're not distributing images for Raspberry Pi which crash
people's routers.  :(

Request timeout for icmp_seq 847981
64 bytes from 192.168.1.1: icmp_seq=61550 ttl=64 time=1.136 ms
Request timeout for icmp_seq 847983
Request timeout for icmp_seq 847984
Request timeout for icmp_seq 847985
64 bytes from 192.168.1.1: icmp_seq=61554 ttl=64 time=0.917 ms
Request timeout for icmp_seq 847987
64 bytes from 192.168.1.1: icmp_seq=61556 ttl=64 time=0.929 ms
Request timeout for icmp_seq 847989
Request timeout for icmp_seq 847990
64 bytes from 192.168.1.1: icmp_seq=61559 ttl=64 time=0.929 ms
64 bytes from 192.168.1.1: icmp_seq=61560 ttl=64 time=0.922 ms
Request timeout for icmp_seq 847993
Request timeout for icmp_seq 847994

Best,
- -Gordon M.



Gordon Morehouse:


- -- 
Sent from my thing that sends email.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSOba6AAoJED/jpRoe7/ujcsoH/ioHo/cDvMWI2hkeNrI72dHt
DI+NZBLo0XYSEKPy/IQNmnz1Ap3g/mBO686Ewr21hAiGNRPoZD4ALJovthWI0uC7
rc9ziET7c5P7HAso3y4J+3qhlZt40Hd8vuU83pfLGZQKDMOTukj1+qcY3xZSUz/N
0Ae6d8xgbGBiqbAqzNudBfXrERNdTvQvV6y/RCxPVWM9gBpt41f0CYZq7depcEq9
I33Sa6JpaLS+n3dXHj0SUtJvFjEz5Q4PyD5XmwPHWXmtQyAhNj/RZFNdwovaU1/P
AcwFdtrNZtkA3tDbhzKyAd2JlXgUlPcZZDDDBSHRREYi5DG/BpHqy0mxpzPXBU0=
=kdsB
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] 0.2.4.17-rc on Pi, a couple weeks on

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hey folks,

Here are my reports.  First the good news: it's WAY more stable.  Then
the bad news: it still gets OOM-killed once in a while, possibly
preventably.

THE GOOD (notes from September 14):

Here's my Pi relay since compilation of 0.2.4.17-rc:

Sep 14 11:50:59.000 [notice] Circuit handshake stats since last time:
13308/13324 TAP, 22/22 NTor.
Sep 14 11:51:51.000 [notice] Heartbeat: Tor's uptime is 7 days 18:00
hours, with 434 circuits open. I've sent 42.85 GB and received 34.05 GB.
Sep 14 11:51:51.000 [notice] Average packaged cell fullness: 98.369%
Sep 14 11:51:51.000 [notice] TLS write overhead: 9%


That low NTor number is depressing.  That high TAP number is scary.
TAP is the old way and the way the botnet is using.  NTor is
post-0.2.4.8, I think.

The replay has settled into a fairly steady state (after losing its
flags except Named) of sending 5-10KB more per sec than it gets.  I
have a feeling this is literally due to the TAP replies being bigger
than the TAP requests.  It's handling tens of thousands every 6 hours.
 Load average is steadyish at 0.7.  Unlike its predecessor, though,
it's not yet crashed under the new network conditions.

...By last night (18 Sept) it had settled in to no Stable flag, but
forwarding an essentially random amount of traffic that looked similar
minute-to-minute.  Load was between 0.9 and 1.1 with tor, top, and
nload being really the only active processes.  There is still room for
tuning with the Pi given that this load was attained relaying about
2Mbps when I looked.

THE BAD:

This morning:

Sep 18 04:50:59.000 [notice] Circuit handshake stats since last time:
34818/41100 TAP, 50/52 NTor.
Sep 18 05:30:43.000 [warn] Your system clock just jumped 101 seconds
forward; assuming established circuits no longer work.


The system clock thing is a Pi thing.  I'm pretty sure I need to get
much more aggressive with ntpd.  (Pis have no battery backup and tend
to have pretty bad clock drift.)

But then, 2 minutes later:


Sep 18 05:32:20 tulameen kernel: [2188444.188460] Out of memory: Kill
process 7544 (tor) score 148 or sacrifice child
Sep 18 05:32:20 tulameen kernel: [2188444.188475] Killed process 7544
(tor) total-vm:153352kB, anon-rss:115156kB, file-rss:36712kB


Coincidence?  Bug?  Smells like the latter.  Shouldn't Tor be shedding
memory if it closes all its circuits, not acquiring more?

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSOa+yAAoJED/jpRoe7/ujs4UH/iXK4+hAAk06nYUptKChGRyx
boZxDxpNum4uEzkJNZlUdvUILuVLX2DXytN7kNJUKDYKGzwCwBhhcQ7tOyBFucz+
muVcbwgyjM8zDhMFexWX8wVh7lauJRpjcNxzE+5hVRkzMFrbGy7FLXZbTiNGT5Ez
cSfZAziu0Au3OKhxLQMUdYiZtfi/b/ReMIx72Xz4pBX4hPiagORG5NPgKpNzeBij
C+khy5up1WuE7qxGX8+zG1T6K0whAW6MFYKdIT63GlwVWzYAP7tZDbbQd3kB46Yd
e5I+ySBGL7VnOzH6CQl+2l1enu87JDyZ1Hw6zkZp3GQ6u8ThiHQQvmNQx9N3rxQ=
=sx6s
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is quite a story - and I've found 0.2.4.x on the Pi to not have
nearly the problems of its predecessor (and .17-rc to be a lot better
than .16-rc)...

Dan Staples:
> Just to add my experiences to the mix:
> 
[snip]
> 
> Finally, I noticed that bandwidth-related config options had no
> effect on the 3 Mb/s traffic flood during the circuit creation
> storms. I had:
> 
> RelayBandwidthRate 200 KB RelayBandwidthBurst 200 KB 
> MaxAdvertisedBandwidth 200KB
> 
> ...yet, still 3 Mb/s traffic floods. Even MaxOnionsPending 250,
> NumCPU 1, and AvoidDiskWrites 1 made no difference in my RPi's
> ability to weather the storms. I eventually had to use QoS on my
> DD-WRT router to set limits on the traffic it would pass to the
> Pi.
> 
> I will try your builds of 0.2.4 to see if that makes a difference.

I guess maybe TCP handshakes could've made up part of that.  If this
is the case, it's a (low priority at the present time, I can imagine)
bug where load on popular hidden services should be distributed to
Guards more effectively.  I dunno if there's a ticket for it or not.

BTW, my builds so far contain nothing special, they are textbook
builds from the Debian source packages but done on a Raspberry Pi so
the armhf is runnable on other Pis.  I will likely start experimenting
with tuning in the future.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSMU7dAAoJED/jpRoe7/ujn+oIAIShPPNyRAOHyri2TuelvnnB
eITzVtngjyz7b+Y2i0kZYqJH5ELWHjjDbd2pRx8QusU52Qb1wv5nxdIYJx1Uj9Q5
vTEOAlNiAZZVKuZPc7p3y1lPmEUppLlNXrYeTFsMDRSiLBejJSgRWjWJsZa1kyqk
MBN4qSvWbTwO9ZVhYCnLuO82KZADNEx1otLSHQ07C/KF3K0MpqM4D6aiAHuQhiv5
hGOGRI6h4JPWuVs2e1xRwot8U1tZY5t19EB+TXRppGUSD6HOA5ZJnFpZRaI7ZUBZ
3stkHuqPCqpUY6BYBvElAhBmiNlX07QUMT1alxA8MlCywsHa9BOlzQiRf9kQhmc=
=obAy
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roger Dingledine:
> Hi folks,
> 
> I just released 0.2.4.17-rc. Hopefully there will be debs of it
> soon.
[snip]
> Please consider upgrading. If you do, though, please also keep an
> eye on it -- it's possible we introduced some new bugs and the
> network will start dissolving once more relays move to the new
> version.

Couple days now - Raspberry Pi (armhf/ARMv6) version showing minimal
to no signs of strain, botnet or no.  Also, number of NTor handshakes
often in single digits, TAP handshakes in the mid four figures.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSMU3mAAoJED/jpRoe7/uj5SsH/2KjW1WeXHeVB0EAdEIXTx0K
3ACat1RCRocmjtSTuv1O/u2hZZiu9RP3LaePmXwc9DSURJ2dVesdRigzk+GOG4bI
h0wEjKKWWsUsr+AAeYu3GEbdVB4F9StotOqLipGzGw5yywNvHeKzT3ZDyYJg1ex8
tq+h9I8COd+Y8cZFbBloyU2lXCHKcAsfL4BNWUWASB1yj/tvZDiWZUuZjHB5S+yk
MO6TX211a+yNcNTQOct2acBqofF7NCUu66r/XZ5fYatMt5ofZvEQJHNEjE6vklxe
phZXuYnur7OfFxB7MLFCV5Zpujhv2LPi7fTu7HTO3NuHNzHx8A1YUcVbvX1C0Y4=
=kiOr
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roman Mamedov:
> Can we have a torrc option to make a relay NTor-only?

Hi Roman,

I currently have my 0.2.4.17-rc installations set to this:

UseNTorHandshake auto

Although I can't be positive it was related, I first tried a setting
of 1 on that, and had to eventually reload the relay's configs after
changing this to 'auto' because it was stalling at starting up - seems
a lot of the relays it 'knows' to talk to (or whatever is going on)
still don't do NTor.  As soon as I did so, it started right up like
normal.

So, we need 0.2.4.17-rc and higher relays out there in much greater
numbers first, I think.

> Could help on some CPU-limited relays like the Raspberry Pi or (in
> my case) Intel Atom.

I think so, once it's viable :)

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSK2YEAAoJED/jpRoe7/ujxvgIAJLuM/Jns4ndKnLojxtYsDdE
lS3PaBzybjkVIIhhwCkzFOti080JwaNa6gAKqHZd7duHyoH2aJHPhhBhEUh/9TXh
tADj4R0FU7PdZVmKX62L+GLDvTWVKLcRl7w+PlSSE+qC1fK9yHfoSKSNJPP0JAXf
i1go+jqxU9RUm4VYE464fU/XYa0TGDw53Vgbct3Xr3INE/hMxyox8XEfxdSlUgGh
IZUNQqBYbISOpq1O51ERiFmHir2G5l4htKmsfXEhwkAndXatCeWr0tFQ8moHu/0Q
88MNtCPwRbU+ixPTROinmFpr9LVUq17p/of8Wtp8EtaiJkUerjzXKmRlygXI5Yc=
=Qmko
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Raspberry Pi / Raspbian tor 0.2.4.17-rc binary .deb packages

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello folks,

I've built binary .deb packages for Raspbian, the Raspberry Pi flavor
of armhf Debian built for the Pi's ARMv6 chip.

You can get them here, or find instructions on how to build your own
from source if you don't trust my build.

https://github.com/gordon-morehouse/cipollini

I haven't made any changes to the source itself - no Pi-specific
optimizations - just built it on a Pi to get ARMv6 compatible
executables; Debian wheezy armhf is targeted at ARMv7 and up, for
those not familiar.

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSKm1tAAoJED/jpRoe7/ujjO4H/RfvL2PbUV48lbzLyyD4vuxH
FmQdGNSGLyI2u6E2rbugpr5Y2OUVLZDXdPmbypen5rGEgKy73vOSjaoOLLiSu3+w
VhOtoKZl4NvHIXFlU+wGddK51gZneUIpiARUqBry9vjglYoMaRHvOEaHrQrUb00f
ioBxCgNyP4bLESGECPwIgT5X6PaISATin9fghGTQHQ84F1Zh2Kt7aViMK2RGxJRS
WJdZ/PxURHC30uaN5R+KBNgcKHoZHIYTRqAhuD0bfcJbhgEAxDAyxBHB2bSzQOsi
fW8IyXLrBshsHAllJZdt6wgcDarRUsMX6G6Y7SuvvNEwG4zXSU+2RnZaWWDygfY=
=qxGc
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrade your relay to 0.2.4.17-rc?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roger Dingledine:
> Hi folks,
> 
> I just released 0.2.4.17-rc. Hopefully there will be debs of it
> soon.

I will get binary debs for Raspbian completed this evening, and this
time sign them with my public key[1] for anyone who chooses to trust
me.  It's quite easy, so I'll post a README about building from
deb-src for those who don't wish to trust my binaries.

The instructions are already on the Tor Project web site though.

Thanks * 100 for your work on this.

[1] 1EEFFBA3 - also attached below for your convenience.

Best,
- -Gordon M.

- -BEGIN PGP PUBLIC KEY BLOCK-

mQENBFIIHWwBCADSkqB1JQtrMnHAigieI4uhOFE4klu6OSr1pMVkYdI5LMkTc9kG
dG/MnFrixOCR3X8tD4cFkPKPT1coxRNzHjcazhpz+ztnUXVEMt1LARVreh+Msl02
b6VaONIjJT8aJFf+9ysS1Y/esP5dwrOW9NdPD8TwE7Po17ZrEiJQ8Sb2hNOAvnLe
AuG3h9A7BCe3//RRqBUv7Jc0VIjhnG0deh5e7IF+FY+1llamKZtsPRJMriGhGcmw
f9vSmILVocpie41wAS60rHFeoI0zQJKjo+3SZovlJI/OW7CPrUDN3aJ+hXRVGYm6
HrTgdYKSb4obcQ1yiB+UZoP//U+tUVxPIQBHABEBAAG0REdvcmRvbiBNb3JlaG91
c2UgKGh0dHA6Ly9nb3Jkb24ubW9yZWhvdXNlLm1lLykgPGdvcmRvbkBtb3JlaG91
c2UubWU+iQE+BBMBAgAoBQJSCB1sAhsDBQkDwmcABgsJCAcDAgYVCAIJCgsEFgID
AQIeAQIXgAAKCRA/46UaHu/7o5d0B/0RyKF4SCi4s6VOV6XTE4RjPUhJtka7YnOj
bjcHEvS976/2oSbcemV8zxJUnLzO0TqgI8nCdddOGS+37sBt7+CXXis8XVneoSly
1r7Fx8vOPY/2dZjDb85uMLpUMBXWyHMLrG32yIud1UduC+r2MqelZq0loflTpk9d
ghiYexmY5iMdEDfegAsOXPh7KzNHipeG5bjF0ohrWJUF7F3utdGBrTuitvuyO59q
EDKBmfqPEonl7z+2HHPViWyaa0bw9q9Ee8Eb5CYjWLp/8KbKX6edKsIaVsuN0R+T
h2J0cB3Hq/+Z61Q8DvqukRrpqyCkyz32Z39IF3kKeU/yni7fREhwuQENBFIIHWwB
CADXMjO1xsvN30Dkt8qL7C7VYw8xOTgoT+tfIpjOI2daB16QGSxL3hvOj20ZbfRg
4J3m+VuxMz76/PhwhzaeRB3lmnzAXUGdFaTuUehWh+WclU9EXS2mR9zPbP2OJ4QL
uCtCa0XkHHoL8NhVH/57mXnsW4vsN/DSjPTUvCwnsbHhmTIYw1zV8x+R7YUb/0mN
rToHHqGREYK9THt1jby/LRVKEe0ARrKHeMyY3E5vzhRK+M6Nv2m6BYhtc1Y3kcLT
iQ58K5d3feAy28QUM9CC713D7czKtz083Apst9lpBFMJQ/arhuOFzK4a2BugwFq7
ih31Af53VWPGMRYDVCraczklABEBAAGJASUEGAECAA8FAlIIHWwCGwwFCQPCZwAA
CgkQP+OlGh7v+6ORCAf+Ka11bi/HCxc136cSHI9F5k0kfFZgZFUirfdB4MpTvxUb
MQfkL/HJv5UQdG7qKmf4pLnvu7D/2aFmttlCgNxQf4f01fQXZ14rqw9xrXC6+bg6
mzGv+rZz+UTxTn/saIX+TtZ9GP+AXM+aDgOgk7kUCZcreGQMdzX/rkxj5fi+AsM5
mKDsq29VImL45xGAp+7W7JF9xDTAdEC68yX1YU1rwiSUCRpHn6KlfRKcAXYZAiaG
KP7R0WLdrOIx3urheYNgkgiPOe6pKMwq25FAiWIa/BGZuJWhM2VoQbLaY+n4R0qe
D+CF7JLDj3HHMwMUb+soYhT07Td7vRyXK2ka2Oi7vw==
=xWdW
- -END PGP PUBLIC KEY BLOCK-


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSKLczAAoJED/jpRoe7/uj1F8IAKmEKEszzhaPjuVefoGMvcUX
Yq0VVIXXYfB2PrWtfgY2T0VPe5AaFN3VZNgtNLSJOjGzrx+nJg6Oq2uVd/rKu+ML
RYq9kmH0WiE8b9cu/SPBAu/7BgKGWUGHH9tOGrQPI1ghdOgM1YpvKTObve3mdhzz
KaMOLb0OTTBjyCfuBM+AoY/EwwO0TaeNiOqnCAxWgcAvHUhDxYmBQcjrBUGlqvhw
eAuZ9dRa89U/xW3dsRJXncRY7LJ79k4NXwanz4hR90nrEfNEZHTbLk0paoDd8IDK
blN5gSE2Oalj6hWz5VywwcmFTMeZD8sXDCrF6S/y/1RDOJqhb4JX1ICcNEp28LQ=
=Mqt5
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Status of UserspaceIOCPBuffers ??

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So in the documentation:

UserspaceIOCPBuffers 0|1
If IOCP is enabled (see DisableIOCP above), setting this option to 1
will tell Tor to disable kernel-space TCP buffers, in order to avoid
needless copy operations and try not to run out of non-paged RAM. This
feature is experimental; don’t use it yet unless you’re eager to help
tracking down bugs. (Default: 0)


Is this description still accurate, or is it better debugged nowadays?
 Would this be useful to set on machines with limited memory
resources, e.g. the Raspberry Pi?

Thanks much for any insight.

- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSJMrDAAoJED/jpRoe7/ujZX8IALXnFOs6WEQsud4UChnjdDRC
Cor6LScDdXjGBvRDodMxyrF6lX50SwIaBR+zu4I4Hw2ekit8UZdBdZafWSjQgq5W
KdMW1XruYBEIN2OcWSjSoZ1K2DzuOr1O77JwBhCuRcJtqqIP5yfD2TcF6AmuxHWk
82is5XCppem1b3CVobduKIVvbC6vUu+3fau5jkwrRv0xVQGTEtSWRY9TDFP5hoxB
cZN+N2yYAm0pZ9+X1fFOHteKOx9r8ENsHfSCeZfKJXbbeRmklxVnZ1k3AgU2BiET
L2tVs/piMOkhOd/hGX59bRk/IyvxArmXxd5+Vq9ejLZa7nmKMuOfZYbKdGo+zlE=
=b1Os
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

tor-admin:
> You could modify the tor init script to limit the memory usable by
>  /usr/sbin/tor as described here:
> 
> http://jlebar.com/2011/6/15/Limiting_the_amount_of_RAM_a_program_can_use.html
>
>  But I don’t know if this works on RaspPi platform and what happens
> when the tor process hits the memory limit.

Thank you, I may mess around with this - what I'd dearly prefer is a
torrc setting though.  Maybe I should search for existing feature
requests and/or submit a new one.

[snip]
> Is there a way to give Tor a hard memory cap, so it won't chew up
> all available RAM on the system?

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSJMWtAAoJED/jpRoe7/ujEQAIAKWnkP3OfemDbxcmhJJr/rIW
65Hpa8gQl9S5z1OoQXLKHEnlIziYj8UJbWM2+ADsJJReAHtWSMAb8ZL7MLSn5wR8
hoTtsQJ+ZjXPP0M0Yiqgwb2HRUcWYuarGOseLzWUwsBAy3g0ucsDrnDhwj9cGPdB
AAa4g4JJ/k5jW1N8clS0WIVJLnzDs4xYbxZzaLc54yQqawS4bybJUqjghLQekVdo
wETMVK4Ajoip2Le1gDGevcO+0a6Nl15QLNdIkGSY7n8vRjQ1gvNpMIDt2CM+miko
lwiWMy4OMbEQkDqKN7nkR15gLDoHsjgp37EbJn5im5Nfp/aNGMNGj8bWv0oi8Is=
=G9Rh
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] huge increase in relay traffic

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Richard Budd:
> I've been following your Pi thread, and up until yesterday I've
> haven't seen any problems at all on mine. Of course it's only
> running 2 meg bandwidth total. So I thought that might be the
> difference.

Yes, I have 3Mbps outbound and I currently let the Pi burst up to
about 80% of that or so, though it rarely sees that much traffic for
long.  It's still pretty variable, especially when I lose my Stable
flag.  :(

> Then last night my router (Asus Asus RT-N66U running Shibby Tomato)
> became very sluggish. Log showed pages of"Tomato user.warn
> kernel: nf_conntrack: table full, dropping packet" So I increased
> Max Connections and Hash Table sizes by about 50% and that has
> seemed to relieve the router problems.

This is a common problem with Tor and Bittorrent and especially the
combination of both.  Just be aware, many router firmwares aren't too
smart and will let you increase the size of your conntrack tables past
the point where the router will run out of RAM and start killing
processes, thus necessitating a reboot.  This includes whatever
version of Tomato I'm running.

> Top shows Tor using 60 to 80% CPU. But it's not doing anything else
> so I'll let it run till it gives up. (it's been running for over 70
> days)

Maybe you could enable the statistics keeping that krishna e bara
suggested[1]?  I haven't peeked at them yet to see what they look
like, but they might prove valuable to figuring out the Pi's limits.

In my extremely constrained free time I am working on purchasing a
small flotilla of Pis to deploy at various friends' houses and use as
a testbed for my "plug-and-forget Tor relay on a Pi that doesn't mess
with your video streaming, games or torrents" project[2].  So, I'll
have to eventually look at those files since they'll be useful to
*me*.  :)

[1]
https://lists.torproject.org/pipermail/tor-relays/2013-August/002590.html

[2] https://github.com/gordon-morehouse/cipollini

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIqYBAAoJED/jpRoe7/uj3zYIANHpgLJLu2Xkk8cmy4YL0bFE
Z+N8x7DQ1teOn1hUso1k0b0kFHlPOaSNLwccQ31JRyQyN0NbWd7AN2hw+jwryX5J
SjLkJibZEP30OBqpXfs1tcb0aghbofCVZlHEn8H7SpcEdflhFBE4tiGPVKWiIT5j
vhahUvFqH3jugwhRTnr68E8oMsCKNYCwgh1AI26lxqJD25lmNmZi38mwNgpByx44
NTUPHD0xToGxkAvlgYAvfkKNIjI/kLMy51qgSTjupMzr3Qjxq6HxnaSORGMlMPga
FGxahifwFMQLyvJ1L1lvZyBNWx4YP8gXIBNoSWmwYRFd6RzHU+poRua9WH5SkTA=
=eDJm
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Roger Dingledine:
> On Thu, Aug 29, 2013 at 11:30:33PM -0400, krishna e bera wrote:
>> On 13-08-29 10:35 PM, Gordon Morehouse wrote:
>>> What on earth is causing so many circuit creation requests in
>>> such a short timespan?

[snip]

> As for the circuit create storm phenomenon... if this is in fact a 
> botnet signing up the million new users, and they're connecting to
> a hidden service C&C site, then I would expect even fiercer create
> storms.
> 
> See also https://trac.torproject.org/projects/tor/ticket/9574


Hi Roger, and thanks for taking the time to respond.  I've definitely
seen an increase in the storms compared to the baseline I established
on my Raspberry Pi after upgrading to 0.2.4.16-rc; but so far only one
crash.  There has been a ripple or two on my bigger VPS relays.

If I could bug you for a sec, I do have some questions about how
circuit creation works in Tor.  I hope you have a moment to answer.

The full message is at:

https://lists.torproject.org/pipermail/tor-relays/2013-August/002589.html

Here is the main set of questions (the "numbers" are in the full message):

> My main question:  How do circuit creation requests on one's Tor
> relay cause load on one's network infrastructure?  Is it DNS
> requests?  Is it TCP connection state entries?  It's not bandwidth,
> we observed that above, and my router can handle far faster pipes
> than the one it's on currently.  The DNS failing is a sign that the
> router is under severe stress.  Back in the 0.2.3.x days, I often
> had to reboot the *router* after one of these storms, not just the
> Tor relay.
> 
> And again - do we really know what is causing this?  Something
> seems seriously wrong with the kind of numbers I'm seeing coming in
> to a node with MaxAdvertisedBandwidth 250KB.

Thanks much,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIqe3AAoJED/jpRoe7/ujFKsH/A6zDg7QnvWF+n+hqFFao890
RO6BqcVnwgfqYaHNvgeQy+8IX16OT+4ccdmXWqAqa7LoJKTzXkAG9X2pQ60V5wNx
PfeXR/sf9N0ZEiQFrC4mhJB+n7RImjiDflpgMKZnVUnGdalRG/b8ht2hpcAf/PfE
RCqPn0DzEwOQUav8sG1pkc0Ii3iu1Xuo288lHjwElXEBo6SSMZ21X2EPUxJPCFtd
Qp4TJ+pVYf6RJPX1amYdEbVcAGlIYELVXo4opSiqc4Bklng2vrZYwwpUU2KRWjqx
Fq3CcKa+naXFm4JZXn8FtqrEb8LZhObOFDrjD6MlxPuwBL0GN9SOrV205ByJ+Sk=
=s+9T
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] huge increase in relay traffic

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Richard Budd:
> I'm seeing the same on all 5 of my non-exit nodes, they are spread
> around the US and EU. It seems that they all are running at close
> to max bandwith for the last several days also.

My guess is whoever is running the DDOS[1] figured out that they can
most cheaply disrupt the Tor network by creating bogus circuits (and
eventually causing relays to run out of RAM and/or CPU) rather than
sending reams of bogus data through.

Whether that's true or not, my experiments with Raspberry Pi relays
provide sort of a 'canary in the coal mine' - enough circuits and tor
*will* consume all available RAM and be killed, as happened finally to
me sometime in the wee hours here.

[1] I presume it's a DDOS because a) come on; b) look at the graph of
clients connecting from Vietnam.  ~0 to ~5000 in a week or two?
Yeah right.

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIjPeAAoJED/jpRoe7/ujuUsIAKRCXz51z+/5MRywfYA48ySi
4325YqSdjzl8mhDKmpOOohhUTMTkCPJvDsD4BC8JyoaEk4cDDdsKMOwPUx2szvAr
Vhkh7rwMqYuDR/nkH+E2w9CVPFgo8BeVbuRSuewX/vvVE4nAS1m4ULB3ffA3EYko
dC9kFN9vf1uFb8lMGu6rVAULm6f8kzWYMGZ0uaWat6qQ4x45kWLxt8Y3caHESk3U
2tpLLAOLT7nhqGC1ALNOEm3gmox1xRFQM1vaYUdpIGb4hhkRKtHEXj+J00Mp0sPH
f4QQhPv+nUbEKamJD45MItU34Iv6zjTJVx9TP5ZkZ1qpa835YsknXaSXpjUe0Yg=
=UjmG
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

krishna e bera:
> On 13-08-29 10:35 PM, Gordon Morehouse wrote:
>> What on earth is causing so many circuit creation requests in
>> such a short timespan?
> 
> One possibility, if i recall correctly, is that the Tor that comes
> with the PirateBrowser bundle is configured to build single hop
> circuits.
> 
> Make sure that these defaults are still set in your relay:

The DDOS - because that's what it obviously is - managed to kill my
Pi-based node last night, so I've finally restarted with all these
except RefuseUnknownExits 1, just because of your caveat.

I had some of the statistics already enabled, so it's continuing to
collect those.

Is there a way to give Tor a hard memory cap, so it won't chew up all
available RAM on the system?

> AllowSingleHopExits 0 AllowSingleHopCircuits 0
> 
> You can also try RefuseUnknownExits 1but maybe auto is better
> 
> And these may help sketch the circuit storms: EntryStatistics 1 
> ExitPortStatistics 1 ConnDirectionStatistics 1

Best,
Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIjJoAAoJED/jpRoe7/ujuicH/Au5NXr/q5MTYH54mPPuE/OJ
9jOkT/M34O0+U9gqYH8ja2gzTFf3CdxESraS6A7A+r2DWUX9R6l+zia5YX/SYCUu
dWWNB843vXhcjNqhw01h05c70QgKStKrm6sLCjliVxhcovfMnkmMxLxk3EmQ3OzW
nOdHQT2QGV+xCXqYz7FS9OtCnRmjTjI3bb8PJ1xcL76IjPGlCKr5vt7cDO3Y7x80
o0hnPJxMhYs0MhS5sNXfHIifDNT6LlCuZvIT0GLe3w9Gg15BUYKgn5bi1iNEtoSV
J/2DbxvmT23Tv6E2WnpxEoOu/yupbHAiDcYbwIT1ig4mePA/xCgjdm7mEdqrXpE=
=AiLg
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Andreas Krey:
>> My main question:  How do circuit creation requests on one's Tor
>> relay cause load on one's network infrastructure?  Is it DNS
>> requests?  Is it TCP connection state entries?  It's not
>> bandwidth, we observed that above, and my router can handle far
>> faster pipes than the one it's on currently.  The DNS failing is
>> a sign that the router is under severe stress.
> 
> Possibly your uplink is full (supposing you're on some DSL), and
> is starting to build up ping time; then DNS requests to the outside
> can start to timeout.
> 
> Andreas
> 

Unlikely - I do pseudo-QoS such that my uplink should never be full.
It's possible, but I believe it's more likely that my router is
thrashing for whatever reason and starts to be real slow at responding
to DNS.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIi9ZAAoJED/jpRoe7/ujL2EH/0O7HxgB/g5nEKFxgz114cYC
gnlNzKXc2xUYZ92vv7BnNwuZ6TuFvW1qNBXT+9T1ObYWngnn/e3Jz8QOF6axmTd3
C+l2asKurD6M4dqkY53miLzrd783JTkgiPYaW6bNdFrmy+hzYjTbHuShccFYgncb
SWRXIMk6OXDqLhCyMAUjlR6Dd0yq6uJMAefmgLyEc9stvrRcrK8de0xD2/qVnHCi
RNJVQXAjKk5NvOIiONBilDl1jQsGgUkENz0Rh9naN9tjOE+Ev0lWbhUZpA09+2is
T2/IbXQXS8m9c4KfL6Z+aSufD9ALjQrYLNQBs6vzk+SEl4ghyCoMOMzPMGS2JvE=
=z+Zl
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ExitPolicy reject *:* ships commented out?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The friend was upgrading from Tor 0.2.3.x to Tor 0.2.4.16-rc.  I do
not know whether he used a tarball but I think it likely he used the
Tor 'experimental' repos as his VPS is Debian-family, and he said "I
couldn't keep the old config"; thus debconf likely presented him with
a choice, he accepted the new config, edited as far down as he needed
to turn relaying on, and that's it.

Since the default exit policy is for a relay to be an exit (without,
even, the benefit of ReducedExitPolicy), his VPS was shut down in
about a day as he'd unknowingly turned himself into an exit node.

Partial user error, and partial - as he would argue and so would I -
bad defaults.  This guy is a software engineer who had a derp moment.
 I wonder how many less tech-savvy users may make the same mistake and
then have a bad time and never relay again (or be subject to law
enforcement action, particularly in hostile countries).

David Carlson:
> I am confused by this thread.  In fact, the specific downloaded
> file that the OP is referring to is not named, nor is it mentioned
> whether it was installed 'as-is' or with a modified configuration.
>  Then a follow-up message refers to TBB, which is not even a relay
> package. David C

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIjFZAAoJED/jpRoe7/ujkPwIALCTA0q7/BAxn3E9cfQdjqpJ
SrHJGXMmIgQlmC98b1VfpoUmmsaz8dlhHfngl1CW230exhMIKLbkXOMAlzlgIowP
YfyMmdTkcx7fWg0jvFYUGMEbJP1k5thN+IYWJEQ1Myh67UTgL8gsclNmT4utH4bu
96COXJLW8i20iegTmh8qMqEQD0au2bj0Y0iI/dNRqHEF2U/XOIal3yE7HDAUUWPL
VlmHWOrh6uuKKCp9/iOrmh0ZzVm1TQDQ2eYVdA2ciLHpecAXIIyRFRtXceZRm3Kh
7HNqosenW+9ecszGkQc0XZerCVUI/bWAfv1EmrgYbz4PNjZlzCy/RNfc91EgiDU=
=IdH9
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Since I originally started keeping an eye on these on my Raspberry Pi
relay (read: slow, resource-limited), I've got to wonder if the
circuit creation storms I was seeing months ago weren't normal network
phenomena but some kind of test run.

We are talking going from 50-250 circuits to thousands of requests per
*second* out of nowhere, and then if the machine survived it, the
storm disappearing as suddenly as it came.  This was happening months
ago, but less frequently and only on lower-end hardware.  Now it's
happening everywhere.

Even if the previous case *were* "normal" Tor network operation, I'd
say it's a bug, but I'm suspicious that it was whatever is going on
now in its test phase.

t...@t-3.net:
> Also see a repeat of the odd log message with the 154.x net address
> someone else described with the huge hexidecimal string (40 hex
> chars, + sign, 40 more, on and on).

Here as well.  I believe this is the sign of an overloaded Tor
directory server.

>> Over roughly the same time frame I received an incredibly high 
>> number of spam e-mails in one e-mail account that normally gets 
>> 20 or so a day on quiet days.  Perhaps this is another example
>> of mal-ware in action.

Funny, one of the dropped connections during my storm last night was
to port 993... :P

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIU2zAAoJED/jpRoe7/ujMm4H/iruokRzfasoJy7jdXF0bMJT
5W94DUUzZJV+XbJIr208PxKFmElOUKLP/L/1Dqlx8csPFqqi6pN4yvBC26QMgxhh
lrcnyV0PaUAc8rwhK9cVKwl/JIoxsHFxpxL1fJBAbO9vzyr5XxKyCwiSNuIco7ip
RZEQc8/3pr/TsivTWUwSNcFtDUiFLi7+IrvGcPNG3bSbOfLhXzzfQ1SILzoy4ddm
jFW31hw/O8/J/P0XC2SbH1n1NsW7GdhhOQMoIx66d/znhy4ir9k7vdcq4MNoYwTx
SSGZc6HcZysmG78fMe7Eo00kv5sLygZnkGhZkFZEzKcjaKJoopFqnCLd60iW1lQ=
=SaO7
-END PGP SIGNATURE-


0x1EEFFBA3.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] A bit more evidence on circuit creation storms

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

So, I started having "tubes clogged" problems this evening and
realized, finally, that my Raspberry Pi powered relay had been
weathering a circuit creation storm since about 18:11 my time.

tl;dr main dev-related questions at bottom


Aug 29 18:11:03.000 [warn] Your computer is too slow to handle this
many circuit creation requests! Please consider using the
MaxAdvertisedBandwidth config option or choosing a
more restricted exit policy.
Aug 29 18:12:02.000 [warn] Your computer is too slow to handle this
many circuit creation requests! Please consider using the
MaxAdvertisedBandwidth config option or choosing a
more restricted exit policy. [2692 similar message(s) suppressed in
last 60 seconds]


First off, I'm happy to note that the Pi is far, FAR more able to
weather these storms running 0.2.4.x, even without the perfectly
optimal OpenSSL (all jokes aside about that particular combination of
three words)...

Secondly, the number of messages escalated.  Here is the worst:


Aug 29 18:38:04.000 [warn] Your computer is too slow to handle this
many circuit creation requests! Please consider using the
MaxAdvertisedBandwidth config option or choosing a more restricted
exit policy. [18258 similar message(s) suppressed in last 60 seconds]


What on earth is causing so many circuit creation requests in such a
short timespan?

Again, a Pi-specific note - on 0.2.3.x, the Pi would have crashed or
Tor been killed before this number ever reached five digits, so
0.2.4.x is better!  I has a metric!

However, note that whatever is going on starts plugging up the works
in Tor itself:


Aug 29 18:18:36.000 [notice] Tried for 129 seconds to get a connection
to [scrubbed]:993. Giving up. (waiting for circuit)
Aug 29 18:19:04.000 [warn] Your computer is too slow to handle this
many circuit creation requests! Please consider using the
MaxAdvertisedBandwidth config option or choosing a
more restricted exit policy. [7190 similar message(s) suppressed in
last 60 seconds]
Aug 29 18:19:14.000 [notice] Your network connection speed appears to
have changed. Resetting timeout to 60s after 18 timeouts and 172
buildtimes.


I assure you, my network connection speed didn't change.  I still
don't know how in the Tor protocol a circuit creation request is made,
but maybe it was them gobbling bandwidth.  Probably not, though?
There was an increase in average TX/RX bandwidth during this incident,
but not to levels that are in any way out of the ordinary for how I
use my Internet connection.

However, it's still causing trouble with my router (which is running
Tomato).  Check this out:


Aug 29 18:56:14.000 [warn] Your computer is too slow to handle this
many circuit creation requests! Please consider using the
MaxAdvertisedBandwidth config option or choosing a more restricted
exit policy. [13867 similar message(s) suppressed in last 60 seconds]
Aug 29 18:56:40.000 [warn] eventdns: All nameservers have failed

[snipped similar "too slow to handle" messages]

Aug 29 19:05:19.000 [notice] eventdns: Nameserver 192.168.1.1:53 is
back up


My main question:  How do circuit creation requests on one's Tor relay
cause load on one's network infrastructure?  Is it DNS requests?  Is
it TCP connection state entries?  It's not bandwidth, we observed that
above, and my router can handle far faster pipes than the one it's on
currently.  The DNS failing is a sign that the router is under severe
stress.  Back in the 0.2.3.x days, I often had to reboot the *router*
after one of these storms, not just the Tor relay.

And again - do we really know what is causing this?  Something seems
seriously wrong with the kind of numbers I'm seeing coming in to a
node with MaxAdvertisedBandwidth 250KB.

I think a bug should be opened about this, if there isn't one already.

Regards,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIAT1AAoJED/jpRoe7/ujuK4H/06MxbDHlN2uHjae6XurDib1
3yxXhHAUXC5pcP8smLQgqqtazTweeQDfIOT78QS9I0MB5z7ZnAYYsjs1/tJ1AKhb
GkHtYXnlaZCxuP/oHlZYVsEhKXGGRSrXQM+y9f4uoukCn7KyVlCPF9oz2wBtSLqE
qCENCZydn7nPUL6mRxveCoUvVXcGfBvm9uk17SmfuV2e6eDr5NMM4x2IxsZAYzLq
hfYOUs8xLMqldsFqIaIV5J8sKwurI040P+TpZNVe7anB1ZF7uNRPfiyGrG7/JgTq
aiGTyPArEdLnqYcRwGW+HbXBhQBjqF5yLt5Jj+kXXG5qBvaLQ3h/7IT7CJFr8GI=
=eaXx
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ExitPolicy reject *:* ships commented out?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bryan Carey:
> It's possible. One should always review all configuration files
> before making their node operational. You can't assume that it will
> be configured in a particular manner.
> 
> I mean, who would have thought the TBB would ship with JavaScript 
> enabled... ;)

ZING.  Ouch.  ;)


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIAC5AAoJED/jpRoe7/ujyrYIAJMMeVA+6eOo0XODDLbdAye9
o0TpBnj8iOwp83yxTdU5Zo08nrRoqQQOfjJ3oM3c78O/n2N0DSU48RXfDr5ZUaCi
OhaBmaVXi1bIjPut0aOQv0oAS+wphibhYlXLxdUEs4J0BD+Cxhsgrd4KgMq+8He3
ALuxdj68867TOlvEojtAAGbdA+KqYrpouFM94peKv4qxouxRrxsOnEmlHPfuw32+
SioRWfGHEBcsOv4towqjp68wwmMQY3LXdKc2KrYDdfwj/00UniAK2sE7YSdMyIL+
/CDk/yVJfnlNbmheTyoOVaEpKQZNDLEdPOy1Z5+aTFUeLTw6nBdtt9hZcczuM4k=
=5Me8
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] always this way?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

That Guy:
> nodes.  People running non-exit relays getting booted out by their 
> VPS/ISP provider.  I am just curious if it is getting worse or has
> it


This is rarely due to anything other than bandwidth issues, although
some backwards ISPs do not like *any* sort of "P2P" traffic.  I chalk
this up to ignorance.  Give your money to a better provider if this
happens.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSIAFBAAoJED/jpRoe7/ujf8UH/jJHRfa0xB7iTF4VZ91iXmml
jpdIBh2byNJZ0mWaqZP91WPCgM615i4e+eLgMWp5fb+lYUQnQ8A8LTY3SNihwwKx
2cSS/7JRnOYxQSrfiEXdRv+BhMBOxrUPtCGZCbeDjQAk0OQwhb0cMmqfgamLDx/z
2KobsLBEjc82J+YQpdyH9iHPYUkbc9bX/zMbfZx9pBVuzV/G8Awkuuc9Tw9jvgLa
/W3UiPezK3p4C5IR3g3+f9AeKxkrPyB7LGdFPpxSiwbKJYI+uf1qYyiVQ/JaVO8J
R3Gqa2i9Dr4QHMn3pMrW7kZCwKScSUBA6z0PTWZyWZF+olR5nlNi2jKlyw74ghw=
=/ptr
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] What if my favorite online store websiteblacklists all Tor Relay IP addresses?

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

t...@t-3.net:
> Not sure where you live but, I read that these days, USA is 
> photographing the fronts of all postal mail. So, mailed
> merchandise isn't exactly a win on privacy anyway.

That is correct[1].

1.
http://www.nytimes.com/2013/08/03/us/postal-service-confirms-photographing-all-us-mail.html

Best,
- -Gordon M.


-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSGrNdAAoJED/jpRoe7/uj7ZIH/2tcPxpO0F0G+W0fI3cWu/CC
+Igh8j9zpXJkA1Z8YODuiyD26G3VQSg3IILXUjfCpzvLsP3xKzxImD3atocXK7y7
O7tLdgyLg4nPLNtILQtOe26g3W59ljxPJXoHRwGpO0N1g94qkggepxB3qz83UZe/
TPZ3iIhtImvYmzXgU1RHK+3X5ikAlRFShbgPG7IsZrsB9QMFgDL4fGL0x1/ipTLh
mfuzdHbfAYqW4zXVgn9wuncWZK/FY1D2e5gMbavrVpR1jRFxuAB81ty230ibOHPC
1DX4+pqHZOWyNpEpADX+aejhpA9F2yLE6ahhnTtv8UBNxpWh2OZwEP4pem+EQJ0=
=rbQ3
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Config Tor Exit Node

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

var:
> Hi guys,
> 
> we moved from a Win to  Linux  with our tor exit node. The win was
>  running fine no problems since we are running the the exit node
> on a Debian wheezy we got in trouble. The exit node is installed
> and configured with the how to on the official Tor website. The
> exit node is directly plugged in to the gateway. Its an DIR-655 
>  which just have to run our internet
>  traffic + the tor exit node.

I strongly suspect that you are doing one or both of the following:

1 overloading your available outbound bandwidth, resulting in
  bufferbloat-related problems.

2 overloading the DIR-655's NAT state table with too many connections.

What version of Windows were you running on before?  The 'Home' type
versions have at various points had limits in the number or rate of
TCP connections the OS would allow; Linux is far less limited.

> Problem is that when the node is running i lose my internet on 
> every other PC around. Connection is still there but it take years 
> to resolve the namesso i figured it must be an DNS problem.

Either of the above would definitely cause symptoms like this.

I might try the following:

1. Turn Tor off completely and wait a while for other nodes to stop
trying to hit your (now turned-off) relay.  Then do several broadband
speed tests.  Average the numbers together for your OUTBOUND bandwidth
in KB/sec, multiply by 0.7, and set RelayBandwidthRate to the
resulting number (or smaller).

2. Turn off directory mirroring on your relay.

3. If you still have problems, figure out how many TCP connections are
in ESTABLISHED, TIME_WAIT on the Tor relay box.  If there are many
(more than a couple hundred), consider either setting
MaxAdvertisedBandwidth to 50% of your RelayBandwidthRate, or use
iptables or other means to limit the total number of TCP connections
your machine can accept from outside your LAN before it starts to drop
packets.

Also, you might consider upgrading your router and/or using an
alternative firmware.

Best,
- -Gordon M.

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSFkt5AAoJED/jpRoe7/uj4SMH/1AynEX0n0YlwPDrr/h/MFvJ
efju8RQ8JXOEaLqYvLMdk71OF2fZ8+EFm/5zkcgUc9F6WjhLWM3w8REhjvRCyjcH
XFKLkQsvWtftVBaE4Vh+kzedxBMANuABTfZEQdsrs3BZiuzaxAU7EE140Wm+BIja
whcbyVYaQ5UcwGUfXSSsVVaoOa0wMa+616HG4rvS2L8MuFdaLih4gdBonjMdMKOS
P6doFbe6LOkXoZ5nKPmhz2Q+tqU9jLkY5MJqBXlQY/7lnYS/eCePyRi40Jv48x/e
4L4A8jw29jaFLKJm4DybU6Fg2hUNIGXYOuU3RmmKRA+gNfNrI7My2LD15/imTZQ=
=+pA3
-END PGP SIGNATURE-
___
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

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Gordon Morehouse:
> Good news, everyone!
> 
> I've put binary .debs[1] up of the latest Tor experimental version
> - 0.2.4.16-rc - which are built for the Raspberry Pi.  I only have
> a few days of test data, but so far it appears to perform much
> better than 0.2.3.x.

I learned that the 'Tor' name was trademarked, so I have changed the
name of my github project from 'torbian' to 'cipollini'.  Please find
binary packages of Tor 0.2.4.16-rc for your Raspberry Pi at this new
github repo:

https://github.com/gordon-morehouse/cipollini

(Cipollini are small sweet onions.  I liked the image because a Pi is
a small and potentially 'sweet' Tor relay.)

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSERECAAoJED/jpRoe7/ujkUMIAIAjD1KYwiB9Ix20okajL6YR
zson6/KiXwutfG+gdJ7macT+YBQX9MsMO2qlU6W7PjlfzqHigU2Et8jmDbhDbXSa
Xnyx/ry0KtBlGp+CnxqwYOF1k/f38yv+zFLMlKqeJWu9QQEsIX7pQlD4kSPYuKp5
uV59s8HjCutcjZDH1L05WKlJ3D+RmEGpoII8eGvT9POKnVKDuOcAJGR1ztvfEU1+
Tl1NGwPIbEsvGiRDlb0ufeRkLQCf3HkcLGTe47BRtpbw9Cvk32wCgQfuyM9x1n8K
qDztqU0VFCcg0hCoyb76cAi237QjYKQL1Bda5+RhboTZk17jSTrVs4BaNYy0TGM=
=czFB
-END PGP SIGNATURE-
___
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

[Gordon Morehouse]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Geoff Down:
> On Sun, Aug 18, 2013, at 12:35 AM, Gordon Morehouse wrote:
>> I've put binary .debs[1] up of the latest Tor experimental 
>> version - 0.2.4.16-rc - which are built for the Raspberry Pi.  I 
>> only have a few days of test data, but so far it appears to 
>> perform much better than 0.2.3.x.
> 
> Sorry to be the ghost at the feast, but should people trust your 
> binaries?

That's up to them - I am who I am, currently just an independent
hobbyist, so that's an individual decision for them to make.  However,
it would be nice for me to also put the instructions[1] for building
on your own Pi (or any machine) into the Github repo as well.

Also, I've never heard "ghost at the feast" before - is that from a
specific country?  :)

> Not that I know anything about Github, so am prepared to be proved 
> wrong: are these a deterministic build from published source?

They're what popped out when I followed the build-from-source
instructions[1] on the Pi, using the deb-src packages for 0.2.4.16-rc
from the Tor experimental repo with no other modifications - in fact,
I think I probably should have put a minor version name on them to
avoid being "upgraded over" with ARMv7 packages for people who have
the experimental Tor repo in their sources.list, but I'm not sure
about that yet.

> Nothing personal, just reflecting the ethos of the list I think.

No worries, it is what it is - people who don't like the idea of
downloading binaries from some random dude can see the following link.

[1] https://www.torproject.org/docs/debian.html.en#source

Best,
- -Gordon M.
-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJSEPzYAAoJED/jpRoe7/uj2vAIAIcyscQ3LqKMEJMI6V0cZPUw
3DKOn4j2xjlawJQ9ZbW2okZfycahes4M4KLAR3H1LOmf3RPt6DYH3Qdg7rrt6HkX
iKUKhlbznklcD+8fWhOLGtgYzEa7IR3jf9w2RXt3qKnm00sK2Q+zflHYPf27NES7
0joAcxa4g7uH5RsH9XX++gpqpPcp+4eszk3akFWuzthXcKmNWDCjEyiHXnjxy8S/
WG9NPJ4qAiXK3ckJRTOJc59itF7YzjKCxsMGYUYTF2KP8Ah2EFpELCCl586bx+w/
L6d06HdKCuNORBLgoAmCJ5tLKEcVDDsZtlCJrssOYA5DJxrLETLwy5TzkaR13bE=
=wKCE
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays