Re: [tor-relays] Call for setting up new obfs4 bridges

[Steve Snyder]

In my experience the amount of monthly traffic is greatly variable. It
can range from nothing (a few megabytes, for housekeeping) to multiple
terrabytes. My understanding is that this is due to which of several
"bins" the bridge is placed in by the bridge authority.


On 7/12/19 12:41 PM, j4c4l4 wrote:
> On Friday, July 12, 2019 1:28 PM, Peter Ludikovsky  
> wrote:
> 
>> Just how much traffic can one expect when running a bridge? Is it
>> comparable to being an entry/middle node?
>>
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> I was about to ask the same question. I have been running an obfs4 bridge
> for several weeks, and the bandwidth it uses is still around 50KB/s, although
> the maximum rates are set much higher than that (2.5MB/s, with a burst of
> 5MB/s). My other middle relay works totally fine at about 8MB/s.
> 
> Is this normal?
> 
> Thanks in advance
> 
> ___
> 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] What fraction of Tor’s DNS traffic goes to Google and Cloudflare?

[Steve Snyder]

I find it more alarming that a single exit operator handles 13% of exit
traffic than that the DNS resolution is dominated by 2 big players.

Although the DNS dependencies are bad too.


On 7/11/19 6:31 PM, nusenu wrote:
> 
> 
> https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42
> 
> 
>> 60.05% of the tor network’s exit capacity uses a resolver which is
>> located in the same autonomous system as the exit relay itself (that
>> includes localhost)  which is recommended to minimize the path
>> between exit relay and its resolver. Lets aim to increase this
>> fraction to above 80%.
>>
>> If you are an exit operator and want to help reach this goal you can
>> use this list to verify you are not using Google or Cloudflare
>> resolvers. 
> 
> https://gist.github.com/nusenu/e6eec32679cc64ffe3e24d2b9367a931
> 
>> The Tor Relay Guide has instructions for setting up a
>> local DNS resolver. 
> 
> https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays
> 
> 
> ___
> 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] gratitude

[Steve Snyder]

> maybe one of these days i can contribute to it with my own relay,
node, bridge, anything.

Lack of technical skills or access to computing resources isn't a
barrier to supporting Tor. You can support the network financially. E.g.

https://donate.torproject.org/pdr
https://emeraldonion.org/donate/
https://noisetor.net/

Donations to these U.S entities are tax-deductible. And there are
similar organizations outside the U.S.

Just sayin'.


On 05/14/2018 05:19 PM, charlie wrote:
> i just wanted to put this out there. i greatly appreciate what you guys
> do with the tor network. it's an awesome thing and i know you guys go
> through a lot to run it and it's appreciated beyond words. i use the tor
> network all the time now, especially since i live in america and privacy
> and net neutrality are not regarded as being important and i feel safe
> only using the tor network. so thank you! maybe one of these days i can
> contribute to it with my own relay, node, bridge, anything.
> 
> keep up the good work. you're the warriors of a free and open internet.
> 
> charlie
> 
> ___
> 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] Failing: 4063 Connection error

[Steve Snyder]

Your kernel version ("2.6.32-042stab125.5") indicates that you are
running in an OpenVZ container. The maximum number of file descriptors
is set by the host configuration and cannot be increased from within the
container.

Run 'cat /proc/user_beancounters' to see the hard limits. Note in
particular the "failcnt" column of values. From your description I
expect you will a very large number of failures.


On 12/17/2017 10:02 AM, Kurt Besig wrote:
> Where can I set the connection limit higher or is this a result of max
> bandwidth allowed?
> This relay was up for over a year with no issues, however since updating
> the Tor version it's been problematic at best.
> Thanks.
> Linux version 2.6.32-042stab125.5 (r...@kbuild-rh6-x64.eng.sw.ru) (gcc
> version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) ) #1 SMP Tue Oct 17
> 12:48:22 MSK 2017
> 
> Tor version 0.3.1.9
> 
> :Failing because we have 4063 connections already. Please read
> doc/TUNING for guidance. [over 1601 similar message(s) suppressed in
> last 21600 seconds]
> 
> 
> 
> 
> ___
> 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] bind DNS Crash on Exit

[Steve Snyder]

That bug has been "fixed" in RHEL6/CentOS6 since the update on 20 Apr 
2017 but the crashes still occur.  As far as I can tell, all the "fix" 
did was move the assertion failure from resolver.c to validator.c.




On 04/26/2017 02:19 AM, teor wrote:

Hi all,

Are you using bind as a local caching resolver on your exits?

The DNS resolver on our exit crashed over the weekend due to this bug:
https://kb.isc.org/article/AA-01466

It hasn't been patched yet in Debian:
https://security-tracker.debian.org/tracker/CVE-2017-3137

So I have added a file:
/etc/systemd/system/bind9.service.d/restart-on-abort.conf

With the text:
[Service]
Restart=on-abort

This should work for any systemd/bind9 Linux system.

T
--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org




___
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] Which is best for Tor: libevent v.2.0.22 or v2.1.8?

[Steve Snyder]

With the long-awaited v2.1.8 of LibEvent recently released, this brings 
up the question: which is more suitable for use with contemporary 
versions of Tor, the older v2.0.22-stable or the shiny-new v2.1.8-stable?


Thanks.

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

Re: [tor-relays] Tor Process Being Killed on VPS

[Steve Snyder]

I'm unfamiliar with the memory use of nginx, but 512MB ought to be more 
than enough RAM to run just the relay on a 64-bit VPS..


Are you *sure* you're not running anything else? Not crond?  Not ntpd? 
Not iptables? If not SSH, how do you administer the VPS?


What type of virtualization is the VPS using?  If not OpenVZ, make sure 
you have virtual memory on the system.  You can create a swapfile if 
don't already have a swap partition.


Do you have SELinux enabled in the VPS?  if so, get rid of it.

Finally, you may have to ditch nginx and just use Tor and the system 
utilities to monitor performance.



On 02/25/2016 06:19 PM, Stephen R Guglielmo wrote:

Hello,

I have a VPS with 512 MB RAM. I run nothing on it except nginx and a Tor relay. The relay 
is an entry guard and moves about 20 MB/s. It seems that the kernel is killing the Tor 
process with "out of memory" errors. Are there any tips for mitigating this? I 
don't have the money right now to upgrade to the next higher VPS plan which has more RAM, 
unfortunately. Maybe there's some config settings that I can modify to limit the RAM 
usage? Or, am I just out of luck?


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

Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers

[Steve Snyder]

I assume you mean the name resolutions.  Yes, the resolutions are cached. 

The history of queries is tracked implicitly by the resolver. I've set mine to 
no more than 10 queries per second, so the 11th query from the same IP address 
to the same TLD would be rejected.


On Thursday, February 25, 2016 11:09am, "Elrippo" <elri...@elrippoisland.net> 
said:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Are you caching the DNS queries?
> 
> Am 25. Februar 2016 13:47:04 MEZ, schrieb Steve Snyder 
> <swsny...@snydernet.net>:
>>The OpenNIC servers may not be appropriate for use by a high-speed Tor
>>exit relay.
>>
>>I run an OpenNIC DNS server, and my VPS vendor insisted that I
>>rate-limit the server to avoid it being used as a DDOS vector.  I'm
>>guessing that this is not an uncommon position to take for public DNS
>>servers.
>>
>>The OpenNIC servers you select for use may be perfectly fine for your
>>level of use but don't assume it is automatically true.
>>
>>
>>On 02/24/2016 10:49 PM, Tristan wrote:
>>> They are default for Pulse Servers.
>>>
>>> Anyway, thanks elrippo for that link to the Open NIC Project! I've
>>added
>>> their DNS servers to my exit relay, and I no longer see any log
>>errors
>>> about failing nameservers!
>>___
>>tor-relays mailing list
>>tor-relays@lists.torproject.org
>>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> - --
> We don't bubble you, we don't spoof you ;)
> Keep your data encrypted!
> Log you soon,
> your Admin
> elri...@elrippoisland.net
> 
> Encrypted messages are welcome.
> 0x84DF1F7E6AE03644
> 
> - -BEGIN PGP PUBLIC KEY BLOCK-
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd
> BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb
> UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+
> B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5
> Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R
> 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs
> e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9
> jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h
> q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z
> +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI
> KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB
> tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs
> cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL
> BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7
> uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd
> U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW
> oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s
> IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb
> BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI
> kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/
> axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM
> XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi
> dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ
> qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU
> 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY
> s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz
> f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc
> ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich
> O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt
> 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5
> KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB
> FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN
> LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv
> 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ
> MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos
> UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC
> AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo
> N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L
> WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs
> 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj
> 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW
> r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU
> 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T
> An7FlnACtSOv3cIWQ0TymS4

Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers

[Steve Snyder]

The OpenNIC servers may not be appropriate for use by a high-speed Tor 
exit relay.


I run an OpenNIC DNS server, and my VPS vendor insisted that I 
rate-limit the server to avoid it being used as a DDOS vector.  I'm 
guessing that this is not an uncommon position to take for public DNS 
servers.


The OpenNIC servers you select for use may be perfectly fine for your 
level of use but don't assume it is automatically true.



On 02/24/2016 10:49 PM, Tristan wrote:

They are default for Pulse Servers.

Anyway, thanks elrippo for that link to the Open NIC Project! I've added
their DNS servers to my exit relay, and I no longer see any log errors
about failing nameservers!

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

Re: [tor-relays] excessive bandwidth assigned bandwidth-limited exit relay

[Steve Snyder]

On Thursday, October 1, 2015 3:05pm, "Dhalgren Tor"  
said:
[snip]
> 
> You are overlooking TCP/IP protocol bytes which add between 5 and 13%
> to the data and are considered billable traffic by providers.  At 18M
> it's solidly over 100TB, at 16.5M it will consume 97TB in 31 days.

Another consumer of bandwidth is name resolution, if this is an exit node.  And 
the traffic incurred by the resolutions is not reflected in the relay 
statistics.

An exit node that allocates 100% of it's bandwidth to relaying traffic will 
starve the resolver, and vice versa.


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

Re: [tor-relays] Non-standard Bridge

[Steve Snyder]

You've set 2 port numbers, 9001 and 80, to listen on.  Pick one or the other.


Also, set "SocksPort 0".


On Monday, September 21, 2015 1:20pm, "Geoff Down"  
said:

> Hello all,
>  I'm trying to set up a Bridge/Client Tor instance with the following
>  torrc:
> 
> ControlPort 9051
> ExitPolicy reject *:*
> HashedControlPassword 
> Nickname 
> ORListenAddress 0.0.0.0:9001
> ORPort 80
> BridgeRelay 1
> ContactInfo 
> 
> Should this work as a bridge? Client functionality is fine (port 80 is
> forwarded to 9001) but there is no reachability test in the log. I have
> a "bridge's hashed identity key fingerprint" in there; where is it I can
> check online to be sure the BridgeDB has received it? I wanted to check
> it worked with fixed ports before I tried 'ORPort auto'.
> 
> GD
> 
> --
> http://www.fastmail.com - Faster than the air-speed velocity of an
>   unladen european swallow
> 
> ___
> 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] How to determine demand/need for bridges/PT?

[Steve Snyder]

Looking at the Tor Metrics page, I can see the number of bridges and the 
number of users connecting via bridges, but that's not enough 
information to determine satisfaction of demand.


Are there now enough bridges to comfortably satisfy demand?  Enough 
bridges with a particular PT type?  If not, what kind of resources are 
lacking?


How does one determine where the need for more bridges, or PT type, is 
greatest?  (Assuming that there is any unmet need at all.)

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

Re: [tor-relays] Calling for more Exit Relays

[Steve Snyder]

On 08/20/2015 08:42 PM, 12xBTM wrote:

And #2: Cost. Take me for example, I have no trouble handling abuse,
operation, and legal things that take up time, but it's hard to justify
$X/mo towards Tor as opposed to $X/mo towards my student loan.


You can rent a real (not virtual) 100Mbps server for less than $10/month.

I realize that $10 can be a lot of money if you're struggling to put 
food on the table.  For others, though, that's the cost of 2 beverages 
at Starbucks per month.  Not such a burden.


There is also the option of donating money to organizations that run 
exit nodes.  This is less desirable than running an exit yourself (due 
to further concentration of exit capability by big players) but still 
beneficial.  I doubt that they would turn away a $5/month donation.


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

Re: [tor-relays] Qualities of a good relay (Sean Saito)

[Steve Snyder]

On Tuesday, June 23, 2015 9:07pm, saitos...@ymail.com said:

 Besides the obvious requirements of a good relay (e.g. speed, geo-diversity,
 constant uptime), what qualities make a relay valuable to the Tor network and 
 its
 users?

A quality that can't be measured: resistence to intrusion.

On second thought, that can be evaluated from outside to a certain extent.  
What ports on the server are open in addition to the OrPort/DirPort?  Can the 
OS be fingerprinted to reveal an unsupported (and therefore unpatched) version? 

I worry about those relays with a heroic uptime.  How is it that they haven't 
needed to reboot in, say, nine months? No security updates to the kernel or 
glibc in all that time?  Really?

In these days when governments, with their expertise and multi-billion-dollar 
budgets, get infiltrated I wonder how easy it would be get some monitoring 
malware onto machines that run Tor relays.  That seems a lot more likely to me 
than the scare stories about the NSA/GCHQ running a lot of nodes themselves.
 
https://atlas.torproject.org/#details/7489E8EDD0B8B68C8A2CB31D2B56B6572091DA7F



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

Re: [tor-relays] Bridge Usage and Setup

[Steve Snyder]

2) Testing
How do I (easily) confirm my bridge is correctly configured?
Especially if I don't have an IPv6 connection for TBB?

FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:

https://tunnelbroker.net/

That lets you tunnel IPv6 traffic when your ISP only offers IPv4 networking, 
allowing you to connect to your IPv6 bridge address.


On Monday, June 1, 2015 12:34pm, Tom Ritter t...@ritter.vg said:

 Earlier this month I set up an obfs3/obfs4 bridge that (as far as I
 can tell) has never been used. Is this normal?  My bridge is at
 https://atlas.torproject.org/#details/C184F644B9D39B26647779282003ACAF59E8028A
 
 
 During this exercise I ran across a few pain points for setting up a
 bridge.  Maybe I completely ignored some existing resource for this,
 but the bottom of https://www.torproject.org/docs/bridges is out of
 date, BridgeDB doesn't have a link anywhere, and trac's search isn't
 that good but I couldn't find anything on that either.
 
 1) Setup
 I followed
 https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md
 to set up the obfs3/obfs4
 As good as this is, it would be great if it included a minimal and
 complete torrc for an obfs4 bridge, and perhaps also for an
 obfs3/obfs4 bridge and an IPv6 setup.  My torrc is
 
 SocksPort 0
 ControlPort 9051
 HashedControlPassword ...
 CookieAuthentication 1
 ORPort 9001
 ORPort [public ipv6 addr]:9001
 BridgeRelay 1
 ExtORPort auto
 ServerTransportPlugin obfs3,obfs4 exec /usr/local/bin/obfs4proxy
 ServerTransportListenAddr obfs3 [::]:80
 ServerTransportListenAddr obfs4 [::]:443
 
 2) Testing
 How do I (easily) confirm my bridge is correctly configured?
 Especially if I don't have an IPv6 connection for TBB?
 
 netstat seems to say that things are good.  The tcp6 connections on 80
 and 443 also apply to ipv4 though; right?
 
 $ netstat -lpn
 tcp0  0 127.0.0.1:9051  0.0.0.0:*
 LISTEN  479/tor
 tcp0  0 0.0.0.0:90010.0.0.0:*
 LISTEN  479/tor
 tcp0  0 127.0.0.1:55346 0.0.0.0:*
 LISTEN  479/tor
 tcp6   0  0 :::443  :::*
 LISTEN  480/obfs4proxy
 tcp6   0  0 public ipv6 addr :::*LISTEN
 479/tor
 tcp6   0  0 :::80   :::*
 LISTEN  480/obfs4proxy
 
 I can put my bridge line into TBB and try and use it for obfs4; seems
 to work. But actually finding that bridge line wasn't straightforward
 (cat /var/lib/tor/pt_state/obfs4_bridgeline.txt and then edit the
 fields, right?) And it doesn't help for obfs3.
 
 Some external validation would be nice.
 
 3) Usage
 Can do I figure out if my bridge is being used?  I've identified the 
 following:
 
 $  cat /var/lib/tor/stats/bridge-stats
 bridge-stats-end 2015-05-31 18:58:43 (86400 s)
 bridge-ips
 bridge-ip-versions v4=0,v6=0
 bridge-ip-transports
 
 $ zgrep unique /var/log/tor/*
 (a bunch of lines of 0 unique clients)
 
 Atlas graphs, showing virtually no traffic
 
 
 
 
 I feel like #2 might be addressed by Weather (if it was working), but
 all of these might be a good subject for a wiki page on how to run a
 bridge, if my understanding of everything is correct.
 
 -tom
 ___
 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] Bridge Usage and Setup

[Steve Snyder]

On Monday, June 1, 2015 1:28pm, Roman Mamedov r...@romanrm.net said:

 On Mon, 1 Jun 2015 13:23:34 -0400 (EDT)
 Steve Snyder swsny...@snydernet.net wrote:
 
 2) Testing
 How do I (easily) confirm my bridge is correctly configured?
 Especially if I don't have an IPv6 connection for TBB?

 FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:

 https://tunnelbroker.net/
 
 Correction: you can get up to 5 _tunnels_ (pointing to different IPv4
 addresses of yours, typically each to a different host or network where you
 need to add IPv6);
 
 Each tunnel provides you a /64 subnet by default, plus a /48 subnet on request
 (done automatically via their panel);
 
 And each of these subnets provide you with much much more than just 5 IPv6
 addresses.
 
 --
 With respect,
 Roman
 
Yes, you are right.  I've only used a single address from an allocated tunnel 
subnet and so mis-stated HE's offering as my own use.  Thanks for the 
correction.



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

Re: [tor-relays] Drop in relay count

[Steve Snyder]

On Sunday, May 3, 2015 10:08am, Linus Nordberg li...@nordberg.se said:

 Hi,
 
 Looking at the graphs showing the number of relays in the network it
 seems like we've lost about 500 (-7%) relays since the beginning of this
 year.
 
   
 https://metrics.torproject.org/networksize.html?graph=networksizestart=2015-01-01end=2015-05-03
   
 https://metrics.torproject.org/networksize.html?graph=networksizestart=2012-01-01end=2015-05-03

My uninformed guess would be that the higher minimum bandwidth requirements in 
v0.2.6.x forced out the marginal relays.


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

Re: [tor-relays] Legal situation of tor in Europe

[Steve Snyder]

On Monday, March 9, 2015 10:40am, Markus Hitter m...@jump-ing.de said:

 Am 09.03.2015 um 15:13 schrieb s7r:
[snip]
 One flaw which IMHO has to be solved sooner or later is the openess to abuse. 
 Like
 port scans, like malware distribution, like spamming, you name it. Right now 
 this
 task is left to the regular website operators and they don't like it, often
 resulting in general blocking of Tor exits.
[snip]

There is no solution to malware distribution because that would involve 
inspecting the traffic running through the relays.

Being able to separate webmail from the parent web presence (e.g. gmail from 
google.com, Yahoo Mail from yahoo.com, etc.) would be a big step forward in 
curbing spam.  This would allow the exit operation to refuse traffic to the 
webmail service while stilling allowing access to the parent presence.


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

Re: [tor-relays] Legal situation of tor in Europe

[Steve Snyder]

On Monday, March 9, 2015 3:33pm, grarpamp grarp...@gmail.com said:

 On Mon, Mar 9, 2015 at 2:40 PM, Markus Hitter m...@jump-ing.de wrote:
 Am 09.03.2015 um 16:08 schrieb Steve Snyder:
 Being able to separate webmail from the parent web presence (e.g.
 gmail from google.com, Yahoo Mail from yahoo.com, etc.) would be a
 big step forward in curbing spam.  This would allow the exit
 operation to refuse traffic to the webmail service while stilling
 allowing access to the parent presence.

 Good point!
 
 Two censors high five-ing themselves over ways to ban entire
 peoples freedom to communicate using webmail. Amazing.
 Yet you do not call your ISP demanding they block your webmail
 for the same and greater spam reason. I hear internets is bad, you
 should ban it too. Please die from clue bat first.

I my mind such a capability would be optional, like opening POP3 and IMAP ports 
are today.  Thus *your* relay could support all services while someone with a 
more timid ISP could still run an exit node, albeit an exit node that is less 
useful than yours.



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

Re: [tor-relays] Very Safe Exit Policy

[Steve Snyder]

On Tuesday, February 17, 2015 11:02am, Chris Patti cpa...@gmail.com said:
[snip]
 I tried running an exit for a bit and it lasted a few weeks before
 some brainless wonder hijacked someone's Gmail with my exit, so I had
 to pull it down and go relay only.

Me too.  I dearly wish there a way to block webmail while still leaving access 
to the parent site.  Unfortunately, Google, Yahoo, AOL, etc. make it very 
difficult to separate their mail services from their overall web presence.


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

Re: [tor-relays] Fast Exit Node Operators - ISP in US

[Steve Snyder]

On Thursday, November 27, 2014 8:39pm, Libertas liber...@mykolab.com said:
[snip]
 If anyone knows of a good way of finding high-bandwidth budget
 dedicated servers (a search term or a list of providers, for example),
 please share. I expected there to be more of a market for this kind of
 thing than I've found.

http://lowendtalk.com/discussions/tagged/dedicated


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

Re: [tor-relays] Call for obfs4 bridges, and a brief discussion of obfs4proxy.

[Steve Snyder]

Does obfs4 support IPv6 addresses?  If so, does it work like ORPort in 
that it is just a matter of adding another line?



For example, to add an IPv6 address can I just replace

ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__

with

ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__
ServerTransportListenAddr obfs4 [:::::1]:__RNDPORT__

in the config file?

Can I use the same ExtORPort for both IPv4 and IPv6 addresses?


On 09/26/2014 06:32 AM, Yawning Angel wrote:

Hello everyone,

As people who have been following Tor Weekly News or other news
sources, I have been working on a new pluggable transport in the
obfs-line to better allow censored users to reach the Tor network.

The result, obfs4 is what I would consider ready for general
deployment[0], and as part of the process there needs to be bridges for
the users.

To entice people to run obfs4 bridges, I would like to talk briefly
about obfs4 and obfs4proxy.  I am also planning on doing a blog post
about obfs4 some time after I regenerate my experimental TBB snapshots.

On obfs4:

   obfs4 is the next up and coming pluggable transport in the obfs[2,3]
   line, though in terms of design, a better name would be
   ScrambleSuit 2.

   The main difference is the switch from UniformDH to
   ntor-with-Elligator2 for the key exchange process, which means that
   clients strongly authenticate the identity of the bridge (The key
   exchange succeeding means that the bridge possesses a Curve25519
   private key that is known only to the bridge).  Additionally the ntor
   handshake (even with the Elligator2 transform in the picture) is
   considerably faster than UniformDH which should increase scalability.

On obfs4proxy:

   obfs4proxy is the current obfs4 reference implementation, written in
   the Go programming language.  The use of Go was primarily driven by
   the availability of an Elligator2 implementation at the time, though
   it also has other practical benefits over writing it as a component
   of the python obfsproxy code, for example, it is trivial to run
   bridges listening on ports  1024 on modern Linux systems.

   obfs4proxy implements support for obfs[2,3,4], as a managed tor
   pluggable transport (no standalone mode currently).  Note that obfs2
   support is for backward compatibility purposes only and it is
   discouraged that new obfs2 bridges are run as the protocol is
   trivially broken by most adversaries.

   In terms of code stability, we have been running one of the Tor
   Browser's default obfs3 bridges on obfs4proxy for quite a while with
   no issues.

   Similar to ScrambleSuit, obfs4 bridges MUST be running tor-0.2.5.x,
   otherwise the bridge lines that are published will be useless[1],
   though people that wish to run obfs3 bridges with obfs4proxy
   naturally can do so with tor-0.2.4.x.

   Source:
   https://gitweb.torproject.org/pluggable-transports/obfs4.git

   Debian packages (Thanks Lunar!):
   https://packages.debian.org/sid/obfs4proxy

Note: I just tagged/pushed obfs4proxy-0.0.2, but the only
significant change is that it is easier to get an obfs4 bridge line
to give out to people as the bridge operator.  I expect packages to
catch up as the wonderful packager has the time.

Questions, comments, and bridges appreciated,



___
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] Call for obfs4 bridges, and a brief discussion of obfs4proxy.

[Steve Snyder]

On 10/27/2014 06:38 PM, s7r wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/28/2014 12:24 AM, Steve Snyder wrote:

Does obfs4 support IPv6 addresses?  If so, does it work like ORPort
in that it is just a matter of adding another line?



Yes.


For example, to add an IPv6 address can I just replace

ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__

with

ServerTransportListenAddr obfs4 111.222.333.444:__RNDPORT__
ServerTransportListenAddr obfs4
[:::::1]:__RNDPORT__

in the config file?


Yes, that sounds right. If you don't have multiple interfaces or don't
care if you open the ports on all interfaces, here is how I do it:
I use ServerTransportListenAddr obfs4 [::]:_RNDPORT_ - it opens the
obfuscated ports on both v4 and v6 (dual stack).

If you do so, do it to ORPort also, so it will be a fully dual stack
bridge, like:
ORPort 111.222.333.444:_PORT_
ORPort [111.222.333.444::1]:_PORT_


Can I use the same ExtORPort for both IPv4 and IPv6 addresses?


Just use

ExtORPort auto


See, the problem is that I *do* have multiple interfaces, each with an 
IPv4 and IPv6 address.  I don't go the auto route because I want to 
avoid having Tor pick the wrong interface/addresses.  I want the bridge 
to run on a given interface and only on that interface.


One more question: how can I test the functionality of obfs4proxy given 
that TorBrowser v4.0.0 doesn't support this transport?


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

[tor-relays] What to change for v0.2.5.x?

[Steve Snyder]

So now Tor v0.2.5.x Release Candidates are available.  Can someone give 
an overview of what's new for those who don't follow the development 
process?


What can/or should be changed in a working v0.2.4.x relay config to 
accommodate the changes made in the new code?


Are there particular areas (IPv6, multi-threading, etc.) that one should 
be aware of when moving from v0.2.4 to v0.2.5?


The changelogs do a great job of describing the changes between point 
releases but are somewhat overwhelming when attempting to  determine the 
differences between major releases.  If would be great if someone could 
give a brief(-ish) description of those changes.


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

Re: [tor-relays] What to change for v0.2.5.x?

[Steve Snyder]

Sigh. Two replies in a row from people who didn't actually read my 
original post.


From 
https://lists.torproject.org/pipermail/tor-talk/2014-September/034740.html:


Tor 0.2.5.7-rc fixes several regressions from earlier in the 0.2.5.x
release series, and some long-standing bugs related to ORPort
reachability testing and failure to send CREATE cells. It is
the first release candidate for the Tor 0.2.5.x series.

This is followed by a fragment of the Changelog file, detailing the 
differences from the prior v0.2.5.6-alpha.


How again is this responsive to my request for an overview of the 
practical differences between v0.2.4.x and v0.2.5.7-rc?




On 09/12/2014 12:56 PM, DerTorSteher wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here's the url to the changelog on GIT:
https://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=ChangeLog
Mostly bugfixes. Like obx said.
- -Ursprüngliche Nachricht-
Von: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] Im Auftrag
von obx
Gesendet: Freitag, 12. September 2014 16:49
An: tor-relays@lists.torproject.org
Betreff: Re: [tor-relays] What to change for v0.2.5.x?

On Fri, Sep 12, 2014 at 07:30:27AM -0400, Steve Snyder wrote:

So now Tor v0.2.5.x Release Candidates are available.  Can someone
give an overview of what's new for those who don't follow the development

process?

There's a post about that on tor-talk. It's mostly bugfixes.

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

-BEGIN PGP SIGNATURE-
Version: Outlook Privacy Plugin

iQFDBAEBAgAtBQJUEyW1JhxEZXJUb3JTdGVoZXIgPGRlcnRvcnN0ZWhlckBnbWFp
bC5jb20+AAoJEEJxcicpw3h9QSEH/jycD3vdZUhjwOCqH05hqYzKaw0vyPz9jLZ5
FUltcJAxtnUGgAVYEWMke76mQZRuFcyjaNEy0YE5vimu/tqNoPFAOzjkhqEyFQem
7qF5kBYd0pd1D5aQAC+K2oatVdKsKzfTCQ0I09Cd3tP5IHcLrLzaSUMwjYOGIYtH
GizgTvGPpfgt43O1tCtSF60B2N23FYvkMyANiONifHq+xvFQ8DpowgIkc13udlvZ
nI+v0d3YkLfqlZm00sFZqkF9R7lmOoHk33NpsoVn8g7yn6j6Gh65FdjrOxdY5con
PsF4hIHM4Ppaaq7Xgo2CPu1/2NcN9N+FGNUCC9gBmqFumlLYec8=
=R2Ck
-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] CPU usage

[Steve Snyder]

 ...renice to 10...

This is good for the Tor process itself, but disadvantages other processes. If 
your server is doing name resolution (as an exit node) the resolver may be 
impacted, which in turn will hamper handling of exit traffic.

If you're running as a middle node then Never Mind.


On Tuesday, July 8, 2014 8:39am, kingqueen kingqu...@btnf.tw said:

 Thank you to all for the useful information; especially to Roman,
 Julien and Scott.
 
 I want to make optimal use of my existing dedi rather than hiring a
 more powerful one, so I've set NumCPUs to 2, renice to 10 and will
 reboot (as the latter is an init script I guess reboot is necessary.)
 I will then wait a couple of weeks to see what the maximum average
 bandwidth usage is at 200% CPU (for two cores) and will set the
 bandwidth limit to just below that.
 
 Hopefully this will improve both my Tor relay's performance and allow
 me to continue to use the dedi for other purposes.
 
 Thank you all once again.
 
 kingqueen
 
 
 ---
 This email is free from viruses and malware because avast! Antivirus 
 protection is
 active.
 http://www.avast.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] Why did my relay fall out of the consensus?

[Steve Snyder]

On June 9th my relay, which was established about 20 months ago, fell 
out of the cached consensus.


There are no errors in the logs, just notices that the relay is not in 
the cached consensus.  Apart from upgrading to Tor v0.2.4.22 3 days 
earlier I haven't made any changes to the server.


Anyone know what's going on here?

https://exonerator.torproject.org/?targetaddr=targetPort=ip=5.9.191.52timestamp=2014-06-09#relay

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

Re: [tor-relays] Why did my relay fall out of the consensus?

[Steve Snyder]

On 07/04/2014 11:08 AM, Kurt Besig wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/4/2014 7:06 AM, Steve Snyder wrote:

On June 9th my relay, which was established about 20 months ago,
fell out of the cached consensus.

There are no errors in the logs, just notices that the relay is not
in the cached consensus.  Apart from upgrading to Tor v0.2.4.22 3
days earlier I haven't made any changes to the server.

Anyone know what's going on here?

https://exonerator.torproject.org/?targetaddr=targetPort=ip=5.9.191.52timestamp=2014-06-09#relay



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


Your OpenSSL is current?


Yes, v1.0.1h.

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

Re: [tor-relays] Why did my relay fall out of the consensus?

[Steve Snyder]

I'm getting 100% packet loss when pinging dizum and gabelmoo; no packet 
loss to the other authorities.


On 07/04/2014 10:42 AM, Benedikt Gollatz wrote:

On 07/04/2014 04:06 PM, Steve Snyder wrote:

On June 9th my relay, which was established about 20 months ago, fell
out of the cached consensus.

Anyone know what's going on here?

https://exonerator.torproject.org/?targetaddr=targetPort=ip=5.9.191.52timestamp=2014-06-09#relay


You can view the directory authorities' consensus votes at
https://consensus-health.torproject.org/. As you can see, gabelmoo,
moria1, tor26, and urras don't consider your relay Running.

Directory authorities determine if a relay is running by trying to open
a TLS connection to the relay. As a first step in your investigation,
maybe try to connect to these directory authorities from your relay
(e.g. by downloading the consensus file from
/tor/status-vote/current/consensus), and see if that gives any hints.


I'm getting 100% packet loss when pinging dizum and gabelmoo; no packet 
loss to the other authorities.

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

Re: [tor-relays] Why did my relay fall out of the consensus?

[Steve Snyder]

On 07/04/2014 11:59 AM, Matthew Finkel wrote:

On Fri, Jul 04, 2014 at 10:06:51AM -0400, Steve Snyder wrote:

On June 9th my relay, which was established about 20 months ago,
fell out of the cached consensus.

There are no errors in the logs, just notices that the relay is not
in the cached consensus.  Apart from upgrading to Tor v0.2.4.22 3
days earlier I haven't made any changes to the server.

Anyone know what's going on here?

https://exonerator.torproject.org/?targetaddr=targetPort=ip=5.9.191.52timestamp=2014-06-09#relay


Did you fix something? It seems to be running again:

https://atlas.torproject.org/#details/9BE67F8BE1B248994A30E4DEEB3EA00CCFBE9F06
https://globe.torproject.org/#/relay/9BE67F8BE1B248994A30E4DEEB3EA00CCFBE9F06


Well, I rebooted the server.  Apparently that counts as a fix.

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

Re: [tor-relays] Shutting down middle relays (off-topic)

[Steve Snyder]

On 06/20/2014 12:47 AM, Tora Tora Tora wrote:
[snip]

If someone can suggest a resolution that works, I might be able to keep
them running, otherwise I see no point in running vulnerable relays
until I figure things out.


Suggestion #1: upgrade to current version of your OS and apply all 
updates available for that version


Suggestion #2: rebuild Tor, using the current version of OpenSSL.

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

Re: [tor-relays] Shutting down middle relays (off-topic)

[Steve Snyder]

You don't have to reboot the server.  Just do a lsof | grep DEL (and maybe 
lsof | grep delete) and restart those services that are using upgraded 
libraries.

That said, there have been a couple of kernel updates in recent weeks (the 
latest being yesterday), so it is advisable to bite the bullet and reboot.


On Friday, June 20, 2014 9:17am, Tora Tora Tora t...@allthatnet.com said:

 Sorry, I wasn't specific. I am running the latest Centos 6.5, build tor
 from source (0.2.5.4), have restarted all applications and confirmed the
 library used with 'lsof'. Since it is running other services, I have not
 tried to reboot yet.



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

Re: [tor-relays] Bridge Operators - Heartbleed, Heartwarming, and Increased Help

[Steve Snyder]

Let us know if/when obfsproxy runs on CentOS.

Even better, if/when it is back to being written in C, instead of 
version-specfic Python.  That will increase obfsproxy use  more than any 
heartfelt request.



On 04/23/2014 02:32 AM, Matthew Finkel wrote:

Lastly, if you are not already running the obfsproxy pluggable
transport[1] (i.e.  obfs3) on your bridge, please follow the Debian
instructions[2] (for a Debian-based system) on the website and install
it.

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

Re: [tor-relays] Recommended reject lines for relays affected by Heartbleed

[Steve Snyder]

On 04/17/2014 12:17 AM, Roger Dingledine wrote:

On Wed, Apr 16, 2014 at 08:03:51PM -0700, Andrea Shepard wrote:

http://charon.persephoneslair.org/~andrea/private/hb-fingerprints-20140417002500.txt


The SHA-256 hash of that file, for the sake of stating it under a PGP
signature, is:

dadd2beca51d1d5cd7ffe7d3fe3a57200c7de7e136cad23b0691df2fbe84ee3f


Thanks Andrea. 374 of the 380 lines from Sina's file overlap with yours.

I've moved moria1 to reject the union of the two lists.


I hope that similar tests are being run on bridge fingerprints.

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

Re: [tor-relays] Checking a bridge

[Steve Snyder]

I've seen bridges range from no traffic in a month to a full terabyte in a 
month.

So that 100GB may sit unused or it may be exhausted in days.


On Tuesday, November 12, 2013 10:14am, I beatthebasta...@inbox.com said:

 Lunar,
 
 There are some $1 a month VPSs which could be used for bridges, I gather.
 Can you say that bridges wouldn't use more than 100GB a month?
 
 Robert
 
 -Original Message-
 From: lu...@torproject.org
 Sent: Tue, 12 Nov 2013 15:27:07 +0100
 To: tor-relays@lists.torproject.org
 Subject: Re: [tor-relays] Checking a bridge

 Martin Kepplinger:
 When my bridge uses only the same few MBs each day, i guess it isn't
 used at all right?

 Is there a simple way to ensure it is in bridgeDB and functioning as it
 should?

 You can search for the bridge fingerprint in Globe:
 http://globe.rndm.de/

 Globe will hash the fingerprint before sending it to Onionoo to prevent
 leaks.

 --
 Lunar lu...@torproject.org
 
 
 FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks  orcas on your
 desktop!
 Check it out at http://www.inbox.com/marineaquarium
 
 
 ___
 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] Which clock is out of sync on VPS non-exit relay?

[Steve Snyder]

On 09/01/2013 10:57 PM, I wrote:

Hej,

On trying to get a non-exit relay going on a cheap VPS Vidalia says
Sep 02 03:48:32.146 [Warning] Received NETINFO cell with skewed time
from server at 128.31.0.34:9101.  It seems that our clock is ahead by 9
hours, 0 minutes, or that theirs is behind. Tor requires an accurate
clock to work: please check your time and date settings.

I've tried the virtual server clock but with no luck.
Any help would be greatly appreciated.


Let me guess: running Tor in an OpenVZ container?

The timezone is an *offset* applied to the UTC time.  It doesn't matter 
what offset is applied if the actual (UTC) time is wrong.  Try this:


  ntpdate -q pool.ntp.org

to get a 2nd opinion on how far you are from the actual time.  It won't 
vary depending on the configured timezone.


OpenVZ containers inherit their system time from the host.  (That '-q' 
is for query because that is all you can do - you can't set the time.) 
Your only recourse is to open a ticket with the VPS vendor and tell them 
to fix the system time on the node that is hosting your VPS.


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

Re: [tor-relays] new relays

[Steve Snyder]

On 08/30/2013 08:05 PM, Andrea Shepard wrote:
[snip]

If I were going to work on filtering by technical means, it'd be filters to
keep neo-Puritans like you out of my life, thanks.


Well said.  This whole thread is example 87653478965432 of the 
censorship is A-OK if I don't like it mindset.


Maybe we need a competitor to Tor, a privacy network that only allows 
pictures of cute kittens and puppies as traffic.

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

Re: [tor-relays] Is it safe to run an exit node from a VPS provider?

[Steve Snyder]

On 08/13/2013 09:04 AM, Sindhudweep Sarkar wrote:

Hi,

Over the past month I've been running a tor exit relay in a spare VPS
machine that I am not using.

It occurs to me know that this was probably a very poor idea, as I can't
control the physical access to the machine or encrypt private key.


Running an exit node in a VM is better than not running an exit node at all.

That said, not all virtualization is created equally.  An OpenVZ 
container (which is really not virtualization at all) leaves all your 
files being just files on the host disk.


Anyone on the host console can just do a locate fingerprint to see 
those files in all containers and can list the processes running to see 
your relay.


At least with Xen/KVM/VMware you're running on your own virtual disk, 
and are running all processes in a self-contained environment.  The 
traffic can still be sniffed by the host, of course, but you get more 
privacy than you would in an OpenVZ container.

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

Re: [tor-relays] Is it safe to run an exit node from a VPS provider?

[Steve Snyder]

On 08/13/2013 11:10 AM, Sindhudweep Sarkar wrote:

Apologies if the reply goes to the wrong location in the thread.

... At least with Xen/KVM/VMware you're running on your own virtual disk...


Can't the virtual disk just be mounted by whoever has access? I don't think 
this is a large barrier to entry for anyone or a script looking for private 
keys. I could argue that pretty much every mac user has been getting software 
in the form of disk images, and these possibly non-technical users seem to have 
no issues.


Well, any VM host can mount and read an unencrypted disk image.

I guess the difference is ease of snooping.  While access to disk 
contents and process info can be gotten by any hypervisor, some 
platforms make it easier than others.


Again, though: running an exit node in a VM is better than not running 
an exit node at all.

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

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

[Steve Snyder]

On 08/12/2013 06:33 AM, Kali Tor wrote:

Hi all,

I am planning on running a bridge-relay but have a hard 1TB/month
outgoing traffic limitation.

Can someone help me with a torrc config that works for this setup?

[snip]

# networking
SocksPort 0
ORPort [aaa.bbb.ccc.ddd]:9001
ORPort [:::::::]:9001

# policy
BridgeRelay 1
Exitpolicy reject *:*
ContactInfo Not Dental bridge AT toofar dOt com

# 96% of (input=500GB + output=500GB) monthly traffic
AccountingStart month 01 00:00
AccountingMax   480 GB



Notes:

1. Delete IPv6 line if you don't have IPv6 networking.

2. Are you sure it is 1TB output and not 1TB of total monthly traffic?

3. CentOS/RHEL user here, so I can't advise you on the use of obsproxy.

4. In my experience, the chances of you actually moving 1TB/month of 
bridge traffic is very, very small.


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

[tor-relays] NumCPUs 2 or 2 copies of Tor?

[Steve Snyder]

Given plenty of RAM, a muti-core CPU and a single IP address, which is 
more efficient:


a single instance of Tor configured with NumCPUs 2 or 2 instances of 
Tor configured with NumCPUs 1 and different port numbers?


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

[tor-relays] Summary of v0.2.3.x -- v0.2.4.x changes?

[Steve Snyder]

Now that Tor v0.2.4.x has reached Release Candidate status, could someone 
please inform those who haven't been following the development process what is 
new?

I just mean the broad strokes.  Like: What changes to a working relay are 
required or recommended when moving to v0.2.4.x?

What are the major new features of this release?  (Any benefit now to using 
more than 2 CPU cores?  IPv6 support for non-bridge relays?  That sort of 
thing.)

Thanks.


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

Re: [tor-relays] Exit node with bad time.

[Steve Snyder]

That CEST you referred to is an offset that is applied to the actual time.  
To check the actual (UTC) time, do this:

ntpdate -q 0.pool.ntp.org

If you are running in an OpenVZ container you will have to have your VPS vendor 
correct the system time on the node hosting your VPS.  Otherwise, you can keep 
the system time in your server accurate yourself by running the ntpd daemon.


On Tuesday, July 2, 2013 4:31am, Bernard Tyers - ei8fdb ei8...@ei8fdb.org 
said:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi there,
 
 I am running an exit node on a VPS. For some reason (I've opened a support 
 ticket)
 a) my systems clock is off by 2 hours (even though its hosted in CEST land) 
 and b)
 I cannot change it, even though I am root.
 
 As a result, I am getting recurring skewed time errors as below:
 
 
 Accounting (awake) Time to reset: 29:12:02:58
   21 GB / 1 PB   22 GB / 1 PB
 
 Events (TOR/ARM NOTICE - ERR):
  │ 12:25:39 [WARN] Received directory with skewed time (server
 '86.59.21.38:80'): It seems that our clock is ahead by 2 hours, 3 minutes, or
 that theirs is behind. Tor requires an accurate clock to work: please check 
 your
 time, timezone, and date settings.
  │ 12:25:03 [WARN] Received NETINFO cell with skewed time from server at
 76.73.17.194:9090.  It seems that our clock is ahead by 2 hours, 3 minutes, or
 that theirs is behind. Tor requires an accurate clock to work: please check 
 your
 time and date settings.
 
 I haven't found any mention in the archives of this (except [1] which is NOT 
 the
 same, just mentions wrong time), if it results in issues to the network 
 overall.
 
 Until I can get it resolved (today hopefully) is there any negative affects 
 on the
 network of having a node with bad time?
 
 thanks,
 Bernard
 
 
 
 [1] 
 https://lists.torproject.org/pipermail/tor-relays/2011-November/001001.html
 
 
 - --
 Bernard / bluboxthief / ei8fdb
 
 IO91XM / www.ei8fdb.org
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 
 iQEcBAEBAgAGBQJR0o/WAAoJENsz1IO7MIrr8SoIALW8W1+SawsVv6r2sLCEPetp
 u05dGZ4E2vyuey5VIRfPsG1Lc2kPmE+dzY2jgHm2Q66htBqMXtv+WQ1P8TMBYyzj
 ke/LkXOW2aE2NkyJ95navfnImJGWS+Ie4eyk+PnHL0d6RoRc9K2JKnQKTCPLRQvQ
 kiFUkKWuHVn/aRzalrlKH7yFdoPosh5pdqqyRLQ4sDQ0dAye0u4GxfvMsrdCP8oO
 ediSXiRaupSr24V+yK7ceZNUiEBcdNp6VudwJXQ+YH1uF4obSHeVWQFC7ZRpAbAI
 VrqNVqBx7Xbij0wC83VR6ifz/AYJNoKlG56H72w/jg1hVwi7x58CIuLWBOm1bUM=
 =2AY7
 -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] Several IP address on the same box

[Steve Snyder]

Yes, you can run a a bridge on each of the 2 addresses.

You'll need to specify different config files (/etc/tor/tor0.cfg and 
/etc/tor/tor1.cfg), log files, PID files and directories for each bridge.


Each of the config files would include something like this, with a 
different IP address and instance numbering each file:


Log notice file /var/log/tor/tor0.log
DataDirectory /var/lib/tor/tor0
Address aaa.bbb.ccc.ddd
OutboundBindAddress aaa.bbb.ccc.ddd
ORPort [aaa.bbb.ccc.ddd]:443

Hope this helps.


On 05/24/2013 05:24 AM, Torry Torah wrote:

Hi,

I have two network interfaces on my server and thus 2 IP addresses.
Since tor uses only a very small fraction of my resources (I'm running a
bridge), I was wondering if I could put up two bridges, one on each
interface. I didn't find anything in the docs about that.

Many thanks,

--
Torry


___
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] On the way to more diversity

[Steve Snyder]

On 05/04/13 12:34, Philipp Winter wrote:
 On Thu, Apr 04, 2013 at 06:37:51AM +0200, Andreas Krey wrote:
 And do obfs3 bridge help that are run on IPs
 also used for regular relays?
 Right now, it is important to get more obfs3 bridges for China since obfs2 no
 longer works [0]. In general, it would be better to run bridges and relays on
 separate IP addresses to defend against censors who simply blacklist all IP
 addresses listed in the consensus. At least in China, however, it is currently
 possible to run both on just one IP address since the GFW blocks Tor relays
 based on IP:port tuples.

I thinking the sticking point is documentation.

From what repository do I get the obfs3 code?  How do I build obfs3?  How do I 
specify its use in my Tor config file (i.e. config syntax)?

If obfs3 use is so important, then why is there so little documentation for it 
on Tor's website?


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

Re: [tor-relays] BitTorrent complaint

[Steve Snyder]

On Tuesday, April 9, 2013 12:04pm, bartels bart...@mailme.ath.cx said:
 Forgive my ignorance, I am new to tor and learning.
 On closer inspection, I find that bittorrent can run over the tor network, 
 like
 any other traffic.
 Personally, I cannot afford complaints and spend time on legal issues; however
 groundless they may be it is not what I do.

Just make life easy for yourself and use the Reduced Exit Policy:

  https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy

To use, just paste these lines into your torrc file.


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

[tor-relays] How to limit number of sockets used?

[Steve Snyder]

I am running Tor v0.2.3.25 in a VPS that limits me to a max of 4096 
sockets in use.  How can I instruct Tor not to attempt to use more than 
this number?


Yes, I know about ConstrainedSockets/ConstrainedSockSize, but the way I 
read these it limits the amount of memory used, not the socket count.


Advice, please?  Thanks.

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

[tor-relays] Advice on configuring Obfsproxy3 transport?

[Steve Snyder]

Attempting to get Obfsproxy3 to work.

With Tor v0.2.4.11-alpha and Obfsproxy pulled from 
https://git.torproject.org/obfsproxy.git yesterday this is what I get at 
runtime:

Apr 05 14:57:23.000 [warn] Server managed proxy encountered a method error. 
(obfs3 could not setup protocol)
Apr 05 14:57:23.000 [warn] Managed proxy at '/usr/bin/obfsproxy' failed the 
configuration protocol and will be destroyed

I have no problems with obfs2, but obfs3 success continues to elude me.

These are the relevant lines from my bridge config:

  ServerTransportListenAddr obfs3 aaa.bb.cc.dd:12647
  ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy --managed

Any advice on how to get Obfsproxy to work would be greatly appreciated.

Thanks.


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

[tor-relays] Local problem or Authority problem?

[Steve Snyder]

This is the 2nd time I've seen the message below in the last few days.  Is this 
a local problem, or is this Authority server having network problems?

-

Mar 12 16:13:57.000 [warn] Received http status code 504 (Gateway Time-out) 
from server '154.35.32.5:80' while fetching consensus directory.
Mar 12 16:13:57.000 [warn] Received http status code 504 (Gateway Time-out) 
from server '154.35.32.5:80' while fetching 
/tor/server/d/04074EB96250570D79D54ABF8BCCB5D78DCAF288+04A4D41B424AEDA92907E8FD2D3E62150EDF6C2B+05FD952570E17B917395B0A1B85BE3A9D0B2CDFB+063AD80363C90979C3BF86B7059A418C5FD5FEE3+087D53B75320FCB0CA6C3410F1772A75A1BCCD1C+08BE6F4FDAED1B19ED764696DC1BE56B738228E0+09579C2014F3B0419E98E78F2A25D8DD6C96B2E2+0999BB98E0F66C0B888530E3F2E5212DDDF0C6DE+09B0FA1C28671CB104AFC9EDD65239084E407BA0+09BDCC19AD5AB4C3926F7A68F283746871D4D56F+0AB6B62AE4772EE2965DFDAFB8130ECE9CD36884+0C03BE2409199A5D144FE71C88978393DDD421BB+0C2F936E8C2612AAC08C01A0351CE38879E9BDDC+0C7CC03C29DCA1A5F1B52B960EEC9626D174B58E+0D36F472EBFAE10CB177AACC6A119BE3F9DCE08C+0D43FC4BC3A709B0466C824B66685B735CA0238D+0D92EF510A781FC282D09E4AD59BA0C549C38CB5+0DE1BBE15B66DEDDA4BA26CCB81243CA5D5B4361+0E68E2980775EC1A4DCF243B300CD10B667D727E+0EC893270D60852719EA61437365D4E04B58DFF0+0FCF73CC589E66B0A61F5243E98EE1815
 
56E58DA+1383AED682BA066E90AB4A129313F8CB74083009+138AC265F2027B064686E061B9BE95B4375F1EDD+14AD0D65F7B8CAB4D1244A81A94435D72C405ED2+163A20C60F5B3852DC4AE997B1AC684167597DA1+176D2F97C6D94847812BA237E5E8FCBC1C06DE23+1775169594A4FC2E0BFF2DC3A72B1250E48AF967+1925372A11574505E657E5FBA91790F1E199E9A7+1A81CCF4DA2D1083C486502D7A1531E0FDA9A976+1A8FFED1415988D7F150DB934B142D367A91F1D4+1AA4EF44F5A1530A7EBF7FCF58F9B9F73B8C8CBD+1AC92989A40613D367D4FBC938260743F735D006+1B047A3E77D42D6F90AC70AD9087C87273608874+1BD1A901C208924FF723449204C1B739253CFC88+1C88BA75E091BA0AD0586F4496563A8108EF0AFD+1D9BD53B703F5B74D35FEFE90A7AAB877C9811C3+1DDB372BA6ED786C00A0A544FC6111388039E208+2007140616A3236E274F96794033B8100FD483E2+210AA9E1A6A081FD73E2ABFB53B58484CFD86854+215DFFBB03D9B0273E54A5312A8D0CC8790FBEBF+2188A991565919B0A93FC008D7F7CA3B88226CD0+21A3880C02DD2F329975A672A378BCF456900D68+21CF5A07F11BD114FDD83A1A9D84011CDEB4B553+22CDC2869521DAB7B894EAB61C22CBD4F91EBFEA+247120DAD42F112C75EA31B08305AEA1B8030C
 
29+24D23ACAA3B84B6FAE1C8C3C6397C8FA72311960+2569B8E88056D46BD791D3EF828669659A37E0C9+262FA174601FDCDB024BED3040929F21BDC36D48+27FEE7C12A2F2CED4FB4BFD8B453740CC14CBE0A+2AF5996140CB3C40ADD81C1C56734EEAB12EE967+2E94AE3BD0CE4F5DFE7779D5358B0B87825B8637+2E95EC620F01E26C120D8097176C4E2A39873F44+2EC372E877F32770625386C46AA1C0A325B23B2C+2FB82F9DB850312DF102F15C904B9DD6D01273B7+3104BEF38E684D052EB5358B0DB8A0221A1D7E2D+3214DEC5847CB9662F76AD2A73F35AD5EB8ADAC5+327371CEF85B0358A179EDBC6305601F3E1A617F+3282DD9CA468BCD87EF104A947FC087BE8457CD4+32AA787CB8185DBB1B371DC3A055C9D54EE263AF+334C9E6D243E607D7F309F6D49EA617D18CBA4AC+33DF5016BA97AA6B00F30C753A9DC2A6B8046F93+3444C8C526C39133A91F519C07476BF40F422330+34D3650408E276D0204EB8711B083432AB5F2736+3521734E1923619DBB92E43FBA1454995BD9BFA2+35624B39BC583AFD70F21C4E4F16E316D83898C2+366E6CB7854E6FB47411484CCF16316967C8BB68+372B550402CF1CAE0EB53CF03B036619521F5401+37BCE27DA528E4B5ECB639EF38768415981376B8+3990219DEFB3E6991ACE408A1D44CBCD226673D1+3D
 
0E6313BEF11C56B4A1703716EACB2D2BFAF170+3D38952385BD797A7E42AE98889BBA39334CE883+3D480580359358750F66AFE84E187AE789380880+3D9F982ECAEE4FA35D4A963BECFB7F3E7B6659C8+40193F0DF2D4041C421455C079272038F9BC3DAC+40BBB8FB6F665C87D9297D67BB053BE388611A09+40DF0911958AEC11481AFE923D0EEA2B7A8EC7DF+419E7503347EA5CD467BB8383565AEC08722A417+41EF33A6492F7563978A369A23F8753F9AE18DB3+42049023A0ADD501B4426F851AC96CE184DC53BD+42F6AA4DF5B2DF4E0C694E7E8D44F07AE0273983+434CE452D749AB0ECB3328F1173EA5C5D9563F28+43AF557F22152E4868AFCBC637F67E3D28502CE5+44FFB205642C55639AB23C33B342B7B4BA52A40F+4547E5892491161DA48E3A85F387F414453D767F+458D39FAFA9D37E137D810E42FC3E3FCA73D1DD1+45B341C87E3765EC668F3F79FEAA775FFAB0FB72+46146B22376DD4CF48EFE695360D4E04C6B27A5F+4672A76E50B62C6ECB36374904BD2E27D58E0F34+473631BF990138E4F0F9DBC6F92A291346F403C6+49067AB9F33B3A813055D1F06C4196AA01952F1F+496341B3CF1F500BF3544EB4D4B4C65A96A663D0+4B03C837FBE98892ABFBD8F88A87DD253F8CBCE3+4D66AEA3A987CB19F6F1A416369FE52DD90C5B97+4D9705E
 
B0D8539C6DB31FB683ADABEAA8B50237C+4DA6EF73ED368372F0639D030408506B7F1874FE+4E825DC538DA34966EA64712E6B7DD84613FD238.z.
 I'll try again soon.


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

Re: [tor-relays] DMCA letters

[Steve Snyder]

Relevant?

Often referred to as copyright trolling, speculative invoicing involves 
sending hundreds or thousands of demand letters alleging copyright infringement 
and seeking thousands of dollars in compensation. Those cases rarely — if ever 
— go to court as the intent is simply to scare enough people into settling in 
order to generate a profit.

http://yro.slashdot.org/story/13/03/12/1449244/canadian-file-sharing-plaintiff-admits-to-copyright-trolling


On Tuesday, March 12, 2013 9:31am, Matt Joyce torad...@mttjocy.co.uk said:

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
 I think you have probably gotten unlucky here in all honesty given the
 traffic you are pushing over there and having an issue so early on don't
 take it as an indication of expected rates either, I use the recommended
 reduced exit policy on both of my relays on is 20Mbit capacity and has
 been running about 6 months, I've yet to receive anything in the way of
 DMCA or abuse complaints about that one as yet, the newest one is a
 large relay which has actually been running just one day less than your
 one over there, however it's sitting on a 1Gbps connection and as of
 today averaging on the order of around 219.40 Mbit/s (110Mbit each
 direction) having transferred 16.45TiB, in the two weeks since it was
 first activated, the rate has been rising most of that time such that
 1.87TiB of that transfer was yesturday, 2.21TiB is the estimate for
 today.  I'm so glad it's unmetered xD.
 
 You can see the traffic stats for it on the relay info page at
 http://torexit2.mttjocy.co.uk/ I hope that helps at least to settle some
 of your concerns that it might scale linearly, were it to do so then
 this bandwidth would be producing them at rate approximately 20 times
 more frequently or around 40 per 16 days ~2.5 letters a day which is
 significantly higher than the 0 actually received.
 
 So it's either unfortunate luck on your part of they are doing a lot
 more careful checking before sending their random notes out than they
 appear to be and figured out that I'm not the type to scare easy if they
 even had a case let alone when they are blowing smoke.  But I would
 highly doubt that unless they are burning a few hundred doing a detailed
 background check that would actually pick up something like minor civil
 settlements before sending any notices it's not something you would find
 on a casual google, and if they *were* doing that yet apparently still
 not coming up with the simple idea of err type the IP address into
 google and don't waste your time and money when it comes back saying
 it's a tor exit node well that would be going beyond stupid to be fair.
 
 On 12/03/13 07:41, jv...@altsci.com wrote:
 Hi all,

 I've been running a Tor exit node on my new server for 16 days. Today I 
 received
 my second automated DMCA infringement notice from HBO. I sent them the
 boilerplate you see at the bottom of the message both times. My colo provider
 Hurricane Electric understands Tor, which is awesome. I don't think it'll be 
 an
 issue, so I'm happy with this. I'm wondering if anyone receives a large 
 number of
 DMCA infringement notices and whether there was a resolution. It would 
 certainly
 make my life a little bit more difficult to send more than one of these per 
 week.
 When I got my first letter I was pushing 5 Mbps (megabits) and now I'm 
 pushing 9
 Mbps. I've set the RelayBandwidthRate to 5120 KB which should give a max 
 rate of
 41 Mbps. If infringement notices increases linearly with traffic, this could
 become an issue.

 I'm happy to share the infringement notices if anyone is interested.

 I followed a few of the tips from 
 https://blog.torproject.org/running-exit-node ,
 I got a separate IP address and I reduced the exit policy. I plan to update 
 the
 reverse dns. I don't feel like reducing the exit policy does anything because
 BitTorrent was designed to run on any high port. Also, reducing the exit 
 policy
 blocks researchers who are doing port scans and header grabbing over Tor. 
 That's
 a point of contention for me because I know legitimate researchers use Tor 
 for
 that purpose. Does anyone have any data or anecdotes on how exit policy 
 affects
 malicious use of Tor vs legitimate use of Tor?

 Btw, my server is 216.218.134.12. I'm running a patched version of tor 
 0.2.3.25
 which fixes a few bugs I found in buffer events. See
 https://trac.torproject.org/projects/tor/ticket/7788 for more info. Uptime 
 is now
 6 days, 13 days without a crash.

 Thanks,
 Javantea

 ---

 Dear Andrew Martin:

 The IP address in question is a Tor exit node.
 https://www.torproject.org/overview.html

 There is little we can do to trace this matter further. As can be seen
 from the overview page, the Tor network is designed to make tracing of
 users impossible. The Tor network is run by some 

Re: [tor-relays] Recommended specifications for 1Gbps exit

[Steve Snyder]

On 02/26/2013 08:46 AM, Matt Joyce wrote:

I am wondering if anyone with experience in this area could advise me
some on recommended specifications for a 1Gbps exit

[snip]

What DNS configuration will/are you using to handle the avalanche of 
resolution requests?

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

Re: [tor-relays] ServerAstra from hungary allows exit relays

[Steve Snyder]

Well, 115GB/day == 3.4TB/month == 10Mbps unmetered/month.

I assume you are talking about a VPS?  It seems to me that the 10 
Euros/month would be better spent on an unmetered 10Mbps plan.  At least 
that way the relay would be up all the time (and eventually considered 
Stable) instead of up and down in 12-hour increments.


On the other hand if your service provider has already indicated that 
they are OK with you running a Tor relay that might better worth more 
than taking a chance on some other provider.


Just my opinion(s).

http://www.webhostingtalk.com/forumdisplay.php?f=104


On 01/12/2013 04:52 PM, george torwell wrote:
[snip]

i just want to ask, from others experience,
if what im getting from my service provider is a reasonable deal.
for 10 euros a month they allow me about 115GB daily traffic in each
direction.
and its not throttled after that, its just what they asked me to put in
my torrc.
and with the bandwidth they give me its exhausted in about 12 hours each
day.
what do you guys think?
thanks

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

[tor-relays] What's wrong with TorStatus?

[Steve Snyder]

The TorStatus pages at rueckgr.at and all.de have stopped reflecting the 
actual state of the Tor relays.


The page at rueckgr.at displays uptime as the length of time between 04 
Jan and now, regardless of the actual history of the relays.  The page 
at all.de is even worse, calculating uptime as the days since 06 Dec 
2012.  The former shows no less than uptime of 6 days and the latter 
shows every relay as having 35+ days of uptime.


The page at blutmagie.de has an accurate representation of relay 
uptimes, but their bandwidth stats are always inaccurate, so there 
really is no single TorStatus page that one can look at to get an 
accurate view of Tor relays.


What's going on with TorStatus?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ServerAstra from hungary allows exit relays

[Steve Snyder]

My experience with ServerAstra is that they will null-route your IP 
address on reports of abuse.  No notification to me, their customer.


This put me in the position on several occasions of noticing that my VPS 
had been down for x days.  It was only when opening a Support Ticket to 
complain about lack of service that I was told my IP address had been 
null-routed due to abuse reports.


Here's an example of what I was told:

Your VPS has been blocked automatically on numerous accounts of virus, 
malware activity and spamming, and got itself into several block lists.
Please clean up the vps and fix the issues which are allowing such 
things to happen, as we keep our network secure and free of these 
problems.  Your VPS ip will be enabled again rightaway but please 
prevent further abuse of our network resources.


This while running an exit node with the Reduced Exit Policy.

This was my experience from Feb through May of last year.  They may not 
have a policy against exit nodes but they sure make it difficult to keep 
one running.



On 01/09/2013 06:12 AM, Claude wrote:

Hi

I want to share my experience with a hoster I discovered about a year
ago: https://serverastra.com/

I set up a non-exit relay in feburary 2012. They offer a VPS with
100Mbit unmetered traffic for about 15$/month. Here are the vnstat
stats: http://paste.scratchbook.ch/view/26af6ae0

Recently, I asked them if I am allowed to run an exit-relay.
They answered:

--
For now our ToS allows Tor nodes. but please be advised they are really
easy to abuse. We will try to protect the network with our firewall in
case of problems (we already experienced spam from ToR networks). In
any case a ticket will be opened upon abuse case and we will try to
keep both sides confidentiality during negotiation. Happy New Year!
--

They are really cooperative! They also set me up a reverse DNS. So
everything runs fine and fast. Although they sometimes encounter
problems with DDOS-attacks, which affects the bandwith. But this only
happened twice last year.

Claude



___
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] Disappointing AUP - (was Re: DDOS?)

[Steve Snyder]

On Friday, January 4, 2013 3:38pm, mick m...@rlogin.net said:
[snip]
 Thanks for the pointer - but yes, I'd prefer to stay away from the US.
 I think the US is probably already well served with tor nodes.

Yes, about 25% of all Tor nodes worldwide are in the US; Germany is in 2nd 
place with 17%.

https://metrics.torproject.org/csv/relaycountries.csv


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

Re: [tor-relays] Disappointing AUP - (was Re: DDOS?)

[Steve Snyder]

On Friday, January 4, 2013 3:54pm, Roger Dingledine a...@mit.edu said:

 On Fri, Jan 04, 2013 at 03:51:21PM -0500, Steve Snyder wrote:
 On Friday, January 4, 2013 3:38pm, mick m...@rlogin.net said:
 [snip]
  Thanks for the pointer - but yes, I'd prefer to stay away from the US.
  I think the US is probably already well served with tor nodes.

 Yes, about 25% of all Tor nodes worldwide are in the US; Germany is in 2nd 
 place
 with 17%.

 https://metrics.torproject.org/csv/relaycountries.csv
 
 Don't look at relay counts (much). Bandwidth is where it's at:
 
 https://compass.torproject.org/?family=ases=country=exits=all_relaysby_country=Truetop=-1
 
 (That said, the 1st and 2nd place remain the same in this case.)

Exit probability is interesting: 43% chance of exiting from a US-based node.

Also, I feel for that poor guy in Chile.


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

Re: [tor-relays] Complaint about spam originating from my server

[Steve Snyder]

On Thursday, December 13, 2012 1:46pm, Roger Dingledine a...@mit.edu said:

 On Thu, Dec 13, 2012 at 08:28:30AM -0700, Brock Tice wrote:
 Hello all,
   I follow the guide for avoiding abuse notices, and generally I only
 get 1/year of the DMCA variety. However, I recently received this
 complaint, which appears to show spam originating from my Tor server
 (209.188.113.101 / tor-proxy.anfani.com). As far as I know, port 25 is
 blocked on my exit policy. Port 587 is allowed. I do have a mail server
 running on this machine, but it does not accept outside connections.

 Is there something I am missing? Is there anything else I should do to
 prevent this in the future? Could there be some way that a Tor user
 could locally send mail using my server?

 Thanks,
   --Brock

 received:_from_[10.235.200.97]_by_ochaua.tpn.terra.com_(LMTP);_Tue,_11_Dec_2012_12:26:15_+_(UTC)
 received:_from_nm17-vm0.bullet.mail.gq1.yahoo.com_(nm17-vm0.bullet.mail.gq1.yahoo.com_[98.137.177.224])_by_1j4.tpn.terra.com_(Postfix)_with_ESMTP_id_5A96DCDFA_for_waleria.l...@itelefonica.com.br;_Tue,_11_Dec_2012_12:25:02_+_(UTC)
 received:_from_[209.188.113.101]_by_web184904.mail.gq1.yahoo.com_via_HTTP;_Tue,_11_Dec_2012_03:54:56_PST
 
 This looks like webmail -- somebody exited from your relay to port 80
 on yahoo's website, and asked yahoo to send the mail. Yahoo sent the
 mail, and the recipient didn't like it. Fortunately (for the recipient,
 not for you), yahoo included the IP address of the user who asked its
 website to send the mail.
 
 We might not think of this behavior as 'spam' coming from your relay, but
 I'm afraid the definition of spam has greatly expanded in the past decade.

I've been burned by this too.

And this is a problem that will only get worse as the trend continues from 
actual e-mail clients to webmail.

hotmail.com, live.com, webmail.aol.com, mail.google.com, yahoo.com; there are 
so many unknown IP addresses behind these few webmail domains that it is 
impractical to block them.


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

[tor-relays] Status of NumCPUs 2 in 0.2.3.x?

[Steve Snyder]

In the Tor v0.2.2.x series it was said that it was pointless to set 
NumCPUs to a value greater than 2.  Due to poor scaling, I guess.


Is that still the case with v0.2.3.24+ ?  Would NumCPUs value of 4 or 8 
(on systems with that many CPU cores) actually provide any benefit over 
a value of 2?


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

Re: [tor-relays] How to diagnose lack of traffic on bridge?

[Steve Snyder]

On 10/26/2012 01:21 AM, Andreas Krey wrote:

On Thu, 25 Oct 2012 16:33:03 +, Steve Snyder wrote:
...

How can I diagnose the failure of my bridge to garner any traffic?


I assume you didn't set 'PublishServerDescriptor 0' in the tor.rc.


This is the content of my torrc file (with ContactInfo removed):

SocksPort 0
ORPort 443
BridgeRelay 1
Exitpolicy reject *:*


Then the next step would be to check which pool the bridge ended up
in, like (replace 'name' with your bridge name):

https://onionoo.torproject.org/details?search=name


This is what I'm shown when I search for my bridge (fingerprint) at the 
URL you suggested:


{relays_published:2012-10-26 22:00:00,
relays:[
],
bridges_published:2012-10-26 21:37:04,
bridges:[
]}



Interesting part is the pool assignment (and whether it shows up at all).

(Besides; stats are turned on? Mine are empty even though it gets used,
according to the occasional netstat.)

Andreas


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

[tor-relays] Need advice on IPv6 bridge config

[Steve Snyder]

I'm getting my feet wet with IPv6 bridges, so far without success.  I 
set up a test bridge (0.2.3.22-rc) on one network and plugged the 
address:port into Vidalia (TBB x86_64-2.2.39-1) on another.


The bridge config looks like this in part (local IPv4 address hidden):

Address aa.bb.cc.dd
OutboundBindAddress aa.bb.cc.dd
ORPort [2a00:1d70:ed15:37:235:53:64:0]:443

At run time the final Tor log entries are:

[notice] Tor has successfully opened a circuit. Looks like client 
functionality is working.

[notice] Bootstrapped 100%: Done.

In Vidalia the message log entries are:

[Notice] Learned fingerprint 24432B99CA2533BC95ABF66C7AFE835F96DD2B2D 
for bridge 2a00:1d70:ed15:37:235:53:64:0:443

[Notice] no known bridge descriptors running yet; stalling

That last line is repeated periodically forever.

So I have enough connectivity to correctly determine the fingerprint, 
bit not enough to get bridge descriptors.


What am I doing wrong?

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

Re: [tor-relays] [OT] ExcludeNodes no longer working

[Steve Snyder]

On Tuesday, September 11, 2012 1:12pm, Jacob Appelbaum ja...@appelbaum.net 
said:
[snip]
 It seems that there are two issues - one is that a guard is failing to
 build circuits, the other is that you can't seem to exclude them. I have
 to admit, I'm more interested in the former... Is there a pattern to the
 failures?

I get those same messages occasionally.  The following are from last week 
(v0.2.3.20-rc), seen from a Los Angeles datacenter.  I haven't seen this rate 
of complaint before or since so I wrote it off as a fluke.

Sep 01 05:20:31.000 [notice] Low circuit success rate 3/21 for guard 
BramaH4=39A0907D409836D7F014364C5FF5AC1DA79E0289.
Sep 01 05:21:52.000 [notice] Low circuit success rate 6/21 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 01 05:25:36.000 [notice] Low circuit success rate 3/21 for guard 
GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0.
Sep 01 05:28:11.000 [notice] Low circuit success rate 7/21 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 01 05:28:12.000 [notice] Low circuit success rate 8/21 for guard 
WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593.
Sep 01 05:28:14.000 [notice] Low circuit success rate 3/21 for guard 
fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13.
Sep 03 05:12:30.000 [notice] Low circuit success rate 4/21 for guard 
afo=E3F77CC99C4CB9F2E9F1531C6C5FBE8F49694F70.
Sep 04 12:31:25.000 [notice] Low circuit success rate 10/26 for guard 
DFRI1=A10C4F666D27364036B562823E5830BC448E046A.
Sep 04 13:24:51.000 [notice] Low circuit success rate 19/48 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 13:24:55.000 [notice] Low circuit success rate 71/182 for guard 
WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593.
Sep 04 13:25:05.000 [notice] Low circuit success rate 29/74 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 13:25:35.000 [notice] Low circuit success rate 7/22 for guard 
KoenigEdmundI=896F7E93A1FD31FC4671A965CD0D663B0A11D350.
Sep 04 13:25:39.000 [notice] Low circuit success rate 13/33 for guard 
DFRI1=A10C4F666D27364036B562823E5830BC448E046A.
Sep 04 13:26:13.000 [notice] Low circuit success rate 7/34 for guard 
afo=E3F77CC99C4CB9F2E9F1531C6C5FBE8F49694F70.
Sep 04 13:28:11.000 [notice] Low circuit success rate 21/53 for guard 
PPrivCom053=674B191AD2F8325120D128E5447DBD99206784F0.
Sep 04 13:39:49.000 [notice] Low circuit success rate 22/56 for guard 
Ydia=6727D7751EDD5CF3254488A45330674D9FD0AFEC.
Sep 04 14:42:04.000 [notice] Low circuit success rate 22/56 for guard 
coinet=C863FB2A6109C9CE2993C8855BAC59583B15475B.
Sep 04 15:34:00.000 [notice] Low circuit success rate 28/71 for guard 
fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13.
Sep 04 16:30:07.000 [notice] Low circuit success rate 23/58 for guard 
GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0.
Sep 04 16:31:38.000 [notice] Low circuit success rate 9/23 for guard 
TorLand1=4E377F91D326552AAE818D5A17BC3EF79639C2CD.
Sep 04 16:54:26.000 [notice] Low circuit success rate 23/58 for guard 
GreenDragon=7ED90E2833EE38A75795BA9237B0A4560E51E1A0.
Sep 04 16:54:26.000 [notice] Low circuit success rate 28/76 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 16:55:08.000 [notice] Low circuit success rate 48/126 for guard 
KoenigEdmundI=896F7E93A1FD31FC4671A965CD0D663B0A11D350.
Sep 04 16:55:16.000 [notice] Low circuit success rate 27/86 for guard 
Ydia=6727D7751EDD5CF3254488A45330674D9FD0AFEC.
Sep 04 16:55:18.000 [notice] Low circuit success rate 16/50 for guard 
DFRI1=A10C4F666D27364036B562823E5830BC448E046A.
Sep 04 16:55:20.000 [notice] Low circuit success rate 26/69 for guard 
coinet=C863FB2A6109C9CE2993C8855BAC59583B15475B.
Sep 04 16:55:28.000 [notice] Low circuit success rate 34/86 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 16:58:29.000 [notice] Low circuit success rate 8/21 for guard 
WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593.
Sep 04 17:01:27.000 [notice] Low circuit success rate 4/21 for guard 
normatalmadge=FA632D7758867661D4A88D95BFC56EF347A2D796.
Sep 04 17:09:40.000 [notice] Low circuit success rate 31/78 for guard 
fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13.
Sep 04 17:13:26.000 [notice] Low circuit success rate 10/26 for guard 
TorLand1=4E377F91D326552AAE818D5A17BC3EF79639C2CD.
Sep 04 18:27:04.000 [notice] Low circuit success rate 7/21 for guard 
psilotorlu=372D36900E37171A5E38653A2AF4AA5C1C51FF45.
Sep 04 18:51:46.000 [notice] Low circuit success rate 31/79 for guard 
fejkse=EE129A8040807A63741F28C2AD1814CDABC2AD13.
Sep 04 18:51:46.000 [notice] Low circuit success rate 32/93 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 18:51:47.000 [notice] Low circuit success rate 13/36 for guard 
WhiteDragon=5DEF69E67BAF2CF26D36B5AC2A925BB2EA376593.
Sep 04 18:51:47.000 [notice] Low circuit success rate 36/96 for guard 
TORy2=F08F537D245A65D9C242359983718A19650A25F7.
Sep 04 18:52:24.000 [notice] Low circuit success rate 30/79 for guard 

[tor-relays] Current state of v0.2.3.x IPv6 bridges?

[Steve Snyder]

I'm wondering about the benefit of running abridge on an IPv6 address.

Since the big announcement last December that v0.2.3.9 supports IPv6 addresses 
for bridges, I've read a few comments to the affect that BridgDB doesn't 
understand IPv6 addresses.

So... what is the state of publishing IPv6 bridge addresses?  Will clients 
requesting a bridge address ever be given an IPv6 address?  Can a client 
specifically request an IPv6 address (or IPv4 address, for that matter)?

Thanks.


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

Re: [tor-relays] What to do about icecat.biz abuse complaints?

[Steve Snyder]

I'm using the Reduced Exit Policy (see: 
https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy?format=txt) 
which does include port 8000, but shows that service as iRDMI.

I usually associate streaming software with video or audio.  What icecat.biz 
does (I have had to learn much more than I wanted to about them) is to provide 
manufacturer's documentation.  I guess the cat is for catalog.

Blocking the IP associated with icecat.biz is the first thing I did.  That 
didn't stop the abuse reports.  It seems that they have servers distributed all 
over the world, and the reports don't say what server experienced the abuse.

Thanks for the response.

On Saturday, April 14, 2012 7:32am, Daniel Case danielcas...@gmail.com said:

 ___
 tor-relays mailing list
 tor-relays@lists.torproject.org
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
 If I recall correctly, icecast is streaming software that runs on port
 8000. I assume that someone through your node is trying to rip the
 content, which is what the RIP Attempt would be. (Not sure where you got
 the info that it is too many connections?)
 
 If you block port 8000, that could stop people accessing the streaming
 software without too many adverse affects on other services. Alternatively
 you can just block icecast.biz (I noticed there isn't a web server on there
 though)
 
 Daniel
 
 
 
 On 14 April 2012 13:15, Steve Snyder swsny...@snydernet.net wrote:
 
 I often get abuse complaints from icecat,biz saying that a RIP attempt
 was seen from the IP address of my exit node.  Apparently this involves too
 many connections in a given period of time.

 I've tried to contact them but get no answer from the e-mail address
 included in the abuse reports.  The Administrator listed in the 
 icecat.bizwhois
 says he just provides the network and can't provide any info about
 the company or who to contact within it.

 The abuse reports each say that my IP address will be blacklisted for a
 week.  Fine with me. I'd just as soon they blacklist it forever but as they
 are unresponsive to e-mail communication I can't tell them that.

 Short of turning my exit node into a middle node, what can I do about
 these frequent abuse reports?


 ___
 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] How does Tor use nameservers?

[Steve Snyder]

I am attempting to load-balance DNS resolution requests.

Suppose, in Linux, you have a /etc/resolv.conf with this contents:

 nameserver aaa.bbb.ccc.ddd
 nameserver eee.fff.000.111
 nameserver 222.333.444.555

How does a Tor exit node use these 3 nameservers?

Are they used in a round-robin fashion with the next name resolution request 
being handled by the next nameserver in rotation?

Is the first nameserver (aaa.bbb.ccc.ddd above) always used first, with the 
second being used if the first exceeds some time-out threshold, and the third 
used only if the first 2 fail?

Does a middle node use name resolution at all, or is the relaying based purely 
on IP addresses?

Thanks.


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

Re: [tor-relays] Tor relay system uptime requirements

[Steve Snyder]

On Thursday, February 2, 2012 9:41am, Goulven Guillard 
lecotegougdelafo...@free.fr said:

 Thanks for all the replies.  I'll give it a try as a middle node for a
 start (as soon as my ISP fixes my intempestive deconnection issue…).
 
 Is an exit node is more CPU(/RAM ?) consuming than a middle one ?

Yes.  At minimum the exit node must do DNS look-ups for the destinations.  Part 
of the anonymity is that you as an exit node determine which IP address is 
associated with www.yahoo.com, not the originating node.  That doesn't take 
much CPU (apart from the crypto of DNSSEC) but it does take some CPU time, and 
a little bandwidth too.  Also, the packet payload must be decrypted for 
transmission to the destination address.

 Assuming it is the case, as it seems that Tor does need more exit nodes,
 what would be best (in a Tor perspective) for a given CPU/RAM
 consumption : an exit node with lower bandwidth or a middle node with
 more bandwidth ?

Tor does need exit nodes.  The graphs on Tor statistics page show that only a 
quarter of Tor nodes are running as exits.  That said, if this is on a 
residential internet connection you might not want to be an exit node.  A few 
web sites blacklist the IP addresses of Tor exit nodes because they don't want 
anonymous traffic for whatever reason.  Likely you won't encounter such a site 
in your personal surfing, but you should be aware that publicly announcing 
yourself as a Tor exit node may constrain you.

 Concerning OpenSSL's performance the Sheevaplug's Marvell Kirkwood CPU
 seems to have a hardware crypto engine which can be used thanks to
 cryptodev-linux, apparently this may help.

I read a lot of complains from people who say their crypto engine isn't being 
recognized/used by OpenSSL.  (Of course, unhappy people are more prone to 
posting than happy ones.)  You might want to run OpenSSL's speed test to verify 
that you really are getting the benefit of your hardware crypto support.


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

Re: [tor-relays] Tor relay system uptime requirements

[Steve Snyder]

I'm not familiar with the Sheevaplug, but I have some experience with low-end 
hardware.

I run a middle node on a Pentium-M 1.8GHz (Dothan, circa 2004) with 1GB of 
DDR1 RAM on a CentOS 5.x/i686 box.  I have Tor v0.2.2.x configured for 
Bandwidth=150KB, BurstBandwidth=300KB.  That 150KB is one-third of my 450KB 
upload capability.

With this set-up I see the Tor process consuming 2% of CPU, about 60MB of RAM 
(RSS) used, and I see 100 - 200 connections active at any given time.

That 150KB is the peak traffic that is used (I've never see evidence that 
BurstBandwidth is used at all).  If fact, it is currently averaging about 90KB. 
 See here:

http://torstatus.blutmagie.de/router_detail.php?FP=4d393c7d93c16b97a3f41df94919ca8272239b96

The crypto stuff is the CPU bottleneck in Tor, so really Tor's CPU use is gated 
by OpenSSL's performance.  My CPU, old as it is, has SSE2 instructions and that 
helps a lot.  I build Tor against a contemporary version of OpenSSL, which 
doubles the encrypt/decrypt performance relative to the v0.9.8+patches that is 
standard in CentOS v5.7.

FYI.


On Wednesday, February 1, 2012 11:45am, Goulven Guillard 
lecotegougdelafo...@free.fr said:

 Hi all,
 
 I am considering setting up a tor relay.  However my configuration is
 not powerful and I failed to find precise informations about the
 hardware system requirements.  I believe it would be useful to have such
 informations in the FAQ, along with graphs of the needed RAM  CPU as a
 function of the allocated bandwidth.
 
 Anyway, I would use a Sheevaplug (Marvell 1.2 GHz CPU, 512 MB DDR2 @ 400
 MHz) running Debian Squeeze.  It already serves as a small webserver
 (~200 visits/month, 10 MB bandwidth/month), and 150 MB of RAM are
 allocated to flashybrid (which helps preserving the SD card life by
 keeping /var/log/* and such data in RAM and write it down only once in a
 while).
 
 First questions : would it be eligible as a tor relay ?  As a tor exit ?
   Or should I rather go for a bridge ?  I guess my bandwidth will be
 limited by the hardware, how much would you suggest ?
 
 On the same network is my personal computer which is much more powerful
 but down most of the day, so I guess it would be unworthy to make use of
 it ?
 
 I have also thought about using the PC of my parents as a bridge
 (smaller bandwidth), but again it is online only a few hours a day,
 would it be worth it ?
 
 Thanks.
 
 Regards,
 
 G.
 
 ___
 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] Thoughts on InspecTor?

[Steve Snyder]

This application claims to identify bad Tor nodes for the purpose of 
excluding them from use:


http://xqz3u5drneuzhaeo.onion/users/badtornodes/

Anyone have any thoughts on this?  The sum of bad-exit-flags (8), exit 
nodes that alter payload (4), and long-term-misconfigured (27) suggests 
excluding 39 nodes within the Tor config file.


Is this reasonable?  Are these exclusions appropriate for relays, or for 
end users, or neither, or both?


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

[tor-relays] Do bridges care about DNS?

[Steve Snyder]

Do bridges have a need for name resolution, or it it just a matter of 
passing a packet from one IP address to another (i.e. from user to Tor 
node)?


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

[tor-relays] How can I tell if my bridge is working?

[Steve Snyder]

New operator of a Tor bridge here.  How can I tell that it is being used?

With a regular relay I can look up the stats on TorStatus, or I can see 
that there are n current connections.  But a bridge won't be published, 
and the lower volume of traffic means that there may not be many active 
connections at any given time.


So how do I know if it is working?  I mean beyond the absence of any 
errors logged?


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

Re: [tor-relays] Tor Status graphs

[Steve Snyder]

You can try a different status page.

I actually do not trust the numbers at https://torstatus.all.de/ but any 
numbers will verify that your relay is actually moving packets.



On 01/19/2012 08:49 PM, Geoff Down wrote:

Hi,
  the read/write graphs in my relay's TorStatus.blutmagie.de page have
  been broken for some time (flat-lined) but I assumed that was down to
  my old software. However, I see that all the relays' pages are the
  same. Is this data no longer available?
I had a quick look in the archives for an answer.
GD


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

Re: [tor-relays] not specified families

[Steve Snyder]

No, there no reason to set MyFamily when you only admin a single node.

That said, I just followed the link you referenced, and it leaves my 
scratching head a little.  The description of NodeFamily is:


The Tor servers, defined by their identity fingerprints or nicknames, 
constitute a family of similar or co-administered servers, so never 
use any two of them in the same circuit. Defining a NodeFamily is only 
needed when a server doesn’t list the family itself (with MyFamily). 
This option can be used multiple times.


What?  Suppose I operate 3 nodes.  I could specify

MyFamily 
$,$11,$


The doc says:

  NodeFamily node,node,…

  MyFamily node,node,…

So how would a NodeFamily declaration differ from the 3-node MyFamily 
example above?



On 01/05/2012 09:29 PM, Greg wrote:

(I'm quite new here, but...)
If you only run 1 node, is there any reason to set the Family? My
reading of https://www.torproject.org/docs/tor-manual.html.en
(MyFamily, NodeFamily) suggests that it's not relevant for the 1-node
case.

Thanks,
Greg

2012/1/5 Tor Relays at brwyatt.nett...@brwyatt.net:

Probably just misconfigured. If there are emails attached to the nodes you
could try mailing them directly about it.

brwyatt

On Fri, 6 Jan 2012 01:29:42 +0100, Aurel W.aure...@gmail.com  wrote:

Hi,

when I browse through the list of relays I find many router names,
which correlate in some way, but which don't specify a family in their
descriptors.

Just to name a few:
* 2* c5VycfOP
* 3* c516a
* Caldron, Caldron2, Caldron3
* BlgTOR2, BlgTOR
* DwarfHappy, DwarfSleepy, DwarfSneezy, DwarfDopey
* DONATIONxTORx0 - DONATIONxTORx7
and so on,...

is there a reason, why there is such a high number of relays, which
fail to specify a family, since this seams rather striking?

aurel
___
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


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

Re: [tor-relays] relaytorkiri

[Steve Snyder]

On 12/29/2011 05:32 PM, Sebastian Urbach wrote:

Am Thu, 29 Dec 2011 12:20:16 -0500
schrieb Nick Walketubaguy50...@gmail.com:

Hi,


I'm showing that tor is currently using 12 - 14 Mbps on my relay,
however, the status page for my relay (
http://torstatus.blutmagie.de/router_detail.php?FP=192bdf2831c1b007a08dc3c1d7e36be16b5cf1c6
)
does not reflect this speed.  Is there a reason for this?


Blutmagie is using an old version of the tor status software (3.6
something).

Try instead torstatus.all.de which uses the actual tor status v4. Here
is the url for your relay and the numbers are matching with yours:


I've got little faith in either status page.  I really don't know where 
those numbers come from.


For example, my relay named Alexander.  Blutmagie says it has an 
observed bandwidth of 7KB/sec, while torstatus.all.de says it is 70KB 
(yes, seven vs. seventy).  Both of those values sound wrong to me.


But torstatus.all.de is closer to what I think is the truth.  Then I 
look at the graphics for this relay, and again I do not believe it.  The 
Write History values are 15 to 20 times greater than the Read History?!


I won't trust these status pages until they show numbers that I (or 
they) can explain.


https://torstatus.all.de/router_detail.php?FP=8a029c96b97a30f153eb1c951ef23d3f0d61cdd1

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

[tor-relays] Hibernation timing bandwidth

[Steve Snyder]

I have a relay with a fixed monthly bandwidth limit, so I expect the relay to 
hibernate toward the end of the month.  (I'm trying to spread the bandwidth out 
over the month, but actual relay utilization cannot be estimated accurately.)

I'm wondering how to time this hibernation period.  What I'd like to avoid is 
hibernating during a period when relay hibernation is common.

If I know that most Accounting-limited relays hibernate at, say, the end of the 
calendar month, then I can schedule my hibernation to be at the start of the 
calendar month.  If most hibernation is done on Saturday (day 6, the end of the 
week) then I can arrange to sleep on Wednesday (day 3).

Is there a known trend to relay hibernation that I can schedule against?

Thanks.


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

[tor-relays] Relay accounting calculations

[Steve Snyder]

I'm not sure I understand how the relay accounting limit is calculated.

The manual says that you might specify an AccountingMax limit of 1 GB, a 
ceiling that would be applied to each of the input and output traffic.  The 
manual also says that it is known the output traffic can be larger than the 
input traffic, especially if you're running an exit node.  (I imagine that the 
converse applies if you also have Tor clients on the same network, using the 
node, though the manual doesn't say so.)

Given that the AccountingMax value applies to traffic in each direction, one 
would have to specify a rate that is half their actual limit.  That is, given a 
100GB limit one would specify AccountingMax 50 GB in the config file, causing 
the relay to sleep when 50GB is reached in either input or output traffic.

Is the algorithm really this inflexible?  If I reach 50GB on output traffic, 
with only 49GB of input traffic, that puts the relay into hibernation with 1GB 
of bandwidth left unused.

That seems counter-intuitive to me.  Is the manual inaccurate, or am I just 
missing the hidden genius of tracking input and output traffic as distinct 
pools?  It seems more sensible to specify the full bandwidth allotment, with 
the relay hibernating when the sum of the input and output traffic reach that 
limit.


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

Re: [tor-relays] max / burst speed

[Steve Snyder]

 I run 2 middle nodes, one at 150KB/300KB and the other at 100KB/200KB.
[snip]

No idea what shaping algorithm Tor uses, nor any clue on recommended
burst ratios under said algorithm. Anyone???.

FWIW, the example config file (torrc.sample) includes these lines:

## Define these to limit how much relayed traffic you will allow. Your
## own traffic is still unthrottled. Note that RelayBandwidthRate must
## be at least 20 KB.
#RelayBandwidthRate 100 KB  # Throttle traffic to 100KB/s (800Kbps)
#RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps)


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

[tor-relays] Sorry, HotMail users, you're rejected

[Steve Snyder]

Got another threatening e-mail from my ISP today, prompted by another SpamCop 
complaint regarding spam run through HotMail.  HotMail records the address of 
the originating server and that, again, is my exit node.

So I have to curtail exit access to HotMail.  Yeah, it sucks, but I know of no 
way to block the sending of webmail while still allowing it to be retrieved.


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

Re: [tor-relays] Received abuse complaint - how did this happen?

[Steve Snyder]

On 08/10/2011 05:54 AM, Javier Bassi wrote:

On Aug 9, 2011, at 11:46 PM, Steve Snyder wrote:


Today my ISP informed me that an abuse complaint had been lodged against me by 
spamcop.net.
(...)
Anyone have any thoughts as to how my Tor config can be used to transmit spam?



Did you have the Exit node flag on port 80? You should contact
directly to spamcop to inform them about tor since they are active
contacting ISPs.


I had and still have the ORPort on 443.  I had DirPort on 9030, but have 
since moved it to port 80 so that I can put up the Tor Exit explanatory 
web page (DirPortFrontPage).


So what do people do about spam via webmail?  Blocking ports 80 and 443 
largely negates the point of being an exit node.


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

Re: [tor-relays] Number of Connections Open

[Steve Snyder]

Exit server with maxed-out 10Mbit connection (1.1MB/sec):

# lsof -ni | grep _tor | wc -l
546

Relay server rate-limited to 150KB/sec:

# lsof -ni | grep _tor | wc -l
132

Regarding the relay server: torstatus.blutmagie.de reports Observed bandwidth 
of 51KB/sec while Vidalia reports 172KB/sec.

Neither server is CPU- or memory-constrained, and the relay server is not 
bandwidth constrained.

With all that said, I don't expect success in your endeavor.  In my experience, 
traffic on relays is really, really erratic.  Look at how the utilization 
bounces on a Stable server:

http://torstatus.blutmagie.de/router_detail.php?FP=4d393c7d93c16b97a3f41df94919ca8272239b96

Good luck modeling (and end-users estimating the use of their Internet 
connections) this kind of variation in network utilization.


-Original Message-
From: Tim Sally tsal...@illinois.edu
Sent: Saturday, July 30, 2011 3:56pm
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Number of Connections Open

Hi!

I'm working on a model to estimate the number of connections an OR has
open as a function of the OR's bandwidth. I could really use some help
confirming that my model is reasonable. Would any relay operators be
willing to share the results of some variant of netstat | wc -l and
the bandwidth of the relay?

Thanks,

Tim
___
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