Re: [tor-relays] High speed Tor relay advice

[s7r]

Hey,

That's neat! Thanks for contributing.

How many CPU's / CPU cores does this new server have and does it use
AES-NI? How much RAM? Does it have multiple public IP addresses?

Currently it's complicated for a single Tor process to saturate a 10Gb/s
line, because it's not yet able to use all CPU cores.

What I would do if I had multiple public IP addresses: make 4-5 virtual
machines, with 1 CPU core each and reasonable RAM (say 8GB per virtual
machine) and run 4-5 different relays that would all combined come close
to saturate the 10Gb/s link.

On 8/14/2016 5:09 PM, i3 wrote:
> Hi all,
> 
> I've ran multiple Tor relays before but I have moved to a new server and
> would like some advice.
> 
> My new server has 10Gb/s connection (I've observed it at 900MB/s to the
> drives) with plenty of CPU and RAM to complement. I typically use
> default configurations on my relays but I feel that to get the most out
> of this one I'll need to do some configuration to tweak it.
> 
> Does anyone have advice on getting the most out of this server, in terms
> of speed?
> 
> Thanks
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] High speed Tor relay advice

[s7r]

Hello,

In this case I suggest you run two separate Tor instances on the same IP
address (it is the maximum allowed). When I say 2 Tor instances I mean 2
separate data directories with separate identities.

If it's a VPS it's already a VM. It does not make sense to create a vm
inside a vm. You can use linux containers or FreeBSD jails if you are on
FreeBSD which work fine in virtual machines, one for each Tor instance.

P.S. If you can, make them exit relays if they're not already. It's not
that much of a hassle, if the provider is mentally sane and just
forwards you the abuse complaints with request to reply within 24 hours.
Most of them are automated emails which do not require replies, and the
rare ones which require reply are from people who just don't know what
Tor is, just explain and they will understand.

On 8/14/2016 5:39 PM, i3 wrote:
> Hey!
> 
> So the server is technically a VPS, it is a slice of a larger server
> that is shared with 5 other people. Though I still have full root
> access. So the whole 10gb/s is not just for me, but from my tests I can
> at least get a few gigabit in real world speeds sustained.
> 
> CPU: 6x Xeon E5-2620v3 vCores
> RAM: 10GB
> 
> I only get one IP address to myself by default. I could probably get
> more though if I feel it is worth it.
> 
> 
> On 14/08/16 15:27, s7r wrote:
>> Hey,
>>
>> That's neat! Thanks for contributing.
>>
>> How many CPU's / CPU cores does this new server have and does it use
>> AES-NI? How much RAM? Does it have multiple public IP addresses?
>>
>> Currently it's complicated for a single Tor process to saturate a 10Gb/s
>> line, because it's not yet able to use all CPU cores.
>>
>> What I would do if I had multiple public IP addresses: make 4-5 virtual
>> machines, with 1 CPU core each and reasonable RAM (say 8GB per virtual
>> machine) and run 4-5 different relays that would all combined come close
>> to saturate the 10Gb/s link.
>>
>> On 8/14/2016 5:09 PM, i3 wrote:
>>> Hi all,
>>>
>>> I've ran multiple Tor relays before but I have moved to a new server and
>>> would like some advice.
>>>
>>> My new server has 10Gb/s connection (I've observed it at 900MB/s to the
>>> drives) with plenty of CPU and RAM to complement. I typically use
>>> default configurations on my relays but I feel that to get the most out
>>> of this one I'll need to do some configuration to tweak it.
>>>
>>> Does anyone have advice on getting the most out of this server, in terms
>>> of speed?
>>>
>>> Thanks



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Do middle nodes create multiple connections to the same Exit node? (with different source port)

[s7r]

It should open a single connection with the exit node (TLS link) and use
that link for multiple (as many as needed) circuits. So if there are two
users using the same middle node and same exit simultaneously, the
middle node should have one connection to the exit node (TLS link) with
two different circuits wrapped inside.

I saw you mentioned that it can be found out, why not try to test it
yourself and see if what I've said it's actually true in practice.

On 8/15/2016 6:48 PM, don.go...@tuta.io wrote:
> Hello,
> 
> Do middle nodes create multiple connections to the same Exit node? (with
> different source port)
> 
> The reason I ask is because I am a little confused. Even the tor relay
> operators are completely honest and don't log anything, the ISP /
> upstream ISP could still log all the connections.
> 
> So they can see: [MiddleNode IP]:[Source Port] ==> [ExitNode IP]:[Dest
> Port (ORport)] -- Timestamp + Duration of connection.
> 
> So if I create a long running ssh connection that is going for 6 hours
> this will be unique to the middle node.
> 
> During this 6 hours, if another tor client chooses the same MiddleNode +
> ExitNode, does the MiddleNode create a new connection to the ExitNode?
> (Can be found out using netstat)
> 
> Or does it use the same connection that it already has established with
> the exit node?
> 
> Thanks.
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Useful metrics for relay operators

[s7r]

On 9/1/2016 12:18 PM, patacca wrote:
[SNIP]
> 
> I would find very useful a mail notification when the ed25519 key's
> expiration date is near and the OfflineMasterKey is enabled.
> Also if the expiry information could be shown on atlas that would be nice.

The expiration date of the temporary ed25519 signing key is included in
the server's descriptor afaik, but there's no way to know if a relay has
OfflineMasterKey enabled or not. We could add this extra info but I
would disagree since this will advertise which relays have this enabled
and which not.

The system is designed in a way that you should not use OfflineMasterKey
if you want to leave your relay unattended or don't have time to renew
keys. A simple script installed on the relay and executed by a cronjob
can determine the expiration date of the ed25519 signing key and send an
email when there's less than X minutes/days remaining. I don't think
this should be a network wide default.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Moving multiple instances to another VPS

[s7r]

Hello,

Thanks for running exits!

Pay attention that each instance has its own datadirectory, this means
you need to have multiple 'keys' subdirectories depending on the number
of your instances. Usually /var/lib/tor should contain some subfolders
like 1, 2 or instance1, instance2, whatever and each containing another
subfolder with the related keys for each instance.

So you need to make sure you backup and move the keys for all instances.
There's no problem if you copy the entire directory, as long as the keys
are there, Tor will just overwrite the expired cached/consensus data.

On 9/11/2016 4:08 PM, pa011 wrote:
> I have to move a multiple instances Exit from one VPS to another.
> 
> Apart from creating the same instances on the new machine with 
> **tor-instance-create** I would then just copy the whole directory 
> /var/lib/tor/keys to the new VPS - or should I copy all /var/lib/tor/ to not 
> miss anything from the original one?
> 
> Am I miss anything else?
> 
> Thanks 
> 
> Paul
> 
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Question about relay speed

[s7r]

On 10/3/2016 12:00 AM, Green Dream wrote:
> You could also turn the old relay into a bridge. I've read that low
> bandwidth machines are often better serving the network as bridges,
> although I don't know what the cutoff value for "low bandwidth" is in
> this case.


I recommend, if you decide to setup a bridge (which is very useful) make
sure you include the latest pluggable transport and better make the new
server with a fresh IP address a bridge, one which was never a Tor
relay, because turning the older relay into a bridge might not be so
effective -- the IP could be blacklisted due to be known as a Tor relay
(part of the public consensus) and be impossible to reach by users
behind restrictive firewalls / censored internet.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Second relay on same ESX

[s7r]

Hello,

Thanks for running relays.


Patrick DERWAEL wrote:
> Hi guys,
> 
> I'm running a relay in a VM on a physical server which is largely under used
> Current advertised bandwidth 26MB, consensus 76500
> I'm considering running a second relay (2nd VM) on the very same
> hardware, but this brings a few questions:
> 
> - is there any issue running it at the same geographical place?

It desirable to have geographical diversity of course, but running two
in the same place to increase capacity doesn't do any harm. Just don't
forget to configure MyFamily in both torrcs so that the relays are
linked together as belonging to the same family.

> - would the current total BW effectively consumed (26MB) be divided in 2
> (i.e. no added value in BW)?

This depends on a lot of things. If your network port can handle more
than 26MB, and the limit of 26 MB observed on the first relay comes from
CPU/RAM, the 26 MB will not be divided but increased. If the first relay
has underused CPU / RAM this means the 26 MB is a limitation that comes
from the network port speed, and in this case it will be obviously divided.

> - basically, would it have any significant added value to the network?
> 
> Thanks
> 

Yes, if the bandwidth grows. If the 26 MB is divided in two, it's easier
and better to run a single one of 26 MB (save space in descriptors
distributed network wide, have a single box to maintain and keep up to
date, etc.)



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Changing exit to bridge

[s7r]

Volker Mink wrote:
> Thanks so far.
> Does it keep my stats in Atlas when i change it from an exit to a bridge?
> What do i have to change in the torrc-file?
> 
> https://atlas.torproject.org/#details/E20FF09A9A800B16C1C7C16E8C0DF95F46F649B0
> 

Note that if the IP address was an exit relay or relay it probably ended
up in few lists (the IP addresses of all relays are public) and it might
not be a good bridge ... because it will be already blocked and nobody
would be able to use that bridge.

If you can get a fresh IP address and run a bridge that would be
awesome, if not simply keep it as a middle relay.

I challenge you to keep it as an exit, exits are more helpful and more
fun to run. Just fight with abuse complaints, it's not that hard and
it'll make you feel better :) try keeping it as an exit.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Another relay is using the same name as mine.

[s7r]

Alan wrote:
> I just need some advice. I'm running 3 relays, one is called Andromeda.
> Today I find out there is another relay called Andromeda.
> 
> https://atlas.torproject.org/#search/Andromeda
> mine is running from ip 144.217.161.119
> 
> Is it a problem with relays using the same name?
> Should I contact them and inform them of their error?
> Should I just leave it?
> 
> Any advice would be very helpful.
> 
> Alan.

Hi,

thanks for running relays.

No serious problem in this case - the name is just something to be
easier to refer to a relay, it is not used deep inside Tor. Identity
fingerprint is what matters, that is related to the crypto keys of each
relay. It is almost impossible to have a duplicate fingerprint by accident.

I think you can just leave it. There is no relay name patent and there
isn't any use for it. Your relay is UNIQUE in the network, because of
its fingerprint, there can be 100 other relays sharing the same nickname.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] "Bug: Duplicate call to circuit_mark_for_close"

[s7r]

tor wrote:
> Hi,
> 
> I'm troubleshooting a Linux relay where the Tor service is having
> problems. External monitoring alerts indicate both the ORPort and
> DirPort are unreachable (TCP connection timeout). I can ssh in and the
> Tor service is still running. The node seems to have increased memory
> usage at this point but there's no evidence of OOM. I restart the Tor
> service, monitoring says all is good again, and things seem fine for a
> bit, until the cycle repeats hours later.
> 
> I'm still investigating, but one thing I immediately noticed was
> hundreds of these lines in the logs:
> 
>   [warn] circuit_mark_for_close_(): Bug: Duplicate call to
> circuit_mark_for_close at ../src/or/onion.c:238 (first at
> ../src/or/command.c:579) (on Tor 0.2.9.11 )
> 
> I found https://trac.torproject.org/projects/tor/ticket/20059 but it's
> marked as fixed with a backport to 0.2.9. 
> 
> Any thoughts?
> 

Hello,

Thanks for running a relay.

You are on 0.2.9.11 and #20059 was merged in 0.2.9.12
https://gitweb.torproject.org/tor.git/tree/ReleaseNotes?h=release-0.2.9

There is no sense to report this further because the issue is fixed, you
are just one release behind.

As for the relay, I am pretty sure there is a firewall or something
which throttles the incoming / outgoing TCP connection a
process/user/pid can initiate or something like this. The problem is
either in the operating system itself either a network-level firewall or
built-in router firewall.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] decrease in traffic

[s7r]

Hi,

Trey Nolen wrote:
> I'm new to running a Tor relay and started one about a month ago.   I've
> got 50 Mbps dedicated to it and at first it climbed in traffic pretty
> steadily until it got to around 25-30 Mbps being used.   Since then, it
> has declined steadily and is down to about 350 KBps now (yes, I'm
> keeping the units straight).
> 
> My node is a single core VPS running 3.2GHz and with 1GB RAM. 
> Currently, top shows tor as using about 15% of the memory.  When it was
> churning out at the maximum rate it got to, the CPU was pretty
> hammered.  I was considering allocating another core, but there is no
> need anymore as it is hovering around 7% usage.  
> 
> The server is running on Ubuntu 16.04.3 and I'm running 0.3.1.7 tor.
> 
> 
> Am I doing something wrong to result in the decrease in traffic?  Any
> advice is appreciated.
> 
> 
> Trey Nolen

First of all, thanks for running a relay.

Based on my experience, what usually happens is that the provider of
your VPS observed during a period of time you used more than N mbps
constantly and all the time, so they capped your VPS at some KB/s limit.
There are performance monitoring scripts that could do this
automatically. A virtual private server shares the network card of the
host with the other VPSes on that host, so almost all providers do not
allow you to use it all by yourself all the time for long periods. You
can open a ticket upstream and they will confirm if this is the case or not.

Nothing you can do about this unfortunately, most providers do this,
even the ones they say they don't do it :) Only thing you can do is get
a dedicated server with guaranteed bandwidth, or try to convince them to
at least lift your the limitation for your VPS to 1mbps.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] decrease in traffic

[s7r]

Trey Nolen wrote:
> 
>> First of all, thanks for running a relay.
>>
>> Based on my experience, what usually happens is that the provider of
>> your VPS observed during a period of time you used more than N mbps
>> constantly and all the time, so they capped your VPS at some KB/s limit.
>> There are performance monitoring scripts that could do this
>> automatically. A virtual private server shares the network card of the
>> host with the other VPSes on that host, so almost all providers do not
>> allow you to use it all by yourself all the time for long periods. You
>> can open a ticket upstream and they will confirm if this is the case or not.
>>
>> Nothing you can do about this unfortunately, most providers do this,
>> even the ones they say they don't do it :) Only thing you can do is get
>> a dedicated server with guaranteed bandwidth, or try to convince them to
>> at least lift your the limitation for your VPS to 1mbps.
>>
>>
> 
> 
> In this case, this is not going on as we *are* the provider.   I'm a
> sysadmin on the network and I'm one of the guys that would be in charge
> of limiting any machines which violated any rules.  :-)
> 
> 
> Trey Nolen

Oh, OK. Glad to see not everybody who rents virtual private servers also
caps their bandwidth. It happened to me so many times that I could even
bet that this was the issue here, but looks like it's not.

Since atlas is down, I have looked at the votes here:
https://consensus-health.torproject.org/consensus-health.html

and it looks like your relay has a measured by authority 'bastet' of
355. That is not a big value. The other authorities measured this:

278;
355;
367;
803;

So it looks like the speed was pretty much the same for the measurements
performed on your relay by different servers on different networks. If
you say you are sure there is nothing automated (at either OS level,
hypervisor level, local router/network level or something upstream) that
could throttle this in case of continuous high usage, there's not much
you can do other than waiting some time to see the next speed measurements.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] So long and thanks for all the abuse complaints

[s7r]

Zack Weinberg wrote:
> On Mon, Dec 4, 2017 at 10:57 AM, Ralph Seichter  
> wrote:
>> On 04.12.17 11:59, James wrote:
>>
>>> As a private individual, after just receiving my 4th abuse complaint
>>> in as many days it's time to stop running my exit node.
>>

Thanks for running the exit and I am sorry you took the decision to shut
it down. However, 4th abuse complaint in few days is really not a big
deal, I could say I swim in such reports, but then again it's up to each
and every one when to stop.

What I want to point out is a HUGE difference between:

1. *Abuse Reports* aka *Serious complaints*, those that are addressed
directly and formally, sent by a human, and explicitly require action or
at least reply with explanation. These are very rare.

2. *Junk NOTIFICATIONS* aka *WARNINGS* aka *Simple Notifications to
safely ignore*, those that are not addressed formally ("to whomever it
may concern..."), are sent by bots or automated scripts (firewalls,
intrusion systems, fail2ban, etc) which simply run a whois on an IP
address and bomb the abuse mailbox with spam, most sent from addresses
that even if a reply is sent the message is discarded - these DO NOT
require action nor reply. These are the 99% ones.

>> I've had an ongoing debate with a hosting service over a fresh exit node
>> being abused for network scans (ports 80 and 443) almost hourly for the
>> last few days. I can understand that they are pissed off, and the whole
>> thing resulted in this particular exit being shut down by the hoster. If
>> I could detect and prevent these scans, it would go a long way to avoid
>> having my exit nodes shut down by hosting services.
> 

This is just a defective policy of that hoster. If a hoster goes mad
because it receives some useless junk notifications, that is not much of
a hoster. The first problem is that one who feels port-scanned or probed
needs to implement defenses at their end, not bomb with automated spam
messages everyone that is connecting to them. You cannot rely on
everyone else doing something in order to ensure your security when you
can implement protections for yourself.

A large exit node (big consensus weight) is almost guaranteed a false
positive to trigger such a dumb warning system, even in legitimate cases
where simply more users pick it as Exit and the service (end point) is
popular.

> With my exit node operator hat on, I too would like to see some sort
> of port-scanning prevention built into the network.  In my case, I had
> to turn off exiting to the SSH port because we were getting daily
> complaints about abusive scanning for devices with weak admin
> passwords.  Which is a shame, since there are plenty of legitimate
> uses for SSH-over-Tor.
> 

I agree it's annoying but it is very hard to implement port-scanning
prevention directly in Tor especially because new connections should not
be distinguishable if they come from the same user or multiple users.
The exit relay should have no definition about this, otherwise you have
to go deeper into streams attached to each circuit which is totally
different. This will be over-engineering with absolutely no gains
because someone that wants to abuse simply does not care about the
network and will just keep port-scanning with isolated requests /
different circuits (might be slower, but still work) and will consume
even more resources in the network.

I don't think this is the way to go, under any circumstances. Better to
learn to make difference between junk notification and serious reports
that require action or reply.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [err] tor_assertion_failed_(): Bug: src/or/connection.c:5113

[s7r]

Hi,

This looks like it's worth a ticket on trac. I've searched and there are
no open reports about this, just a ~5 year old one that is closed (#9017).

So this happened only when you had IPv6Exit enabled (1) and you had to
switch to 0 to avoid it?


Toralf Förster wrote:
> Got this today:
> 
> Feb 13 22:02:49.000 [err] tor_assertion_failed_(): Bug: 
> src/or/connection.c:5113: assert_connection_ok: Assertion (conn->type == 
> CONN_TYPE_EXIT && conn->state == EXIT_CONN_STATE_RESOLVING) || 
> connection_is_writing(conn) || conn->write_blocked_on_bw || 
> (CONN_IS_EDGE(conn) && TO_EDGE_CONN(conn)->edge_blocked_on_circ) failed; 
> aborting. (on Tor 0.3.3.2-alpha efc105716283bbdf)
> 
> Before I changed the config from
> 
>   ExitRelay 1
>   IPv6Exit 1
> 
> to 
> 
>   #ExitRelay 1
>   #IPv6Exit 1
> 
> and a little bit later to
> 
>   ExitRelay 0
>   IPv6Exit 0
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Setup

[s7r]

Gabe D. wrote:
> Feb 24 10:45:08.668 [notice] Tor 0.3.2.9 (git-64a719dd25a21acb) running on 
> Linux with Libevent 2.0.19-stable, OpenSSL 1.0.1t,
>   Zlib 1.2.7, Liblzma N/A, and Libzstd N/A.
> Feb 24 10:45:08.668 [notice] Tor can't help you if you use it wrong! Learn 
> how to be safe at https://www.torproject.org/downl
>  oad/download#warning
> Feb 24 10:45:08.668 [notice] Read configuration file "/etc/tor/torrc".
> Feb 24 10:45:08.671 [notice] Based on detected system memory, MaxMemInQueues 
> is set to 2891 MB. You can override this by sett  
>ing MaxMemInQueues by hand.
> Feb 24 10:45:08.671 [notice] Scheduler type KIST has been enabled.
> Feb 24 10:45:08.671 [notice] Opening Socks listener on 127.0.0.1:9050
> Feb 24 10:45:08.671 [notice] Opening Control listener on 127.0.0.1:9051
> Feb 24 10:45:08.671 [notice] Opening OR listener on 0.0.0.0:9001
> Feb 24 10:45:08.671 [notice] Opening Directory listener on 0.0.0.0:80
> Feb 24 10:45:08.000 [notice] Not disabling debugger attaching for 
> unprivileged users.
> Feb 24 10:45:08.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
> Feb 24 10:45:08.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
> Feb 24 10:45:08.000 [notice] Configured to measure statistics. Look for the 
> *-stats files that will first be written to the d 
> ata directory in 24 hours from now.
> Feb 24 10:45:08.000 [warn] You are running Tor as root. You don't need to, 
> and you probably shouldn't.
> Feb 24 10:45:08.000 [notice] Your Tor server's identity key fingerprint is 
> '123'
> Feb 24 10:45:08.000 [notice] Bootstrapped 0%: Starting
> Feb 24 10:45:09.000 [notice] Starting with guard context "default"
> Feb 24 10:45:09.000 [notice] Bootstrapped 80%: Connecting to the Tor network
> Feb 24 10:45:10.000 [notice] Bootstrapped 85%: Finishing handshake with first 
> hop
> Feb 24 10:45:11.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
> Feb 24 10:45:12.000 [notice] Tor has successfully opened a circuit. Looks 
> like client functionality is working.
> Feb 24 10:45:12.000 [notice] Bootstrapped 100%: Done
> Feb 24 10:45:12.000 [notice] Now checking whether ORPort ***:9001 and DirPort 
> ***:80 are reachable... (th 
> is may take up to 20 minutes -- look for log messages indicating success)
> Feb 24 10:45:13.000 [notice] Self-testing indicates your DirPort is reachable 
> from the outside. Excellent.
> Feb 24 10:45:13.000 [notice] Self-testing indicates your ORPort is reachable 
> from the outside. Excellent. Publishing server d  
>escriptor.
> Feb 24 10:45:14.000 [notice] Performing bandwidth self-test...done.
> 

You need to give us the IP address of the relay so that one can check if
the ORPort is reachable. It should be, since that is indicated in the
log messages but doesn't hurt to check.

It takes some time until you can see it on atlas / relay search, it's
not instant. Give it up to 24 hours. You will see it earlier here (but
not instantly under any circumstances):

https://consensus-health.torproject.org/consensus-health.html

(careful, large page and can take some time to load) by searching for
your nickname or fingerprint - see what the directory authorities have
to say about your relay.

The IP addresses of all relays in the network are public and not
considered sensible information, but I can see a possibility where you
don't want a certain IP address tied to the email you are posting here
with, so it's up to you to decide but you can go to a port checking
website (google it) and check the relay IP address ORPort if open or not.

If yes, wait for 24 hours and check back on relay search.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] whonix tor-relay - help needed

[s7r]

peter.zehet...@liwest.at wrote:
> Hi there!
> 
> I try to configure a tor relay on an whonix-gateway but I allways
> receive the answer that my server has not managed to confirm that its
> ORPort and its DIRPort are rechable.
> 
> How can I fix this?
> 
> Thanks Peter
> 

If you're using whonix-gateway you are probably in a virtual machine
that has a NAT virtual adapter with the host's physical network
interface. You need to forward the ORPort (and DirPort) from host to
guest in the virtualization software -> virtual network editor settings.

If the host itself is behind NAT you might need to do yet another port
forwarding in the router that connects the host to the internet.

Or, you can setup in the virtualization software, for the network card
attached to the whonix-gateway virtual machine Bridged networking
instead of NAT, so that it will get an IP directly from the router and
just do just one port forwarding from the router to the
whonix-gateway-vm IP instead of two.

However, unless your host has many many resources, it does not make
sense to run a Tor relay in a vm. There are torrc settings that make it
use as many resources as you'd like to give it (ram, cpu, bandwidth,
including accounting for metered connections). I recommend you install
Tor directly and properly edit torrc to satisfy your needs.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] default exit notice HTML page on exits?

[s7r]

nusenu wrote:
> 
> 
> Eran Sandler:
>> I certainly think it should be added by default.
> 
> I agree that an html page giving some basic information about 
> tor on every exit relay IP makes sense.
> 
> If there are no major concerns from other operators to enable 
> this _by default_ I will open a trac ticket to start
> discussions with the tor developers.
> 

I agree this is a very useful feature, I use it on all exits. But it
only makes sense if DirPort is running on port 80, otherwise nobody will
just try the IP address with :randomport in their browsers until they
see a working web page.


Also note that since some time BEGIN_DIR is used, so relays serve
directory data via their ORPorts, thus not making DirPort mandatory if
you want to serve directory data. The long-term plan is to entirely use
ORPort, so relays will need 1 single port to run for both Tor traffic
and Tor directory data, making things easier to configure in firewalls,
less data in our consensus documents, etc.

It will not hurt if a page is added as a default if the relay is Exit
and the request is HTTP, display an info web page, but this again will
only make sense if ORPort == 80.

I think it's simpler if this is pushed to the operator's control, to do
it at their own choice. Maybe one wants to run a webserver and show that
page, or even more advanced statistics like bw usage, etc. Maybe one
wants to add his company banner, or etc. Making this optional and
configurable at operator side makes sense, since it's hard to come up
with some sane defaults that will just work outside the box for everyone.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Directory Server and bandwidth accounting

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 6/26/2014 7:46 PM, Kali Tor wrote:
> Hi,
> 
> Is my understanding correct that if I set AccountingMax, the relay
> will never be used as a DR?
> 
> It kind of feels odd because in my situation I can donate 500GB
> (and maybe even more) but I do want to keep a max limit and at the
> same time let the relay be a DR as well. Any way to achieve this?
> 
> -kali- ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Hi Kali

Where did you learn that AccountingMax argument will prevent you from
being a directory server?

I can not confirm or infirm this information, but as far as I see in
the manual there is no such reference for accountingmax.

500GB per month is little amount of traffic, seriously. My 100mbit
relays made on virtual servers consume 6-7TB of total traffic per month.

Use the accountingmax argument and you should be fine, it's better
than capping bandwidth and it is a great help for the network.

Thanks for running a relay.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
PGP Pubkey: http://www.sky-ip.org/s...@sky-ip.org.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEbBAEBAgAGBQJTrFSwAAoJEIN/pSyBJlsRfVAH+PZzfzkCV6i6p8fC16PmVEBa
1cmbYloi+/edIniSrpo4KnYTSJVRBg/6Sg7CrZYlTymdM5mr5HIrAOFiIrEb5iu1
jUAryPsU9UQzSlgNzX/WwZQrwz0KSoGpp5t9fiF+DdQhObE3r16DVjQkjh7aIQQR
c0pqWGoLfGgx3KbXpLqLczQio9++wf9wQ0gKB9tcnTOxYGHl1qFDKpqwFqQ7Y8LB
55XbG70+ncSKWGMhIc6Hkg9XxhRigKo7A97dj+vBupEu8fUdhp1sWGdZUFEmYXKv
L5kaZBsD9jsdMWHW7N4U3fATylyNjceOu7ZIU6wouQG/LRH6c26467xOa/W6cQ==
=vEBO
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] optimize performance of a relay running on a VM

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have multiple relays running on the following systems:
- - vmware vsphere virtualization technology
- - 100 mbps port
- - 1GB dedicated RAM
- - 2.6 Ghz 1 core CPU dedicated
- - OS: FreeBSD 10.0 Release amd64 or Debian Stable
- - DO NOT KNOW IF I HAVE AES-NI SUPPORT OR HOW TO ACTIVATE IT (?)

Currently atlas shows 3-4-5 MB/s advertised bandwidth for these
relays. Arm shows between 600 and 1200 concurrent circuits (total of
inbound, outbound and exit) and average traffic consumption is 5-6 TB
per month (total both download and upload). I think this can be
improved, but how?
The servers have only purpose Tor, there is nothing else running on
them and there is no bandwidth cap or throttling.

Suggestions? Thanks in advance.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTswH9AAoJEIN/pSyBJlsRtTMH/jFV2FdfSksYNalSn9fmHcRk
sKoWfNuRL/FQAQ1R0faN0F3lemOfDq80vosmd95h5EIZG7UmmN/xs9s8K9PQAzxf
j3XHwCtYVkKkEA1djdAbFUB5s3WN6ieNm0qnnqZeBk16A9vJeRI2wkYFPRaDn6c5
n9u+p5QUjRmBKMkY/TOZ12TWSdeD683SoGdx4O5FeP90B+Q61SFgDtkvX6wtWKZr
flWM/Bf0gpQL6Qowl9E49J5dJj+RgSYqPZ943x37nutBYzGmn0pbqXU1ulg0WFuz
3tu4bjwLITg1BB64jnF9hwn91pnd8ECay8OMqnZxbI1QycvPTPcNkwkasqARfTs=
=MJBs
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] optimize performance of a relay running on a VM

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/1/2014 10:07 PM, Random Tor Node Operator wrote:
> On 07/01/2014 08:46 PM, s7r wrote:
>> I have multiple relays running on the following systems: -
>> vmware vsphere virtualization technology - 100 mbps port - 1GB
>> dedicated RAM - 2.6 Ghz 1 core CPU dedicated - OS: FreeBSD 10.0
>> Release amd64 or Debian Stable
> 
>> - DO NOT KNOW IF I HAVE AES-NI SUPPORT OR HOW TO ACTIVATE IT (?)
> 
> $ cat /proc/cpuinfo | grep aes
> 
It does not return anything. I have the proc folder, but there is no
cpuinfo file in it. Here:

root@tor:/ # cat /proc/cpuinfo | grep aes
cat: /proc/cpuinfo: No such file or directory

> If it returns a string of instruction sets, your CPU has the
> AES-NI instruction set. If it returns nothing, it doesn't.
> 
> 
>> Currently atlas shows 3-4-5 MB/s advertised bandwidth for these 
>> relays. Arm shows between 600 and 1200 concurrent circuits
>> (total of inbound, outbound and exit) and average traffic
>> consumption is 5-6 TB per month (total both download and upload).
>> I think this can be improved, but how?
> 
> What does the CPU usage of the tor process look like?
 PID USERNAMETHR PRI NICE   SIZERES STATETIMEWCPU COMMAND
  675 _tor  2  200   130M   126M sbwait 567:31   7.96% tor
Uses maximum 10-12% of the available CPU.
Uses maximum 150 - 160 MB of RAM. (~15%)

> How long have your relays been running? It takes a while until a
> relay reaches a steady state. [1]
Little over 2 months if I recall correct. Exit, Guard, Stable and Fast.
> Can you tell us the fingerprints of your relays?
> 
here is one I am freebie hired to maintain:
6C36F9ACBA57AC9C10DBC39D330CFA337522E72B

> At least in terms of your hardware, you should be able to roughly 
> saturate your 100 Mbit/s line.
> 
> 
> [1] https://blog.torproject.org/blog/lifecycle-of-a-new-relay 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Thank you for prompt reply and looking forward for your help.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTswsDAAoJEIN/pSyBJlsRws0IAItoJ1gQxlfKwmBIuUHgsAyJ
FA2F1s/N4tU4zrC8oLQEayI8nKNRyRK8armLRRm1fDOR5ZomRov/ThnJA55boZv/
RF8p4aMNSAehOJAGgRbUwFmjL4NTuvZBEeC8TOHrDSKX6SB2R210RhyucBpRID3C
l2D7nITPnqGVM3zeZ3d79LMWGo9MQ6CBYHosE4MmmVCwYPI3abRDXNLWEdii7AvR
1qt24HQeartxf1AIiJRph05/PlZRbh0RkdATz+lYeAhwz0ryRkncYbU8SRkK5jnf
s5VwqDqOuUDp1k7Grn7f7SERwCzlNKWhg1kLfxKWevBL4Q8WX47Xvjaw827dPUg=
=mYES
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running tor in VPS - keep away snooping eyes

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/2/2014 9:50 AM, Kali Tor wrote:
> All,
> 
> Are there anything special that needs to be done to make sure that
> Tor nodes running inside VMs (VPS) is protected from snooping eyes?
> Since there is hardly any data at rest I am assuming not, but then,
> what do I know!:)
> 
> -kali-
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Kali

I don't understand what exactly you mean, snooping eyes.Anyone can see
at anytime that the VPS in questions is a Tor relay. 1 method is by
seeing the traffic it generates and second is the consensus data in
the Tor network, where all relays IP addresses are listed. This should
not be a problem whatsoever, Tor is not designed to hide the fact that
you use it or that you run a Tor relay. It is designed to offer
anonymity and privacy in activity, not if you use it or not.

If you are asking how to secure  your box better, indeed the public IP
address list of relays is often scanned and brute forced. That is why
I recommend:

- - if you run only Tor on that box is best, if not make sure your apps
are properly secured (mysql not listening on public IP if it's not a
remote mysql server, strong passwords for mysql, ftp, etc.).
- - make sure only ports used by Tor are open. There is no need for
anything else.
- - if you use ssh for administration that is fine, just change the port
from 22 in /etc/ssh/sshd_config to some custom port, anything, like
2988 or whatever.
- - permanently disabled plain password authentication or rhost
authentication in sshd_config and only allow key-based authentication
for better security and protection against weak password probing.
- - do not allow any other users for SSH access.

Let me know if you have any other questions.


- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTs+YiAAoJEIN/pSyBJlsRqwwH/1yYOsjM/7eVB4S6BjkEVbdZ
cNXeYB2wyFQdKWiGXTfEyXBdTWUMiXl2YJNol1K8L0bDhv3H90lRBzhGpxUGbIjr
BPZqwUYvR8FnzildmmUTRlzntq0mfbMQ9E7jXWhepS95QA5JxH2D4Bl2qCb7//uq
HXlB76YIdDS3D57wKlF8r2JGFYlIbg38gEtvnY2X4755KpJrxlFUPkqVsLAl4j5c
z9PQzR0qw5mdEnMGWFdkve4Qlq1FL9lYx0+UmO0VCGcpiHcHMLhtVTMX6Ieq/zGP
apTJ8L5EmUaIdrCUilU4thkouBbVjnPKS3R65HXy2AjujuxtR+fuTkXyNbeAp1k=
=Wk0Y
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running tor in VPS - keep away snooping eyes

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/2/2014 2:46 PM, Kali Tor wrote:
> Hi,
> 
> 
>> 
>> If you are asking how to secure  your box better, indeed the
>> public IP address list of relays is often scanned and brute
>> forced. That is why I recommend:
>> 
>> - - if you run only Tor on that box is best, if not make sure
>> your apps are properly secured (mysql not listening on public IP
>> if it's not a remote mysql server, strong passwords for mysql,
>> ftp, etc.). - - make sure only ports used by Tor are open. There
>> is no need for anything else. - - if you use ssh for
>> administration that is fine, just change the port from 22 in
>> /etc/ssh/sshd_config to some custom port, anything, like 2988 or
>> whatever. - - permanently disabled plain password authentication
>> or rhost authentication in sshd_config and only allow key-based
>> authentication for better security and protection against weak
>> password probing. - - do not allow any other users for SSH
>> access.
>> 
>> Let me know if you have any other questions.
> 
> I have done all that, so covered on that aspect. Was wondering if
> disk encryption and use of something like TRESOR would be useful?
> 
> -kali- ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Full disk encryption on a Tor relay, if it's just a Tor relay it's
overkill. It will just increase the HDD I/O rate and resource
consumption.

Also, most important, if you use full disk encryption and your vm gets
somehow rebooted (migrated to another cluster by your provider, update
to the host OS or hardware, etc.) and you are not around to enter the
passphrase for full disk encryption your operating system will not
boot and cause you long downtime, until you are available to manually
enter the passphrase. this can cause you to lose flags in the
consensus, because of extended downtime.

Important to say that Tor does not have any files which need to
encrypted. Tor, by design protects each relay by not knowing both the
original source and the final destination of the traffic. It just has
some cache of the consensus data, which anyone can publicly get from
the Tor network without needing to break your box or hack your full
disk encryption.

Only things which are secret are your onion keys, which give your
relay's fingerprint. Make sure you back those up, in case you need to
re-install this relay.

If you use that vm for something else too and you have some sensitive
data there, it is always a good idea to encrypt everything... but in
your scenario full disk encryption will not help since you are exposed
to physical attacks (e.g. someone caching your files while your
virtual machine is RUNNING, making full disk encryption useless).


- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTtCldAAoJEIN/pSyBJlsRIYEIAJ6aN9MLeDhhssA6SR8fV8JS
Vmn8mJ4rbazE8JFkIqxf6sDHHPCHOyhHwc1xCe/PqIuIncNqC4G2sXNtoaFo7sMt
dTLa4RvII5JJl0hk4n+F7yoj8QJLEFsdZrPaDs2vyoeK92Hrt+fSLTHmK1bkd0Bn
/AKAcSNlwL4Ls3WrYrigwHFCsNKcpBIpsdukZ/mit4uDnDarPpT4j3Sy5Wm11pYI
Pd3I7TXIh78kUJcjgmrVEEO5a7+SaHvFaCpZwImEb73MdCH+UhyVWnqKV8wbVWGx
ZnXRJ5/d/kevnfiQLIU9/VaWut2lHpwCNgLsQzqYBa8XXPwBjmOzDx2RZrtnxZo=
=VsE4
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running tor in VPS - keep away snooping eyes

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/3/2014 1:40 PM, Kali Tor wrote:
> 
> 
> 
> 
> 
>> On Thursday, July 3, 2014 9:11 AM, Mike Cardwell
>>  wrote:
>>> * on the Thu, Jul 03, 2014 at 10:02:06AM +0200, Lunar wrote:
>> 
>>>>> I have done all that, so covered on that aspect. Was
>>>>> wondering if
>> disk encryption and use of something like TRESOR would be
>> useful?
>>>> 
>>>> The private keys for the node are sensitive, and even the 
>>>> .tor/state file for the guard nodes could be if the attacker 
>>>> does not already have that info, same for any non default 
>>>> node selection stuff in torrc. Tor presumably validates the
>>>> disk consensus files against its static keys on startup so
>>>> that's probably ok yet all easily under .tor anyway.
>>> 
>>> Some says that it's better to leave the disk unencrypted
>>> because in
>> case
>>> of seizure by the police, they can easily attest that the
>>> system was only running Tor and nothing else.
>> 
>> Even if it's encrypted, you can easily attest the exact same
>> thing by handing over your password... If you choose to do so.
>> 
>> 
>>> Some disagrees and says that we should always encrypt to make
>>> tampering and (extra-)legal backdoor installation more
>>> difficult.
>>> 
>>> I believe the best strategy has never been really determined so
>>> far.
>> 
>> I know of only two benefits to not encrypting.
>> 
>> 1.) On some systems, for some workloads, you might have some
>> level of improved performance. For a Tor node, I doubt there is
>> any noticable difference.
>> 
>> 2.) You can reboot without having to enter a password.
>> 
>> Encryption gives you choice. The choice to hand over your
>> password/key or not. As far as I'm concerned, "the best strategy"
>> *has* been determined and it's to encrypt...
> 
> Thanks for the discussion on this.
> 
> If disk encryption is indeed the way to go, how many of the node
> operators do actually encrypt the disk? Has there been any
> performance issues? I ask specifically because I run in a VPS where
> resources are limited (compared to a proper machine).
> 
> - kali-
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Depends, what configuration will that virtual machine have?
You shouldn't notice too big of a difference, full disk encryption is
not a resource killer on any configuration.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTtTopAAoJEIN/pSyBJlsR9lkIAIYVigtTOYcYeihEJLx8yWs+
WRc/1p9u/YuSA62enSpqkuYYOtvMLsJiGtdRzr66kyrIqgifIStOAyTkd2un+QLq
nRl2OY/jmhwg0EM0EGpdzDo9qMzEPpDOfRtoJhotnB+0Aurl8Bt6PuNhSezY3a3X
VUmKaNf13SCyqyiB3cty+/gpSpTrQRoCH0lV/QtrMvHo8KqOknSbRa7LyylDz6Wv
fH6C8UnIU6ueL2RxRV8h+cIla52mRJStv2LWO3+IqFBnGPrbFlZks7OjYaY74nEI
r3YMg7dDgy9jT7QuL2LIBxGKsXAdDEeww+xLtbd1KRlYwt6W+JHtbVkhpO3Yfic=
=3pg1
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running tor in VPS - keep away snooping eyes

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/3/2014 2:18 PM, Kali Tor wrote:
> 
> 
>>> If disk encryption is indeed the way to go, how many of the
>>> node operators do actually encrypt the disk? Has there been
>>> any performance issues? I ask specifically because I run in a
>>> VPS where resources are limited (compared to a proper
>>> machine).
>>> 
>>> - kali-
> 
>> 
>> Depends, what configuration will that virtual machine have? You
>> shouldn't notice too big of a difference, full disk encryption
>> is not a resource killer on any configuration.
>> 
>> - -- s7r
> 
> 1GB RAM, 1CPU Core, 20GB SSD. Currently being used just for Tor.
> 
> -kali-
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

Yeah, as i thought you won't notice any penalty over performance if
you enable full disk encryption, just keep in mind you have to be
around and enter the passphrase at each and every reboot otherwise the
operating system will not boot.

And on a virtual machine, full disk encryption will not protect you
against physical access to the host machine while the VM is running,
keep that in mind (the decryption key is stored in the RAM memory
otherwise the machine cannot run, they can pause, capture files,
resume or unlimited of other things to break your encryption).
- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJTtT6eAAoJEIN/pSyBJlsRT54H+wfYw2ZliTXKoL4mXyJhdzo1
wTjzjj0ONNPNOrqtdRPMLZgS7Vs0ej36rDtYdnAJSNn5XtlGkfgp5WWMzVZZuKo9
ABc7Q92YmSeWv1KCpvglA2B06Eew+8rh2j3FCRCWqb4v6BqjiohFdrB+3X5QVp6P
6LwZb4ds2PQVjqmEoEe3PHZM8jFmq8FwV978xaiAoxvvcvjLjz3rJSlGTUG60XRK
mL5O1WDtx8F4OGDvFTLCsAt8+QMEBcgmu+lIOTxGIvW4Nz4L6/W7O+JG8O+zTIcS
ae9k823JNBxIf9WgKrKzdO0B/t/4fcHiDCwrKpXJjzndirXAFsv+9LpEhLatkSE=
=L51B
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] German company Webtropia: Terminated contract without notice because of abuse

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 7/30/2014 10:34 AM, u...@riseup.net wrote:
> Hi all,
> 
> I've been running two exit relays, [1] and [2], at the German
> company Webtropia [3] for the past two weeks. Things went quite
> nice and smoothly, the speed of the server was decent and the
> network great, pushing quite some terabyte.
> 
> Before renting the server, I told them what I wanted to do, if the
> would forward abuse etc. They said there were fine with this and
> forwarding would be no problem, given that I would deal with such
> mails in a timely manner. So I decided to rent the server, maybe
> naive?
> 
> Yesterday (29th) they stopped routing/switching traffic to the
> server, so it wasn't accessible anymore. They sent me a mail, the
> subject read "termination without notice", claiming they did this
> because I didn't pay the invoice. I replied that I doubt this and
> sent them the transaction details. Their reply claimed that my
> contract wasn't quited because of this, but instead of abuse: They
> wrote that they got "52 mails" the day before (28th) dealing with
> phishing mails, bittorent downloads, ddos, etc. I told them once
> again that this server is housing tor exit nodes, and I'm not
> responsible for the traffic. However, I asked if we could find an 
> agreement and "meet in the middle": Closing some ports (25 for
> example) and forward the mails to me, so I would take care of these
> and they could lie back and think "not our department" (actually as
> spoken about beforehand). Sadly there wasn't any negotiation
> possible, the denied me (up until now at least) even a refund of
> the money I already paid (is this legal?).
> 
> Just to inform you about this. Stay away of them - they don't keep
> their words.
> 
> Cheers, uf
> 
> 
> [1] 
> https://globe.torproject.org/#/relay/94CB5C820BF97391BFDCAF8DD1B3176A452E8FB2
>
>  [2] 
> https://globe.torproject.org/#/relay/55A463CAB24AFB91073C6D6D7CC6CA741A1430E2
>
>  [3] https://www.webtropia.com/en/
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

uf

I had the same problem with other ISP. Required me to register my own
/24 subnet (256 ip addresses) RIPE allocated if i wanted to continue
running exits in their network. Currently working on this.Choose a
different provider if you wish to continue running exits. need
recommendations?

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT2PhIAAoJEIN/pSyBJlsRGC8IAM6YObPduacoNR3ZwLsjLowr
HDvEZQvNcf/46ikEoxq7F+x7b1Ur55iY4jTTMjIDiXnhZyifVpk5fJiiKZdSB6Zi
m8YwE7JjHBj8T8eVCkZ5dK6o9v/w1DUFxGBo5YhR4iKM0nymoDkZ1ley9Lqd/2O1
fgVNOaZdfMRySMoGvP6vF32ntlmZbgI/quJVXeP9ZQZ4Lx97JcAH9x7a2ceC/lDH
x6yFux5mW601HiM5B92iHAjzkCDKAKl8iQ/cG1omxPyB5/znnDiGkFsyt0BUgzsH
xShKhFdv49e/uP4N6Y7yztQhRIzK9tU0kxCVFi+EhDjP5CUbyfbt+RG7lCZDSWQ=
=6u8T
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Exit node dropped to near zero weight

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/15/2014 11:24 AM, Bill Winslow wrote:
> Hi everyone,
> 
> https://globe.torproject.org/#/relay/5B06042B4911171026059FB694215B97D10E47E8
>
>  I've been running an exit node for a few days now, and around 8
> hours ago my consensus weight and exit probability dropped to
> essentially zero, after dropping substantially several hours
> previously.
> 
> Why is that? Nothing in my logs suggests anything unusual -- but
> then again, I'm very new to this and thus wouldn't know where else
> to look or what to think about this.
> 
> http://pastebin.com/mfkbPK9L
> 
> Thanks for your time.
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

One of my relays also had the consensus weight of 620 and today I
checked atlas it decreased to just 20, and nothing unusual in the
logs. Its uptime is the same like yours, few days (9 to be exact).

I guess this is normal and it will grow to normal. The lifecycle of a
new relay blog posts explains it, in a way.

Just give some more time to run and it should be OK. I saw your
advertised bandwidth is 512KB/s - that is reasonable, but the higher
you can give to your relay, the better and the bigger consensus weight
it will have.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT7ea4AAoJEIN/pSyBJlsRzbIH/j99k3NaUG/VQgQXaEvRhF3R
2vzV55t6M56KnL/DUr6ESbF9jHMZnpchAR2w5zIfmtJkw34Se2mxrjGXWJqnue/8
fOH8JVSh/7cqmyoQAVjhTBBtrk5Nbkqz7QDAQYER+7KfAgBiMfocmeR1E++t5C9N
O+V5w/yM4deOh21z9bbMRgAEaAUPHAa2gSsHTNMtPCZxOWLN51o/cAj4ppjwsiNn
d/gphWJOE1AwFrQr4foaIdPBmrUiYQq7DXToMtGSCvks8j6mpzrtk/mcXCn89aFh
dKrprPTPl2/kyu7Rn6CfdpFRzZs2kJAGKbeZFrHi658oncfVhGCSEazj4h6vR3M=
=FeK0
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Advertised Bandwidth

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/16/2014 3:33 AM, Mike Patton wrote:
> Hey there,
> 
> The advertised bandwidth will increase gradually. Well mine did.
> 
> M.
> 
> On 16/08/2014 10:28 am, IceFish ThreeTwo
>  wrote:
>> 
>> Hello!
>> 
>> I'm unclear as to what the "Advertised Bandwidth" is on Atlas. My
>> node has it's bandwidth set to 700Kb/s, however on Atlas the
>> Advertised Bandwidth is around 7Kb/s. I'm on day three of running
>> this relay and I have read the Early Lifecycle blog post, but I'm
>> still confused as to why the Advertised  Bandwidth is a hundredth
>> of what I have it set to.
>> 
>> Thank you! Ice Fish
>> 
>> 
>> -- Sent from my iPhone
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 


The Advertised Bandwidth will increase as uptime counts up. All you
need to do is keep your relay running and it will come to as much as
you set in your torrc (RelayBandwidthRate and RelayBandwidthBurst). It
cannot reach the maximum in few days. I have a relay running for 10
days, I haven't set any limit o it (it has a full 100mbps port) and
atlas shows it 650KB/s so - waiting is the only thing you need to do.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT7qxBAAoJEIN/pSyBJlsRURcH/3f/7jZ8gGrJNxlbp/GFp9Xs
WrNYT95jNg3pehzKsi+EoJuoCXIhOpNN4WH/lM7XyWwsZzfQ78liCLMOHDBMKAsP
hc01LKZyXlvaSxIJxlK4rVQd+w+KUfSigDxB6xG6ztU1oezVcyQZpR8xeHOGXR8g
qpHII43Iw+JpiIfBv3pH3na0bDvR8lVYcHzi6Wgu1E2DzUac0P4Fa+JUZOnVqJas
7B+LXiNprqX6SH6e8HCLhj9yOzNfA5LYlt/QillNGlvfYFi540ehq8tsdfskY1ZQ
GGBx1Ld96/S9pGkyH0dzlUGABJNERjOilIlWtdloWvqYG0Q3FFLoj5GCA5ntOWY=
=zmXd
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] icetor's loki2 update status (CVE-2014-5117)

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/19/2014 4:15 AM, Rex Wolf wrote:
> On 18/08/2014 4:48 PM, Tim Semeijn wrote:
>> For at least 24 hours I have been noticing that statistics of my
>> nodes like uptime and MyFamily are not updating as they used to.
>> I issued them all a reboot and changed the config but no changes
>> yet to be seen.
> Agreed. I just updated two of my relays today (including a reboot
> to one of them), but Globe hasn't registered the change yet. Uptime
> is continuing to accrue as if I never rebooted or restarted the
> relay, and the old version is still listed.
> 
> -Rex
> 
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

There is something going on with atlas and globe. They have huge lag.
A relay is not running for 2 days (it has changed IP address and
fingerprint) but still showing as running on atlas and counting uptime
forward. in https://consensus-health.torproject.org everything is fine
however. The same as torstatus.blutmagie.de everything fine and
accurate, just atlas and globe have lag. Someone needs to look into them.


- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT8qeHAAoJEIN/pSyBJlsRBH0IAL2kdARDPoJ4lyZ8EJlLo7pK
bYXVqtlDp464tr0qQGG+vqkGmkctxtnD1qza49p2bo/A5eXxdaYoYFkn9EWSlBY1
BXSkqjZ73W9Hn4v9/z+mr1ZfijitLThDkgdHgilw+9iS19vYxz50VOk0ygUDhPVU
PFr34/QtFRbZGS5fzsxeXr/2XJQ+vHrBP2yL0gLfLEUR8af/qUlZrS97t+VnNSTn
Lfr/k6fhrACAQs8IY4lfRq5XTeE9zDs+jndPl+IKjqXQTNoNFWy6TQSSfLXZCgeJ
3MCW/wEiOYPv2fK2cMAi58vA8jNrBoHWegn380651TL26FpnZy9Aovnh01JvjHk=
=TlO4
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Centos 7

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 8/28/2014 6:09 AM, Adam Brenner wrote:
> On 07/23/2014 10:23 AM, obx wrote:
>> There are no packages for centos 7 yet.
>> 
>> Is there an ETA?
>> 
>> Is there anything we can do/contribute?
>> 
> 
> See the following link[1] on the Tor website.
> 
> [1]: https://www.torproject.org/docs/rpms.html.en
> 

Tor works perfectly fine on CentOS, Red Hat Enterprise or Fedora. Find
here a nice easy step by step tutorial:

https://www.sky-ip.org/configure-relay-rhel-centos-fedora.html

Mail me directly if you have questions. Make sure you add repos
properly to avoid package name collisions.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJT/12qAAoJEIN/pSyBJlsR524H/jTPL1L7sH1h5BBRdbeDgJ/B
nZKm1BR+gwZYsQaxjQgQ48Wfb3mAUTz7Ge9S8M2s1FOiUzeupI0ZThUjvMx0rj5m
iy7363ZTPdpjm4h56mknxnOv1Ev1BqZAWnwrOsPZ0lyV+ygibJgdwzQgT6C0CoKf
2qpFCqhkJwXRFy8QvNatYJbeKZJ6lX/Xmi6Jr25KQHeTkyfTReTpY8CIT74AaTDV
4WFjFRNnSKJ5Ebi96ttCcmioMR+GxQntghJmIeDfld0ba2l2M9OFgcYjr0pDIwl7
X9ez5nt4YK6GWmdpnTjL10lYlyK4sEGWBHusDnv2xYozDDAsFfdFHgL6PB5VbTY=
=5Vx2
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] boost CPU on a Tor relay

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

A Tor relay currently going 33MB/s could go a lot faster but CPU is at
93% usage - this is the bottleneck. Here is the output of /proc/cpuinfo

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 26
model name  : Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz
stepping: 5
microcode   : 0x11
cpu MHz : 3068.000
cache size  : 8192 KB
physical id : 0
siblings: 8
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 11
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm
tpr_shadow vnmi flexpriority ept vpid
bogomips: 6132.24
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

it also goes down to processor 1 - processor 7

Any ideas how this could be boosted? OS is Debian wheezy. No aes-ni
hardware acceleration, no openssl benchmarking or customization
currently. advices? Thank you.

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUDuRTAAoJEIN/pSyBJlsRLqYH/iSCtC9r/7/DBCG2qqUGPEgY
TELvt+UMGyMP6ncNJH+vDEdHO4BBlSMzFQdj2sKyO3hOT5492cIOaT3gGokaDApL
W913yqUkIfiUT6FUWJ6g4/LUt25pMG25Ednr/ZJJXR/pR+Ym3T3ytg+MSwRBmpEe
+h26Q7qvd/p4f6VhTR0sEsxQfDLVXrEsj3kn0BL0rLklN5zH/bqmIsK2hio5Nl3H
KBvbvyt+JbLhA/4+jygT6AygHDH9arpXWEh3ZcJVn7mE0OmPAvukdlLUj70K5F7r
cCeMakcGBbSzit5tY7jUmSvkUewVBhAxAZmv1hgNnuCoSrGPtQZseCbM06cry+k=
=TyKF
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] boost CPU on a Tor relay

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 9/9/2014 2:43 PM, Moritz Bartl wrote:
> On 09/09/2014 01:28 PM, s7r wrote:
>> A Tor relay currently going 33MB/s could go a lot faster but CPU
>> is at 93% usage - this is the bottleneck. Here is the output of
>> /proc/cpuinfo
> 
> 93% CPU across _all_ cores for 33MB/s sounds a bit too heavy. Are
> you maybe only running one instance of Tor and it maxes out one
> core? Spread the load to more cores then, and limit each of the
> relay processes so it stays well below 90%.
> 
> https://www.torservers.net/wiki/setup/server#multiple_tor_processes
>
> 
Yes, it's one Tor instance - I thought it will use the network better
this way. How many Tor instances should be there 4 or 8?

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUDuf5AAoJEIN/pSyBJlsRz44H/3ayBCp1LaXQb2FxTau1ME/m
W2Dft0vHQVzSR3cmx1mER/qD5ltVDsq0i4FgnoHhOA6quKlRyQYKtBkCZ3AQK1Sh
VGio0NRBEry+TpqJoD9xnkcE9ubUrRvNf3MnLYG14ooNoo65fpME/ie3xuVNfPp/
aaWoZVh1sICy+xsc9dT6HkeSDAaT/QCjLXZZ4HtYfk2UcQD63sCEukXrq/IRgR+E
ylhvDacgFREQoH+M+58xLmCmZcngYwurDmGbjYaVOiRvp0udpGvhqGdAn/IPrpHi
EB4MC/C2DVIL27B0uXebMuYdJ2wGJ+RiZ6zS0519cb/soCmnM1DUNalBSel0lVM=
=6XFi
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] RELAY_EARLY tor network update status (CVE-2014-5117)

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have checked the whois records for the IP addresses of the outdated
relays which you earlier advised and found their providers. Opened
support requests and sent them a message.

Records were as follows:
93.174.90.30 supp...@ecatel.info n...@ecatel.info

82.165.197.129 supp...@1and1.com supp...@1and1.com

91.205.172.16 supp...@contabo.de

These 2 are in online.net network where they don't provide an email
address, you need account registered with them to contact them. Maybe
someone with account there can open a ticket and send the draft letter
provided below?

IPs of Online.net relays which need contacted (to include so they will
know which customers to notify):
195.154.243.53
195.154.226.66


Dear Provider,

I am a Tor supporter (www.torproject.org). I contact you with a request:

I have identified your customer with IP address  runnig a Tor
relay to help the network (very nice) but unfortunately running an
outdated version for which we have a security CVE and there is a patch
available. Latest Tor release is 0.2.4.23 and your customer needs to
upgrade to this one. Patching the relay is a good practice which will
make the network safer. The bug discovered IS NOT CRITICAL so there
are no serious security threats (no cause to panic), but updating is
always better.

The reason I am contacting you (the provider) is that your customer
has not provided valid contact information in his Tor relay settings.
Can you please kindly forward this notification to your customer and
confirm that it was done? It is in the benefit of everyone, so it
won't get anyone annoyed.

I am sending you this message as an individual Tor supporter and not
on behalf of Torproject.org to which I am in no way related other than
supporting the network as a volunteer.

Thank you in advance for your cooperation and sorry for the approach
but I have no other way to reach your customer.

On 9/19/2014 12:00 AM, Nusenu wrote:
> (if you are on the CC list of this email you are probably one of
> the tor relay operators running one of the 10 fastest vulnerable
> [CVE-2014-5117] relays on the tor network. Please upgrade your tor
> relay)
> 
>> The tor network is currently at 64% of the bandwidth being served
>> by relays running a recommended version according to
>> torstatus.blutmagie.de. I updated a previous metrics feature
>> request so we might see nice graphs about patching progress in
>> the future [2].
> 
> Since we are seeing active RELAY_EARLY attacks again (or new buggy
> tor implemantations) I was wondering what the current update stats
> look like.
> 
> ~85%* of the tor network's bandwidth is provided by patched
> relays. (~66% 0.2.4.23, ~11%  0.2.5.6-alpha, ~7% 0.2.5.7-rc)
> 
> *) according to data from torstatus.blutmagie.de
> 
> 
> 10 fastest relays still running a vulnerable version:
> 
> https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036D0A
>
> 
https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB834
> https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FDC89
>
> 
https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B032E5
> https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A896842C2
>
> 
https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A442
> https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA3D2
>
> 
https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A73E
> https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A1BD
>
> 
https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BEE19
> 
> _______ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUG1JpAAoJEIN/pSyBJlsRbgQH/0k2+9+U2EbVomPdMPvOvi94
wLcI7wGe7dUeOGHh746+0cZvUi5EtCX4T4JjeP8iUY0+uMiIw+iCcBekQNzSjieW
l78++e3HZ1e5CNZIJjAPRt1fPbba87DVF2ms8SjVCClDSjPxeSC7QZpNtNQonDIK
QZ7JZyNi0zn+nffd3i32pSh5YWJoIbI2GbF1RYNJwq906XuvFfagNokDZnRB56ko
bx2CPPWxVWLN5K9pkH4WXRaFCaX0o2KkijU+KvU+rsT3ukIWMhahIT19lX+mIzTA
KX08C42sH0V8+IxCjjWq6+wAaGj3EPRT4JyAaDAerB2cCqs3qMDMupMxUGxHvnQ=
=PpB0
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bandwidth not being used by Tor on Gigabit dedicated server

[s7r]

cept *: # HTTP Proxies, NewsEDGE ExitPolicy accept
> *:9418 # git ExitPolicy accept *: # distinct ExitPolicy accept
> *:1 # Network Data Management Protocol ExitPolicy accept
> *:11371 # OpenPGP hkp (http keyserver protocol) ExitPolicy accept
> *:12350 # Skype ExitPolicy accept *:19294 # Google Voice TCP 
> ExitPolicy accept *:19638 # Ensim control panel ExitPolicy accept
> *:23456 # Skype ExitPolicy accept *:33033 # Skype ExitPolicy accept
> *:64738 # Mumble ExitPolicy reject *:*
> 
> In addition, there's another Tor node running at the same ISP (but
> by a different person), on completely different hardware and a
> different router, that exhibits the same issue:
> 
> https://globe.torproject.org/#/relay/50F37822AFA257B24B3343D9BBFB0442E900FB4C
>
>  For background, I built and manage the network both servers are
> hosted on and have been doing so for 20 years. I also built both
> servers. The network is at less than 15% capacity, 99% of the
> time.
> 
> CPU load is always at 0.00. Based in the USA, west coast.
> 
> Ideas?  Is there simply less demand for tor traffic in the US?
> 
> Cheers, Jon
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
PGP Pubkey: http://www.sky-ip.org/s...@sky-ip.org.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUKvcYAAoJEIN/pSyBJlsRft0IANm500IF63yielvNcKqVdXQl
j1fe532wa+/Ui3x3CCAj05lAEGFZlIhRZG70HQql+A5tTHFOUQbMhkJloXs5OOMC
XGwMy8f26A6ZbHd4YAtg4p1c6d7YRfd3QJD1k8yERoEG1jEOjtJANCsCuXCult7u
NyXL1t9UD12KMbTckIchBdqr5k2wA9e+RI8O60jSIq3h06kJ7yDA5yO6JNAvVRPE
2FMCxrJ5Bu9wWhp7F4YvogMHXTlcVbVNubOe/D5oBumz7KjsjUPbshaWz3kbXJUY
939O2dB5h3OrZkz9MqnlnpPkqcA4yTFZT8J3cXqtnOvKZx9SXhpj6WAXmua/Mo8=
=IYwa
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Few questions about relaying

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Can you please copy/paste your entire torrc to a pastebin and provide
us the link?

It is hibernating only if you use accounting. Provide us your entire
complete torrc and we will correct it for you if you don't have
traffic limits on your server.

On 10/11/2014 4:54 PM, Blaise Gagnon wrote:
> after a few hours, still hibernating, and still wondering why I
> lost Stable, Guard and Named all at the same time (see atlas
> graph)... weird.
> 
> 2014-10-11 6:03 GMT-04:00 Blaise Gagnon  >:
> 
> no reason for my node to be hibernating, no caps...
> 
> 2014-10-11 3:31 GMT-04:00 Lunar  >:
> 
> Blaise Gagnon:
>> and ... what is "hibernating" ?
> 
> See AccountingMax and related options in tor manpage:
> 
> AccountingMax N 
> bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits|TBytes Never send more
> than the specified number of bytes in a given accounting period, or
> receive more than that number in the period. For example, with
> AccountingMax set to 1 GByte, a server could send 900 MBytes and
> receive 800 MBytes and continue running. It will only hibernate
> once one of the two reaches 1 GByte. When the number of bytes gets
> low, Tor will stop accepting new connections and circuits. When the
> number of bytes is exhausted, Tor will hibernate until some time in
> the next accounting period. To prevent all servers from waking at
> the same time, Tor will also wait until a random point in each
> period before waking up. If you have bandwidth cost issues,
> enabling hibernation is preferable to setting a low bandwidth, 
> since it provides users with a collection of fast servers that are
> up some of the time, which is more useful than a set of slow
> servers that are always "available".
> 
> -- Lunar mailto:lu...@torproject.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
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUOTlTAAoJEIN/pSyBJlsRC0AIAKHjgRlZKXGBC2SoxjKMk+WJ
l7LOVuwp3L7wQJ1L7hHUyJTRAfRZ7OzXlgK3gurg/Bxdhb8BO8W0r+Yk8yVjr4zV
/rLDnibYxO7XCU7wUUdVClhLkDeCzwpu9I+t7bBDsif6T8PkjqjE4pPxwFHcm1T4
oCYvavpWS/K4wNs4PbrbBJBmxXYgzScAwGs00Xr5oBbl9B0aJ2RLfdwEu2blqyHb
XkfSLkdhes4kRnCc5DQhT4BBDPrtCCqe66cOWXSGrH2ji0J29WGnniG3+lbvv0eo
csEioxV7Cn8/ptvkapH4qjYQsHHb1jTG31y/ZOJZhtMHx8hYR+1nxvmlaZKgvYQ=
=rzUm
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Few questions about relaying

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

RelayBandwidthBurst 15 MBytes
RelayBandwidthRate 3 MBytes
ContactInfo quebecf...@gmail.com - 200Mb dedicated relay
ControlPort 9052
CookieAuthentication 1
DataDirectory /home/blaise/.arm/tor_data
DirPort 9030
DisableDebuggerAttachment 0
ExitPolicy reject *:*
Log notice file /home/blaise/.arm/tor_log
Nickname QuebecFibe
ORPort 27645
RunAsDaemon 1


Use this. You are using the latest Tor?


On 10/11/2014 5:11 PM, Blaise Gagnon wrote:
> http://pastebin.com/DQ4k7Fzz
> 
> 2014-10-11 10:06 GMT-04:00 s7r  <mailto:s...@sky-ip.org>>:
> 
> Can you please copy/paste your entire torrc to a pastebin and
> provide us the link?
> 
> It is hibernating only if you use accounting. Provide us your
> entire complete torrc and we will correct it for you if you don't
> have traffic limits on your server.
> 
> On 10/11/2014 4:54 PM, Blaise Gagnon wrote:
>> after a few hours, still hibernating, and still wondering why I 
>> lost Stable, Guard and Named all at the same time (see atlas 
>> graph)... weird.
> 
>> 2014-10-11 6:03 GMT-04:00 Blaise Gagnon > <mailto:quebecf...@gmail.com> <mailto:quebecf...@gmail.com
>> <mailto:quebecf...@gmail.com>>>:
> 
>> no reason for my node to be hibernating, no caps...
> 
>> 2014-10-11 3:31 GMT-04:00 Lunar > <mailto:lu...@torproject.org> <mailto:lu...@torproject.org
>> <mailto:lu...@torproject.org>>>:
> 
>> Blaise Gagnon:
>>> and ... what is "hibernating" ?
> 
>> See AccountingMax and related options in tor manpage:
> 
>> AccountingMax N 
>> bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits|TBytes Never send
>> more than the specified number of bytes in a given accounting
>> period, or receive more than that number in the period. For
>> example, with AccountingMax set to 1 GByte, a server could send
>> 900 MBytes and receive 800 MBytes and continue running. It will
>> only hibernate once one of the two reaches 1 GByte. When the
>> number of bytes gets low, Tor will stop accepting new connections
>> and circuits. When the number of bytes is exhausted, Tor will
>> hibernate until some time in the next accounting period. To
>> prevent all servers from waking at the same time, Tor will also
>> wait until a random point in each period before waking up. If you
>> have bandwidth cost issues, enabling hibernation is preferable to
>> setting a low bandwidth, since it provides users with a
>> collection of fast servers that are up some of the time, which is
>> more useful than a set of slow servers that are always
>> "available".
> 
>> -- Lunar mailto:lu...@torproject.org>
> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>>>
> 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org
>> <mailto:tor-relays@lists.torproject.org> 
>> <mailto:tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org>>
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> 
> 
> 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org
>> <mailto:tor-relays@lists.torproject.org> 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org> 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> 
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
PGP Pubkey: http://www.sky-ip.org/s...@sky-ip.org.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUOTz/AAoJEIN/pSyBJlsR47sH/22x8Fycj/JUaYi+D6NIuGJX
cQO0DRXDsXKt25x9dN85kTmJdTYwnMGAmrGo2jd7ICMM6maANHmd7Ns3QpeTevDH
Gr30xc9QScCYNyDwK1h783gIaZ4dhh87SA0ClakCBie5SQKyars2PiNlFRW5QcWn
fgIVSyEvy8Ld4wzdobJTVd6UpLTjqSJjm4EzItbn79f8UKPoJKW+1BAyebFBcbFM
QAWujcgLcAmmnWTdu5Cci7g8RUMWpnKJKmX3nENPV7CbaeGkgy5u//A42XswL5mV
aox5OqHl3xqQJk4BZwYXEdfYjXq/j8TXTugttuFA6OdSn0eCjsxvXAIGCoH4LxE=
=X1E2
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Few questions about relaying

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

If you don't want to rate-limit, remove RelayBandwidthBurst and
RelayBandwidthRate lines.

On 10/11/2014 5:24 PM, Blaise Gagnon wrote:
> 0.2.5.8-rc yup I'm trying this torrc and will get back to you.
> 
> Thanks s7r !
> 
> 2014-10-11 10:21 GMT-04:00 s7r  <mailto:s...@sky-ip.org>>:
> 
> RelayBandwidthBurst 15 MBytes RelayBandwidthRate 3 MBytes 
> ContactInfo quebecf...@gmail.com <mailto:quebecf...@gmail.com> - 
> 200Mb dedicated relay ControlPort 9052 CookieAuthentication 1 
> DataDirectory /home/blaise/.arm/tor_data DirPort 9030 
> DisableDebuggerAttachment 0 ExitPolicy reject *:* Log notice file
> /home/blaise/.arm/tor_log Nickname QuebecFibe ORPort 27645 
> RunAsDaemon 1
> 
> 
> Use this. You are using the latest Tor?
> 
> 
> On 10/11/2014 5:11 PM, Blaise Gagnon wrote:
>> http://pastebin.com/DQ4k7Fzz
> 
>> 2014-10-11 10:06 GMT-04:00 s7r > <mailto:s...@sky-ip.org> <mailto:s...@sky-ip.org
>> <mailto:s...@sky-ip.org>>>:
> 
>> Can you please copy/paste your entire torrc to a pastebin and 
>> provide us the link?
> 
>> It is hibernating only if you use accounting. Provide us your 
>> entire complete torrc and we will correct it for you if you
>> don't have traffic limits on your server.
> 
>> On 10/11/2014 4:54 PM, Blaise Gagnon wrote:
>>> after a few hours, still hibernating, and still wondering why
>>> I lost Stable, Guard and Named all at the same time (see atlas 
>>> graph)... weird.
> 
>>> 2014-10-11 6:03 GMT-04:00 Blaise Gagnon >> <mailto:quebecf...@gmail.com> <mailto:quebecf...@gmail.com
>>> <mailto:quebecf...@gmail.com>>
> <mailto:quebecf...@gmail.com <mailto:quebecf...@gmail.com>
>>> <mailto:quebecf...@gmail.com <mailto:quebecf...@gmail.com>>>>:
> 
>>> no reason for my node to be hibernating, no caps...
> 
>>> 2014-10-11 3:31 GMT-04:00 Lunar >> <mailto:lu...@torproject.org> <mailto:lu...@torproject.org
>>> <mailto:lu...@torproject.org>>
> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>
>>> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>>>>:
> 
>>> Blaise Gagnon:
>>>> and ... what is "hibernating" ?
> 
>>> See AccountingMax and related options in tor manpage:
> 
>>> AccountingMax N 
>>> bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits|TBytes Never send 
>>> more than the specified number of bytes in a given accounting 
>>> period, or receive more than that number in the period. For 
>>> example, with AccountingMax set to 1 GByte, a server could
>>> send 900 MBytes and receive 800 MBytes and continue running. It
>>> will only hibernate once one of the two reaches 1 GByte. When
>>> the number of bytes gets low, Tor will stop accepting new
>>> connections and circuits. When the number of bytes is
>>> exhausted, Tor will hibernate until some time in the next
>>> accounting period. To prevent all servers from waking at the
>>> same time, Tor will also wait until a random point in each
>>> period before waking up. If you have bandwidth cost issues,
>>> enabling hibernation is preferable to setting a low bandwidth,
>>> since it provides users with a collection of fast servers that
>>> are up some of the time, which is more useful than a set of
>>> slow servers that are always "available".
> 
>>> -- Lunar mailto:lu...@torproject.org>
> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>>
>> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>
> <mailto:lu...@torproject.org <mailto:lu...@torproject.org>>>>
> 
>>> ___ tor-relays 
>>> mailing list tor-relays@lists.torproject.org
>>> <mailto:tor-relays@lists.torproject.org> 
>>> <mailto:tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org>>
>>> <mailto:tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org>
>> <mailto:tor-relays@lists.torproject.org
> <mailto:tor-relays@lists.torproject.org>>>
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>>> 
> 
> 
> 
> 
>>> ___ tor-relays 
>>> mailing list tor-relays@lists.torproject.org
>>> <mailto:tor-relays@lists.torproject.org> 
>>> <mailto:tor-relays@lists.tor

Re: [tor-relays] Tor 0.2.5.10 is released!

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 10/26/2014 9:06 AM, goll wrote:
>> Which package exactly? I'm guessing you're using the deb? Which
>> OS? What CPU architecture?
> 
> No, using the rpm, CentOS 6, x86_64.
> 
>> 
>> The next question would be whether you somehow disabled your 
>> curve25519 support -- but I don't know how to easily check that
>> with the deb.
>> 
> 
> Found this link. could it be distribution related? 
> http://www.denniswinter.de/compiling-tor-crashes-on-centos-at-curve25519-donna/
>
>  And also, I'm running my system in FIPS mode, but that shouldn't
> impact curve25519, it's mainly to disable insecure algorithms like
> md5.
> 
> br
> 
> 
Please note that CentOS is using the OpenSSL custom version from their
upstream distro which is Red Hat Enterprise. Red Hat strips some
things from the ordinary OpenSSL package we use in Debian, including
some curves. I don't know about curve25519 especially, since I am on
Debian and FreeBSD mostly, but I know for sure that CentOS lacks some
EC curves. I have tried to configure a bitcoin wallet on CentOS 7 few
months ago and I couldn't install it as it comes 'out of the box'
because it was missing the curve bitcoin requires to perform ECDSA.

Does this help?
https://trac.torproject.org/projects/tor/ticket/9699

There has to be someone else running a Tor relay on CentOS here, maybe
we can hear from them how their relays are performing.

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUTNFnAAoJEIN/pSyBJlsRwrAH/1SpWw+Rre0pkBvrvBVkomhS
owGGxk3k+vJPUJ5RGMRHak1epXlT2J/zjkf17S5V3nmLejNPV2Clj1BsyO5ULPm2
mGrQHdnuwgvhOw1xPFR7DvlsVZ1JUZrd2MGMSoohKhmi90RwlnTOJYTuvppJbjnj
0xelzsSuejElZhTyB3/3L6rhCEpWjhSXb4E5OvtwMREVJSsA3FNBem842T8kMvE6
n0q5Pay8+5dLVR3/fN7P9sQfMnVlIeNuLldhq9v09qwxYsjvjNlB1zViVXrRXaNG
z9EkHyH6UzveKr5syjsAm6a2WwtZ2IHoLp6tkwxehqUVhC6SsCpkzN56GT/W+G0=
=BALY
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-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

and it will prefer v6 (if enabled on your OS) and fall back to v4 if
v6 fails (it will take the configuration from your OS network stack).
ExtORPort auto is your best option.

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUTsl5AAoJEIN/pSyBJlsRBrsIAMse7fSQfSrRmcSHe9IPiWSi
UqWM95t+AeE8bqFwSpFhuwavvZ0Jt1Ll7WKclJKlq66z9qWs1hwVsB4mqSkIt9dm
1pHNlFNh5dakk1o413ZHRpTNQskWG9YGCv20vNTwlbHZlZ1InXr7e6Qy2/31o8Hc
P/EEGNBOjTMe6Y/XOR5LVndjZgb0vYkbL8Kk8ETKb8kQAnb3TOxE9A3VBQ4FVnMJ
uLJyz9Fx68G1HG5RtAp9k7nsFPJ1oyiq/Hr2OOO8Z5sPjiPdhxFLyo4V6UrZ7YMm
ysnSK2iEOqc3m7+MnfMK0OBVqSyCYgJE/JR1CjPuPCtzcLuVAxyVDVDGuHKDv/g=

Re: [tor-relays] Relay's clock settings off no matter what

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Austin,

The clock is very important to Tor, you need accurate clock all the time.

Do you run NTPDATE or NTPD service inside your VPS? The virutal
servers are sometimes problematic, depending on virtualization, when
coming to hwclock and dedicated time.

You need to open a ticket with your VPS provider and ask them what
virtualization technique they use and if there is a NTP daemon on the
hypervisor (physical host server) which sets the time inside the
guests (virtual machines). Make sure the time is correct on your
master host server and rely on that time instead of trying to run your
own NTP service. If they say the master server doesn't run this
service or set the time inside guests (i doubt it), you can then run
NTP inside your VPS as follows:

(NTP and NTPDATE are included in FreeBSD base system so you don't have
to install anything). Run these commands:

$ service ntpd stop
(or onestop if stop doesn't work, if it says ntpd is not running just
proceed with the following commands)

$ echo 'ntp_enable="YES"' >> /etc/rc.conf
$ echo 'ntpdate_enable="YES"' >> /etc/rc.conf
$ ntpdate 0.rhel.pool.ntp.org
$ service ntpd start

Your timezone does not matter. Tor calculates the time in UNIX time
format, so you can be in any time zone, GMT +1, UTC, EET, whatever -
Tor will work just fine if the UNIX time format is accurate. The
localtime via timezone is just a translation/calculation of UNIX
timestamp.

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

iQEcBAEBAgAGBQJUZdtcAAoJEIN/pSyBJlsRMzMH/3F1MeX9Z1y7z4G+zNNDENin
Yytg5YsXrWrwFCiC90j6rmKIY2rFvu5YTqpnoZ28bmC8+ZePuCXM1srK62YnUlvP
YVYJO1bCP0gl7ER1MhffS5pcpvXZ4Mb+uPdk1MlKcO+yD7xgP0EwbojBRJp/23Ct
jjkeLIg9fkDb+TRVd3KKFfvgHaItGYAoMc3Jn9yVUrH1vmKUDWe4XeSt37ejx4iE
6431+KUeFkEzPMJII2hBDJ3HFGx+VFAfBa+V2jQ+5DzIUwTc710jgmjSy7xhv/4Z
+V7JDniU6bDt0U1SIpKfZBGThrIiT7vsBg9EWQcQf1IHTvXe5boDkoveUdyIytk=
=Kczu
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Relay's clock settings off no matter what

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Or FreeBSD Jail system... anyway your provider has the interest to
have an accurate time on the host server... so it shouldn't be a
problem at all - it can be fixed in few seconds.. it's just a
misconfiguration.

No sane person will refuse to set the correct time on a host server...

On 11/14/2014 12:49 PM, eric gisse wrote:
> If your vps provider is openvz, you are shit out of luck because
> you can't set time.
> 
> On Fri, Nov 14, 2014 at 4:37 AM, s7r  wrote: Hello
> Austin,
> 
> The clock is very important to Tor, you need accurate clock all the
> time.
> 
> Do you run NTPDATE or NTPD service inside your VPS? The virutal 
> servers are sometimes problematic, depending on virtualization,
> when coming to hwclock and dedicated time.
> 
> You need to open a ticket with your VPS provider and ask them what 
> virtualization technique they use and if there is a NTP daemon on
> the hypervisor (physical host server) which sets the time inside
> the guests (virtual machines). Make sure the time is correct on
> your master host server and rely on that time instead of trying to
> run your own NTP service. If they say the master server doesn't run
> this service or set the time inside guests (i doubt it), you can
> then run NTP inside your VPS as follows:
> 
> (NTP and NTPDATE are included in FreeBSD base system so you don't
> have to install anything). Run these commands:
> 
> $ service ntpd stop (or onestop if stop doesn't work, if it says
> ntpd is not running just proceed with the following commands)
> 
> $ echo 'ntp_enable="YES"' >> /etc/rc.conf $ echo
> 'ntpdate_enable="YES"' >> /etc/rc.conf $ ntpdate
> 0.rhel.pool.ntp.org $ service ntpd start
> 
> Your timezone does not matter. Tor calculates the time in UNIX
> time format, so you can be in any time zone, GMT +1, UTC, EET,
> whatever - Tor will work just fine if the UNIX time format is
> accurate. The localtime via timezone is just a
> translation/calculation of UNIX timestamp.
> 
> On 11/14/2014 6:59 AM, Austin Bentley wrote:
>>>> Hello everyone,
>>>> 
>>>> I have an interesting problem. I am monitoring my relay using
>>>> arm. I am getting the following warnings:
>>>> 
>>>>> 05:56:12 [WARN] Received directory with skewed time
>>>>> (server
>>>> '154.35.32.5:80'): It seems that our clock is behind by 1
>>>> hours, 0 minutes, or that theirs is ahead. Tor requires an
>>>> accurate clock to work: please check your time, timezone, and
>>>> date settings.
>>>> 
>>>> Most of the messages tell me that my clock is an hour
>>>> behind. However, I also get these messages occasionally (but
>>>> not as often):
>>>>> 02:07:27 [WARN] Our clock is 52 minutes, 35 seconds behind
>>>>> the time
>>>> published in the consensus network status document
>>>> (2014-11-14 02:00:00 UTC).  Tor needs an accurate clock to
>>>> work correctly. Please check your time and date settings!
>>>> 
>>>> 
>>>> I am running a Tor exit relay on a FreeBSD VPS. Said VPS is
>>>> in Czech Republic. If I set the time to CET, it is 1 hour
>>>> behind true CET (GMT+1); therefore, I have it set to EET
>>>> (GMT+2.)  I have verified the time is correct in Czech
>>>> Republic. This problem is rather frustrating because it is
>>>> causing my server to throw away circuit data as old data.
>>>> 
>>>> Could someone shine some light on this?
>>>> 
>>>> Thanks, Austin
>>>> 
>>>> 
>>>> ___ tor-relays
>>>> mailing list tor-relays@lists.torproject.org 
>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>>
>>
>>>> 
___
>> tor-relays mailing list tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUZeM8AAoJEIN/pSyBJlsRGeEH/2ElP4+Z7uD2PQkYk25tq7ji
VVTUwxa5qweD4/YBWwoohhMmii+yY4ZoLnmoevNh2Y3PxTwC49N5nyQH7CQL59OU
gIL8GCfmoJD6mjv+cCENn+g/iPUpb5eIhuKnLnh0dm49pj5t0Wb8H3R6HUR+BGnA
Me3SOwfWT3XR6Ktd93Ev/yY03vRRFFhSQShGCeSwKIIT6CvKWgTSXCi4SZsslY5B
mvRJMx99dYbEFuL32hNkPtcx5mr7JkUQamWJzuzPEY4HDFaYIW0zU0SBcFBbXVjT
MClytBVcS1YznSMC/l9eusnijDO4LCM7We6EsjRmWWgPKOg+SsoMbCtZzmh+Y0k=
=piNO
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] wild swings in Advertised Bandwidth

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That does not necessarily mean your bridge works with max. 8 kB/s.
Maybe the bridge is not used much currently (most probably if it's new).

The minium BandwidthRate of 20kB/s you read is correct, I think it
should be at least 200kB/s minimum. Back to our topic, that refers
strictly if you cap the bandwidth to a certain value. If you did not
limit the bandwidth of your bridge via torrc setting or other upstream
firewall and if your internet line is capable of handling above that,
it is not necessarily a problem that your bridge shows in globe with
that value.

On 11/22/2014 11:10 PM, jchase wrote:
> Hi, I'm running a low-volume bridge on a raspberry pi. 
> Globe.torproject says that my fingerprint is 
> 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . I'm keeping an eye on 
> myself and traffic via globe.torproject and my advertised
> bandwidth makes wild swings: one day its 56 kB/s and the next day
> it's 8 kB/s. When I read that "The minimum BandwidthRate setting is
> 20 kilobytes per second", I am confronted with the fact that 8 is 
> less than 20 and it doesn't seem worth it keeping my bridge up and 
> working. Why would a bridge make such swings in advertised 
> bandwidth? And is there any good reason to keep the bridge up and 
> working if it sinks to 8 kB/s? Thanks, J Chase 
> ___ tor-relays mailing 
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUcScbAAoJEIN/pSyBJlsRtu4IAIW4lFh1+Cf8fCcay96mr2O+
lPzKP19OoUBxz9BLqZ+bQNqAQKPjfK+u6qTqTDP1jYsjrGkY8XbWXBmQWi/RDwp2
bUIOPHuYyTRNDHTiVlMsOlZ2rDc+0ufmOi+lWsYqkOZp3D07BfZsziBoMhYQ6Pyw
NFlrux6yw72Kk9/XLsOLniaHJrbxuZGeMdiQxeExTRt/coEqvMOrk5Yebi+19rDb
/21XZ0TPmagGgnWzAy+mkIX259BWk5I7hWws62gKeqSi4UknvRXdqHGRZ++fxdTB
d5Kn1t51q0h9NewTkcVjE8bFHcVu5A/Tz3J/j62u//KObNCw6C8HSUOtuGwfczQ=
=VDJy
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I also share the thought that more US exit power is welcomed in the
Tor network.

However, the fact that there is more exit power in the EU compared to
the US has nothing to do with the legal implications of running a Tor
exit, it's as simple as bandwidth is a lot cheaper in the EU than in
the US. And for small relays run at home, US, as opposite to the EU,
has asymmetric internet lines, with download speed considerably higher
than upload speed - they think for a residential line you should only
consume content, not create. Since a Tor relay needs to be able to
receive as much as it sends, this is a bottleneck.

Depending on your budget, Voxility has a datacenter in the US.
Unfortunately they provide only enterprise class servers with prices
directly proportional to the class. Maybe we can manage to pool $ in
order to create a bigger node with this provider if we find enough people.

On 11/23/2014 2:10 AM, Steve Snyder wrote:
> On 11/21/2014 07:08 PM, SiNA Rabbani wrote:
>> Dear Relay Operators,
>> 
>> I noticed there are very few US based exit nodes in the network.
>> And more and more people are jumping on the same set of AS
>> numbers in Europe.
> [snip]
>> If anyone is interested in running fast Tor Exit nodes at Rethem 
>> Hosting. Feel free to contact me directly, so I can make proper
>> referral/introductions. Rethem Hosting is also able to provide
>> hosting In IceLand, but you get the most bang for your buck in
>> the US datacenter.
> 
> I am interested in running a fast exit node in the US.
> 
> That said, there is precious little information on Rethem's web
> site (http://www.rethemhosting.net/) to indicate that they would be
> open to that. They don't say anything about what plans might be
> offered, where the server would be located, or what forms of
> payment are accepted.
> 
> Their web site is non-SSL and the only method of contact is via
> the notoriously insecure e-mail.  I like graphics of binary numbers
> and circuit board traces as much as the next guy, but their site
> doesn't give much information to the potential customer.
> 
> And with your servers running for less than 3 days apiece, I think
> it is too early to say if Rethem is a good venue for hosting a Tor
> node.
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUcSiMAAoJEIN/pSyBJlsRIikH/R0ikZ8flX2FyuezmgwcGAvM
NPxQ4tjzb2nHLH64woKch4dr3hAfJDU62lZXcOkBiRq8PcotojZYuPkIz6SLzn4d
6WU0oVqyvBd1PhtaCQIDh+3kxs9LOOM+FDkhnbvgi1ma9MbvrYfc1CpvyE1coTUc
ulWN7Cw9N7A/aYDnOGAyOM45oXgANWI2Ha48g7T+oZuniYeTnC1qQB7FnWjx0ud6
PSTD8zaZTB/vVlxfqVS/dS2H3kbXYuKHZe3Yoz5WCzf8GDR5WilrowivfNdQoezQ
ZxvBS7F/lc5cDQ5fZIJxi0fuH6Hq20AWWvTwOOLzcdqUPzoSA6PF3z+Ir87KcN8=
=1e8/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Just checked them now, that is great if they will allow you to run Tor
exit nodes on such cheap virtual machines. 5$ for 1000GB is a good
deal for US traffic, and bitcoin accepted is an important pro. But I
am concerned if they will sustain Tor exits on the long term. If the
Tor relay will consume more bandwidth they might start shouting about
it since more virtual machines share a network port, and they will
want to maximize how many VMs they can assign to a port in order to
maximize profit. Not to mention if the relay will be under DDoS attack.

I saw many cheap cloud providers which claimed to support Tor, yet
after little time just when the relay was becoming popular and known
in the consensus, service terminated. Hope VULTR will not follow this way.


On 11/23/2014 2:56 AM, Seth wrote:
> On Sat, 22 Nov 2014 16:35:18 -0800, I 
> wrote:
> 
>> So USA can be fast and cheap but beware when they agree Tor is 
>> acceptable because there are poor trade practices laws to get
>> refunds and rights.
> 
> FWIW I spun up a Tor exit node on VULTR. I pro-actively informed
> them I was doing so by creating a support ticket with this text:
> 
> "Just giving you guys a heads up that I've setup a new Tor exit
> node.
> 
> It's using the ReducedExitPolicy detailed here:
> 
> https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy
>
>  The reduced exit policy has been successful in eliminating the
> vast majority of DMCA complains according to this Tor blog post:
> 
> https://blog.torproject.org/running-exit-node
> 
> If there are any complaints about traffic from this node, please
> alert me immediately so I can deal with them. I have a dedicated
> email setup for this purpose at t...@sysfu.com.
> 
> Regards, Seth"
> 
> The response was a simple "Thank you for the update."...so they
> seem pretty cool about it.
> 
> If you look at https://torstatus.rueckgr.at/ you'll see a half
> dozen other nodes running on VULTR.
> 
> The starter $5/mo size gets you 1000GB of bandwidth per month,
> can't beat that with a stick.
> 
> Another thing I like about VULTR is that you can install your own
> custom OS via an ISO or iPXE script. Also none of that fixed kernel
> nonsense I dealt with at Digital Ocean. And they accept Bitcoin.
> 
> That fact that thousands of average joe sysadmins can now spin up
> a powerful Tor relay or exit node, on the operating system of
> their choice, for $5/mo payable in Bitcoin...I think that's a big
> deal.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUcTLxAAoJEIN/pSyBJlsRiZoH/3mCS4OPT/Si47+fmyI2IkdW
ggEhv9S5csBCZRCl/374Gu5Kv4Ru/2W3mBAZvflxTAN9Mef0msiVHl8pC9NlW3Y6
E7f4DEvb8NTiuoCEpYPUe6GJfmTrP+dZDoWarUPGiBzYxCXw2mSwdmnC1r7ei3X5
X6bALW88w9O8eG3r29CuCqx7OAm4o4SfqI7ConkkLtzQ4XDQ+oOiWVld3M/RrKMm
oJAu+ALecrUtopcIlyz5feql0467pddAIl579YYj62BRpUpAWM5CAyOvmXdNHNJD
2SaxzUS/F5BFPdmCOU5QzOIzRDFEnLud9LTFn8KeyR053ARDekHLoTC3nMSM4dA=
=OYdd
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That is, because in almost all cases, providers allow unmetered
incoming traffic to your server but keep count and accounting on
outgoing traffic from your server, which is why the torrc setting acts
the way it does.


On 11/23/2014 7:58 PM, Seth wrote:
> On Sat, 22 Nov 2014 22:42:15 -0800, Mirimir 
> wrote:
> 
>> How much throughput do you get with your VPS, 1000 GB/mo or 2000
>> GB/mo?
> 
> The 1000 GB/mo applies to whichever value is greater, input or
> output. So far the Tor node is pushing less than 1.5GB per day.
> Takes a while for traffic to ramp up apparently.
> 
>> As I read comments in torrc, AccountingMax "applies separately to
>> sent and received bytes, not to their sum", and so "setting '4
>> GB' may allow up to 8 GB total before hibernating".
> 
> Yes, others have raised this issue as well and I will look into
> it. ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUciHlAAoJEIN/pSyBJlsRrnEIAIQefR/1wVrFIPCj2C6ecwyB
6rb49UG7+aFIMypDBO39ivmjSzci5nlnnQRmQHbySnvNAtsXAJ0FXyLNY8uATdd2
EqNwn6oj12sCQRlfhJ8nv9VnBSJ5ltogUCrVNXDJsj9D1sCPsry7/PaMTh1IVqtX
WiSUuYbu2/S+hXPXteR4eSP7MaQJY6ZC8rKZ9ZhS/QRfA1yShzJ2JwzCclXpFtFo
AolA+7oYycBWMeITstghUdjJh1kOQlYQYTrU787nyyPhuY2lzBze3W6yG8V0/Y7H
7CwEIDUSw+n0xgrl1Ck4ZofELLQMFPZrl95BD7o+DVHJivaQgc8hPD2NMf6TYZc=
=0dVx
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

If the only limit is consumed monthly traffic, and not the bandwidth
your relays consumes daily (e.g. you use your VPS only for Tor) it is
not recommended  to use RelayBandwidthRate. Better use AccountingMax,
and your relay will work at full speed until it hits the accounting
limit, then go into hibernation. It will wake up at a random time in
the next accounting period.

As the Tor manual says, it's better to have a fast relay available
some of the time instead of having a slow relay available all the time.

Just use AccountingMax and do not forget there are other factors as
well which count in the speed of a relay, such as CPU, RAM, network -
a VPS (share resources machine) is unlikely to achieve maximum
resources usage. Give it a try with AccountingMax (so you are sure it
won't bypass the limit set by your provider and you don't have to pay
extra) and see what what speed it reaches.

On 11/24/2014 5:24 AM, Mirimir wrote:
> On 11/23/2014 11:05 AM, s7r wrote:
>> That is, because in almost all cases, providers allow unmetered 
>> incoming traffic to your server but keep count and accounting on 
>> outgoing traffic from your server, which is why the torrc setting
>> acts the way it does.
> 
> That would be great! I'll confirm with the provider.
> 
> I'm also wondering what to set for RelayBandwidthRate for an exit.
> I see some old threads on this list, and a question at Tor.SE, but
> find nothing that's clear and persuasive.
> 
> Assuming that the 1000 GB/mo limit applies to just outgoing
> traffic, throughput would need to average ca. 0.4 MB/sec. However,
> median advertised exit bandwidth from Tor Metrics is ca. 1 MB/sec,
> so it seems unlikely that an exit advertising 0.4 MB/sec would be
> used very heavily. And so actual usage would be far less than 0.4
> MB/sec.
> 
> Conversely, setting RelayBandwidthRate to 3 MB/sec would ultimately
> lead to heavy use. But with full utilization at 250 GB per day, the
> relay would hibernate after just four days. There must be some
> intermediate value that would bring average usage to 0.4 MB/sec.
> 
> What is the optimal RelayBandwidthRate for a 1000 GB/mo VPS? I'm 
> guessing that it's about 1 MB/sec.
> 
>> On 11/23/2014 7:58 PM, Seth wrote:
>>> On Sat, 22 Nov 2014 22:42:15 -0800, Mirimir
>>>  wrote:
>> 
>>>> How much throughput do you get with your VPS, 1000 GB/mo or
>>>> 2000 GB/mo?
>> 
>>> The 1000 GB/mo applies to whichever value is greater, input or 
>>> output. So far the Tor node is pushing less than 1.5GB per
>>> day. Takes a while for traffic to ramp up apparently.
>> 
>>>> As I read comments in torrc, AccountingMax "applies
>>>> separately to sent and received bytes, not to their sum", and
>>>> so "setting '4 GB' may allow up to 8 GB total before
>>>> hibernating".
>> 
>>> Yes, others have raised this issue as well and I will look
>>> into it. ___
>>> tor-relays mailing list tor-relays@lists.torproject.org 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>> 
___
>> tor-relays mailing list tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUcwMtAAoJEIN/pSyBJlsR2woH/3+almWowdzRimgGfkqXcOLi
7DllnhPwKI3fMpONTkR5MxxjpAXAYlBDh/pVOqaAggSP7RfYrxAKNunb3NK7KVXQ
3Q19KodQLMlD25Bdw45HT5o+aCVT3C1Gte1sUNP4HmMTa4rMONUsJ5lhESc+l7Nt
BzgU36m2cClePVL1Xzup/iMtDEukbvdj45GmPwdVfutfZix+12aOcu5eqL0PKssQ
TuY8XQU7eKP1p9ErykDDa9jjQVLAQ1cRLJNg+xBjOuiwM7z5K5ukegDNemEf6Tj+
WCjEMURqqzhAtIpcTR2j6qrSQ8qpl2L9uukpdApSW0Mx/EwlQobDi8z8I6JEA28=
=ExD/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 11/24/2014 7:32 PM, Mirimir wrote:
> On 11/24/2014 03:06 AM, s7r wrote:
>> If the only limit is consumed monthly traffic, and not the
>> bandwidth your relays consumes daily (e.g. you use your VPS only
>> for Tor) it is not recommended  to use RelayBandwidthRate. Better
>> use AccountingMax, and your relay will work at full speed until
>> it hits the accounting limit, then go into hibernation. It will
>> wake up at a random time in the next accounting period.
>> 
>> As the Tor manual says, it's better to have a fast relay
>> available some of the time instead of having a slow relay
>> available all the time.
>> 
>> Just use AccountingMax and do not forget there are other factors
>> as well which count in the speed of a relay, such as CPU, RAM,
>> network - a VPS (share resources machine) is unlikely to achieve
>> maximum resources usage. Give it a try with AccountingMax (so you
>> are sure it won't bypass the limit set by your provider and you
>> don't have to pay extra) and see what what speed it reaches.
> 
> OK, then. But in that case, and given that the provider states the 
> throughput limit as "1000 GB per month", I would want to use
> monthly accounting, in order to be in synch with them:
> 
> AccountingStart month 1 00:00 AccountingMax 900 GBytes
> 
> Yes? That way, with no RelayBandwidthRate limit, relay utilization
> will presumably increase for two or three months, until
> AccountingMax is exceeded, and the relay hibernates. Subsequently,
> it will tend toward an equilibrium, with some mix of bandwidth and
> activity/month that depends on the configuration of the directory
> authorities.
> 
Sounds about right. If you have 1000GB from your provider, why set it
to 900? You can put 995 GBytes without any problems, since 5GB per
month is more than enough for management / administration and time to
time regular operating system updates.

> If I used daily accounting, the relay might end up hibernating
> every day. That would be worse, right? Also, I'm imagining that
> this might lead to lower average throughput, because the relay
> would show up as unstable? Is that correct?
> 
> More generally, should AccountingStart (day vs week vs month) match
> the accounting period used by the service provider?
> 
It does not matter really, as for traffic consumption will have the
same effect. If you have 1000GB per month you can either set
accounting period of 995GBytes per month or accounting period of
248GBytes per week - it will still prevent your relay to consume more
than 1000GBytes per month... As a personal thought, I think it's much
better to have a monthly accounting period as your provider accounts
your traffic, this way you relay will go into hibernation one time per
month rather than 4 times (after the end of each accounting period Tor
goes into hibernation and waits for a random time until it 'wakes up'
again).

> Thanks.
> 
>> On 11/24/2014 5:24 AM, Mirimir wrote:
>>> On 11/23/2014 11:05 AM, s7r wrote:
>>>> That is, because in almost all cases, providers allow
>>>> unmetered incoming traffic to your server but keep count and
>>>> accounting on outgoing traffic from your server, which is why
>>>> the torrc setting acts the way it does.
>> 
>>> That would be great! I'll confirm with the provider.
>> 
>>> I'm also wondering what to set for RelayBandwidthRate for an
>>> exit. I see some old threads on this list, and a question at
>>> Tor.SE, but find nothing that's clear and persuasive.
>> 
>>> Assuming that the 1000 GB/mo limit applies to just outgoing 
>>> traffic, throughput would need to average ca. 0.4 MB/sec.
>>> However, median advertised exit bandwidth from Tor Metrics is
>>> ca. 1 MB/sec, so it seems unlikely that an exit advertising 0.4
>>> MB/sec would be used very heavily. And so actual usage would be
>>> far less than 0.4 MB/sec.
>> 
>>> Conversely, setting RelayBandwidthRate to 3 MB/sec would
>>> ultimately lead to heavy use. But with full utilization at 250
>>> GB per day, the relay would hibernate after just four days.
>>> There must be some intermediate value that would bring average
>>> usage to 0.4 MB/sec.
>> 
>>> What is the optimal RelayBandwidthRate for a 1000 GB/mo VPS?
>>> I'm guessing that it's about 1 MB/sec.
>> 
>>>> On 11/23/2014 7:58 PM, Seth wrote:
>>>>> On Sat, 22 Nov 2014 22:42:15 -0800, Mirimir 
>>>>>  wrote:
>>>> 
>>>>>> How much t

Re: [tor-relays] Help - My relay consensus has been stripped back to 20

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This was reported yesterday 01.01.2015 in IRC too, for this relay:

3D7E274A87D9A89AF064C13D1EE4CA1F184F2600

The same it was pushing good amounts of traffic and the consensus
weight dropped to 20 with no modifications made to the Tor config file
or anything. You are the 3rd person who reports this, seams like worth
investigating further.

I can see both of them are exits, but doubt this has anything to do
with it.

Could it be a measurement problem from the bandwidth authorities? Why
would it happen only to very few relays in this case?

On 1/3/2015 1:28 AM, bigbud...@safe-mail.net wrote:
> On the 29th December one of our relays, bigbud
> (6911888F83565892FE23F1B03EB501D80E1E8780) which had a consensus of
> 630+ and had been running for nearly 18 months (100 days uptime
> running 2.5.8) suddenly started receiving much less traffic.
> 
> I have seen a gradual reduction in traffic over the course of the
> last year but on the 29th the drop off was very significant and I
> saw in Atlas that the consensus is dropped to 20. When I look at
> the consensus files it shows that bigbud has a consensus of 20 and
> that Unmeasured was set to 1.
> 
> Any ideas please? I upgraded Tor to 2.5.10 after I noticed the
> consensus drop. Is this something to do with the Lizard new relay
> flood or something or is there an actual problem with the relay?
> 
> On a related note the relay lost guard status too a few months ago
> and I couldn't see why that would be. 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUpyxIAAoJEIN/pSyBJlsRB6MH+wWzDQPlhf+H4KWkoX9J6jhc
GQbL3+YmmZP1Eh941hnE6zaHpk5OUZiDarovBxSdL0FPEyHWlvLJIsFR6VXmfq2s
RB4hId21mKR5HQLNy/at6KP4Xs7dv3Qyid/KCZK3qH82HtJ9Yt9lA6yNTT8uLWmV
zIr1SKAMltBiIVrBWZaNGtqy5NVrGiF3yx2VYuHT7ZORL1l8BVjvG2I9d+/n2n7r
3RdEUKXSeFp/UnLlN5M9ZhHEdQLkioKfUisnkHdPKu7LTvWlVIONCm0t5lHo62xh
MUmbBP+lrWMfmQE8sJaTgmlJKq26Gb+JtG7uXV8k+XOfDokQygnFclJwZtUnKrQ=
=9kZo
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Mozilla-Middles losing guard

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The speed matters. Some time ago, Guard flag parameters were changed
little bit, so now the Guard flag is assigned to 25% of the fastest
relays in the network (of course which are also stable and have good
uptime and have been around in the network for a while). This means
that if the speed drops down, the Guard flag could go away with it. By
the reference speed I can see below of 1.51 MB/s it's quite near/under
the limit.

If you had for example 5MB/s constant, you would not lose the Guard
flag not even some of the times.

On 2/17/2015 9:22 PM, lpwzi9...@use.startmail.com wrote:
> probably needless concerns, right. i see, thanks for clearing this
> out for me!
> 
> 
> On Tue, February 17, 2015 20:11, Kurt Besig 
> wrote:
> 
> On 2/17/2015 10:59 AM, lpwzi9...@use.startmail.com wrote:
 at this very moment all of them got the flag, right. But
 theyre loosing it at seemingly random order. I kept an eye on
 Atlas for some time, at 18:00 (UTC+1) Mozilla13 was at 1.51
 MB/s without Guardflag.
 
 
 On Tue, February 17, 2015 19:50, Nusenu
  wrote:
 
>>> i am wondering about losing of guard state of the
>>> Mozilla Middle Relays.
 
 what makes you think they [1] lost guard flag?
 
 [1] https://atlas.torproject.org/#search/mozilla 
 https://consensus-health.torproject.org/consensus-health.html

 
> My relay gains/loses guard occasionally, what's the concern 
> regarding?>> ___
> 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

 
> 
>> 
>> --- This email has been checked for viruses by Avast antivirus
>> software. 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
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU45/zAAoJEIN/pSyBJlsRfDAH/166+H8bai2yKRe6lcDmjrxd
2Ymd1VH5GlntTywhDvYvnBK7y7iVhN7A/OxOSEjh2mzJ2lLY7FScpCuNJLAJnOxF
gDVLA7Zd26C2tnNKr8Gc0eCR+8ZcfirXYCkxvLQfzZBDB45UHmsBF5usThS10qg2
k8LkQimtxEJZ84FjfYigEpBWgG9QwsAtqTD4sSJA1T5Nfp8yahmT7S4xxfhTUxXN
Sh2dvLsQVgnFtevoNcXHPNAHb+UqdEbu/V8SEdq7hvEfs2deH46C5+l6493gFt8l
khAkF+WRjSIDTxUK5sF2FvWWwkopELMlqRfkSBm7VUeebApXzuDxkzvPoissKLM=
=QVek
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] eventdns: Address mismatch on received DNS packet.

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

We have a ticket open for this:

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

I think this is a libevent error.

It happened to me on FreeBSD 10 with Bind910, FreeBSD 10 with Unbound,
Debian Wheezy with Unbound, Debian Wheezy with Bind, Debian Wheezy
with ISP-assigned-resolvers (pretty much everything). Happened
initially on Tor 0.2.4.21, followed to all upgrades of 0.2.4.x series
and also happens currently on 0.2.5.10, but on the latest version the
error appears not to occur as often as it used to in 0.2.4.x series.

On 2/21/2015 4:06 AM, Sebastian Urbach wrote:
> On February 21, 2015 2:09:48 AM Libertas 
> wrote:
> 
> Hi,
> 
>> On 02/20/2015 06:31 PM, Jacob Corbin wrote:
>>> I'm sorry for the late reply on this but I've been having
>>> problems
>> with my
>>> Internet connection and am trying to catch up on emails. I've
>>> never
>> received
>>> that message but months ago I started getting messages in the
>>> posts you referenced like:
>>> 
>>> Jan 05 12:36:58.138 [warn] eventdns: All nameservers have
>>> failed Jan 05 12:36:58.354 [notice] eventdns: Nameserver
>>> 192.0.2.7 is back up
>> 
>> I get this constantly on my exit node running OpenBSD with a
>> local Unbound caching DNS server. I think libevent (this is part
>> of libevent, right?) is just a little too trigger-happy with
>> reporting DNS requests as failed, as my failures never last more
>> than a second. I was considering opening a ticket about this.
> 
> Unbound@Debian here, the same effect. Thanks in advance if you do
> open a ticket.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU5+91AAoJEIN/pSyBJlsRmqgIAMdCnbLul375fYbFSkVDY6ey
Zy6rQy8cAhXcTQbp3C+avUL3gJUaWFmNPL2jFfg+Q9cI83gT6x3VmqgcDazXL1zb
QMlJKlkg5WF7b6w/0ZTMw8y0lMmH6sufzy6FArq5ms5nn7RFLZcce6RhepD/apow
scmCBiGuI1OFJA8VqhpOuWiLD0E3HuCfHUsqn0VRcc8db8BNtvaHSfflhsTqGRo3
xuwwNcnz9xQ4rREFIJiPWSw9GMIt+gZrxUkJtpXbGXy1OWkvR+zcmkzND5V6SncE
VylmAXw8QZga6b4I/EephgfiTDhKq7hQtqdBzoDWdPo5qfY9uwuGSAmTOYjm9g0=
=QW3F
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] 7 relays gone because of spammers

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Sorry to hear this.
I want to setup a big node at Voxility, which is a good provider to
host Tor exits, maybe more of us can pool together financial resources
and make a big cluster. I have some offers from them if interested.

On 2/25/2015 8:35 PM, Speak Freely wrote:
> Hello fellow relay runners,
> 
> This morning OVH decided to kill 7 of my relays due to spamming,
> and block all access to all services. I ran the Reduced Exit policy
> for all of my relays.
> 
> Due to heightened concerns about this affecting other unrelated
> services I have with OVH, I had to shut down the other 3 relays.
> They may eventually re-appear as middle-relays.
> 
> This has cost me hundreds of dollars, as I foolishly decided to
> prepay on an annual basis. None of the servers were older than 2
> months. Some were only a few weeks old.
> 
> The Abuse department's rationale is as follows: "Your account was
> suspended because 100% of your IPs are blacklisted on multiples
> lists for Spam and other malicious activities. This case is closed
> and this decision is final."
> 
> --
>
> 
When I first contacted OVH regarding running Tor relays, this was the
> response that I received from them, which does not mesh with what
> just happened.
> 
> "Good morning Matt,
> 
> I'm very glad to here from you. It is very flattering to hear that
> you are very satisfied by our service at OVH!
> 
> We do take our network speed and hardware performance very
> seriously here. We are proud of our infrastructure that we have
> built over the years.
> 
> I do understand your concerns about setting up a Tor relay on one
> of our VPS. In a simple form, yes you can.
> 
> We do let our customers use our VPS as Tor relays. We have no
> problem in letting you this.
> 
> However, your are allowed to use Tor but it will be at your own
> risk.
> 
> Rest assure that, in case of an abuse, we will not terminate your 
> account without notice. In fact we may not even terminate your VPS.
> You will receive a warning from our Abuse department giving you a
> choice to resolve the abuse case.
> 
> Like you said, we are in a world where free speech is constantly
> under attack and we are committed to help as much as possible to
> protect this fundamental right that we all have. We will absolutely
> not in any case share our customers information or data to
> authorities without a warrant.
> 
> For any other questions or concerns, feel free to contact us at
> any time. We are available 24/7.
> 
> Good luck with that privacy project of yours and keep on supporting
> the cause of free speech!
> 
> Thank you for contacting OVH and have a wonderful day!
> 
> Colin K. Customer Advocate"
> 
> --
>
>  Not that it matters anymore, but each relay was dedicated to one
> of the victims of the Charlie Hebdo attack. 
> https://atlas.torproject.org/#search/4charlie
> 
> --
>
>  Eventually I will get back at this... But for now, my money is
> gone, and all my hard work is lost.
> 
> --
>
>  So... I know I'm new. And it's possible this has happened (many
> times) before, but... You've been warned.
> 
> 
> Speak Freely ___ 
> tor-relays mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU7hu9AAoJEIN/pSyBJlsRD+UH/j78yJIPzCiKjeyDrJtQ2YIp
7W2aU/ESWPm8rQQQo1r8d6YYbaDSFJOyCVaaIHlNq1Iom5bn59DX4IigBhQzcINs
N/ys6ysPy/RKU2E0YJssG9DIT8KrcKTDJ47mCe6WE5l7BqDCYUwp/Z03zuyxYUTy
7zBZH0KsqtQMepnTvPpSoQmG6CAJGHUuTng1+V1Fcd2WV8gpgu30P1yyBR9HigSa
m0Nbo6rwDJ/DNYgFPgD4W2KC6COrZop6unSFHw5Xz6Du64ClwZidEfgYPRcm3SU6
3+rEEKvc3Zln4LirYALYaOpxPv/LyR1UAu1sqAJb0NBR4Dd2/wvyAbYxBFMhV/c=
=fo3M
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 3/9/2015 1:17 PM, Sebastian Urbach wrote:
> On March 9, 2015 7:17:20 AM oneoft...@riseup.net wrote:
> 
> Hi John,
> 
>> Can someone point me to an overview of the different legal
>> situations for running tor relays in European countries? I'm
>> especially interested how the situation differs per country.
> 
> I don't think that we have something like that anywhere, sorry.
> 
> The only offered list is this one, afaik:
> 
> https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs
> 
> From what i hear a few countries are starting to crack down on Tor
> or Encryption more generally and some are planning to do so in the
> near future. Hard to keep up with the changing laws.
> 
What is the source for this?

In the European Union Tor running a Tor exit relay  _is legal_, and
the rights for privacy and anonymity are guaranteed by European Court.
I can't find the source now to give exact data, but about one year ago
declared the laws from multiple EU member countries enforcing to
retain user navigation data or metadata of communications (who calls
who and when, internet browsing history) as incompatible with the
universal human rights which guarantee the right to privacy and
private life.

Majority of Tor exit power in is Europe. We have no reports of relay
operators being prosecuted or punished by any means for running Tor
exit relays.

Which countries started to "crack down on Tor" and which ones are
planning to do so in the near future?

This is a speculation and it's not backed up by anything real. Can you
define "crack down on Tor"? People and organizations are researching
and trying to find a flaw in Tor since Tor was born - there is a good
side here, being widely studied and getting a lot of attention makes
it the best anonymity network available. All the bugs and flaws
discovered until now were fixed, and this only made Tor stronger, so I
want to thank this way for everyone who is doing research and tries to
find flaws in Tor, assuming they do this in a transparent and fair way
and share the results with everyone.

I only know of one case, outside the European Union, in Russia to be
exact, where they've put a bounty of $100.000 or $150.000 9can't
remember the exact amount) for whoever manages to crack Tor. This is
under no circumstances reason to worry. Still there are many exit
relays in Russia, so not even there Tor is illegal.

P.S. Not everything is illegal, except what is authorized and
regulated by law. It's the other way around, anything is legal and
permitted unless clearly prohibited by law. At least theoretically
speaking :-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU/aqTAAoJEIN/pSyBJlsRmiQH/0sxOlVVkN/7RvAIBFmAJbIQ
B0yAHXgKCc0cut/KYUmJXzeoE+/M+KPw6g+dpGytNVGwbJ5TNVg6en5IXSJqrAhb
yIywEOYawyP1HROUrSm/qygQGeMGsIMMGyOAoWKTYsLPq45ahmwsUuHLGMYf+BDF
ikMms9CUSg+IUpXzTIZJmWgZtoTxN6Tb0ZIbV3vba/zu+jsMJkIaImbJhSr/asIt
h1UxRv6S7cwdhQAoLX/fBiCUA+xW7xqgMauyrWBgxJKI7e8WFS5EbFN0mZVBpVQe
Q6/KLAyC6/JAwC4OqsIuNjS1PH9V65dJWk6Zya23UZt4gi2aJ26EHEnDQqo6lhA=
=1Vcd
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay behind reverse proxy

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If you are using the free nginx, community project, that will only
allow you to deploy a http(s) proxy. Only the commercial (paid) nginx
allows you to deploy a TCP proxy (handles all TCP traffic), which is
what you need for a Tor relay.

If you want to use a proxy, you should look into a TCP proxy which
will handle any type of TCP traffic, regardless of protocol. (Tor uses
http for directory requests [DirPort] but not for ORPort). Make sure
your relay can reach the other relays in the consensus and it doesn't
have any kind of restrictions or limitations such as being able only
to talk on certain ports or reach a limited number of IP addresses,
etc. Your relay needs to be able to connect to all the other relays,
so the clients can build circuits through it.

A free open source solution might be haproxy ( http://www.haproxy.org/ )
Maybe this will help you with your setup.

Make sure you properly bind DirPort and ORPort to the correct
interface and use NoAdvertise and NoListen accordingly. Provide more
information about your setup and the relevant configs, if you are not
able to do it.

Read the manual: https://www.torproject.org/docs/tor-manual.html.en

Thanks for running a relay!

On 3/9/2015 1:46 PM, efkin wrote:
> hello tor ^.^
> 
> i'm trying to setup a tor relay behind a nginx reverse proxy... i
> would like to know if it's correctly setup.
> 
> i have this warn in the logs:
> 
> [warn] Received http status code 404 ("Not found") from server 
> '85.14.240.188:443' while fetching 
> "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
> 
> 
> but then in the same log little bit after:
> 
> [notice] Tor has successfully opened a circuit. Looks like client 
> functionality is working.
> 
> last message is : Now checking whether ORPort X.X.X.X:9001 is
> reachable... (this may take up to 20 minutes -- look for log
> messages indicating success)
> 
> 
> thx for support.
> 
> it's a great community!
> 
> efkin ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU/a+eAAoJEIN/pSyBJlsREQ0IANp7mWz4jCQnHLETk7tE4s27
Y/PJvmAIvROrf6kMTw5slremUxOzCbIuz25JMem96GvPiMVm2VFNYRsdwKCfPUBt
PP4jMAtu0R4DQxonyDxwLX/ZWGVZW1cJHDkCoH5KbZpEJqaGFBVEuOrahY+j8O2z
YHta5dSLl3Uium8EbCf9PuHOo4IfXyi6paR7tvQTKJCsaBeS/+WrTspiJzo1VeMV
goGV9xTSpAiBrEPcU9ggizNFIs7S4jdBdfbs06VTCIuV1PCgP0kltpBxBJ+1jr99
g9mIbvCf9A7z7gSmbVHAPxeE2LleWXxzM2JSxmZIxys5s0XfD09F3pM+67Uj2HI=
=qgn/
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Markus,

Your arguments are fair and correct and mostly I tend to agree.

But, the port scans, malware distribution and spamming existed before
Tor, exist in parallel with Tor and will continue to exist even if Tor
will disappear.

I admin a lot of servers opened to the public internet and I have
noticed, for q quick example, that if you don't change the default SSH
port (22) and implement ssh-key based authentication, the server will
be flooded with failed login attempts (password brute forcing). The
SSH logs also save the remote IP address - you will be amazed that
almost all of those IP addresses do not belong to Tor exit relays. The
percent of Tor-IP addresses in these logs is very small and
insignificant, compared to other non-Tor IP addresses.

A basic web server running Apache2, its access log will have tens of
thousands of requests for /phpmyadmin or /wp-admin or other paths,
from scripts which try to brute force phpmyadmin or other CMS web apps
(such as wordpress, joomla). Again, the logs also include the remote
IP address - we see here IP addresses of Tor exit relays in a very
small percent compared to other non-Tor IP addresses.

When port scanning or brute forcing, doing it through Tor has many
disadvantages, such as being very slow (can't handle too many
concurrent requests), exit relays IP addresses being blacklisted and
so on.

It's much more practical to just use a compromised computer with good
bandwidth which can handle many requests per second and has a
not-blacklisted IP address. There are hundreds of thousands of such
computers on the internet. Secondly, there are infected computers
which can be used as proxies, all these represent a better solution
than Tor for port scanning and brute forcing.

I totally agree on some good and sane anti-abuse measures, but without
undermining the freedom and anonymity of the users.

Port scanning is just 'the noise of the internet' - in almost all
cases it's irrelevant if someone performs a port scan on a server, as
long as the server is properly secured. If your SSH port is 22,
password authentication enabled, and your root password is 12345 .
ta-ta.


On 3/9/2015 4:40 PM, Markus Hitter wrote:
> Am 09.03.2015 um 15:13 schrieb s7r:
>> This is a speculation and it's not backed up by anything real.
>> Can you define "crack down on Tor"? People and organizations are
>> researching and trying to find a flaw in Tor since Tor was born -
>> there is a good side here, being widely studied and getting a lot
>> of attention makes it the best anonymity network available.
> 
> 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.
> 
> To what I understand, Tor's goal is to make flow of information
> free and to allow this freedom, anonymous. This doesn't include
> abuse, so implementing at least basic anti-abuse measures would
> make this network much more general website friendly and
> accordingly get it closer to its goals.
> 
> 
> Markus
> 
> 
> 
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU/bYGAAoJEIN/pSyBJlsRf9IH/2HQmj4vn6j8JVaBKrUSjeoW
wzEF6eap+Pig7DS6aGbK4RZK3rhV1k6hvuUbD98wz3BDD32thzJ9xekR9PFhr2cY
MxaWFeAmNwwd2metpPob5cQGJ34Sb7qbvVCHF9Hdx6SH8QlUYlsIk5pc4+DWSxPv
st5wGSQTYEqGs2Nz93sLnP3q64EScmcBfaLwiHkO/vS7pfLWtVT1rYVxr6dcm7s+
anIvpPb7+rMsIdk4c7xCssIWY89sBfB7dmi4/PciHGHXGpWi2YuxXrGm7nqXbHjO
KQPBmjpOEmDOqYmooKESmpyNVgLynRft6gk1FEuDwIq1U497SvwMZvEr7+Wh39M=
=ohul
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay behind reverse proxy

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi again

I don't know anything about haproxy config and how it should look like
unfortunately.

As for torrc:

ORPort :3128
NoAdevertise
ORPort :3128 NoListen

remove Address line.

Leave the contact info and other settings. Let us know if it works
this way.

On 3/9/2015 7:50 PM, efkin wrote:
> 
> 
> On 03/09/2015 03:35 PM, s7r wrote:
>> If you are using the free nginx, community project, that will
>> only allow you to deploy a http(s) proxy. Only the commercial
>> (paid) nginx allows you to deploy a TCP proxy (handles all TCP
>> traffic), which is what you need for a Tor relay.
> 
> nice to know!
> 
>> If you want to use a proxy, you should look into a TCP proxy
>> which will handle any type of TCP traffic, regardless of
>> protocol. (Tor uses http for directory requests [DirPort] but not
>> for ORPort). Make sure your relay can reach the other relays in
>> the consensus and it doesn't have any kind of restrictions or
>> limitations such as being able only to talk on certain ports or
>> reach a limited number of IP addresses, etc. Your relay needs to
>> be able to connect to all the other relays, so the clients can
>> build circuits through it.
> 
>> A free open source solution might be haproxy ( 
>> http://www.haproxy.org/ ) Maybe this will help you with your 
>> setup.
> 
> Took a look at it and is quite cool.
> 
>> Make sure you properly bind DirPort and ORPort to the correct 
>> interface and use NoAdvertise and NoListen accordingly. Provide 
>> more information about your setup and the relevant configs, if
>> you are not able to do it.
> 
> i just setup: ORPort 3128 Address oni-on.cf
> 
> and some other stuff like nicks and contact info.
> 
> my haproxy config is somehting like this:
> 
> frontend oni-on bind *:3128
> 
> acl host_onion hdr(host) oni-on.cf
> 
> use_backend onion if host_onion
> 
> 
> it seems that when it checks for reachability at the end of 20 mins
> it does not manage to reach it.
> 
> 
>> Thanks for running a relay!
> 
> still trying to set it up but a pleasure.
> 
> 
>> On 3/9/2015 1:46 PM, efkin wrote:
>>> hello tor ^.^
> 
>>> i'm trying to setup a tor relay behind a nginx reverse
>>> proxy... i would like to know if it's correctly setup.
> 
>>> i have this warn in the logs:
> 
>>> [warn] Received http status code 404 ("Not found") from server
>>>  '85.14.240.188:443' while fetching 
>>> "/tor/keys/fp/27B6B5996C426270A5C95488AA5BCEB6BCC86956".
> 
> 
>>> but then in the same log little bit after:
> 
>>> [notice] Tor has successfully opened a circuit. Looks like
>>> client functionality is working.
> 
>>> last message is : Now checking whether ORPort X.X.X.X:9001 is 
>>> reachable... (this may take up to 20 minutes -- look for log 
>>> messages indicating success)
> 
> 
>>> thx for support.
> 
>>> it's a great community!
> 
>>> efkin ___
>>> tor-relays mailing list tor-relays@lists.torproject.org 
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>>> 
>> ___ tor-relays
>> mailing list tor-relays@lists.torproject.org 
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJU/gqyAAoJEIN/pSyBJlsRrXsIAIuK70LrNYTV7SxqldCxjD7U
+26EtuE3ddb1MJks75ogeBvEKr3sHhiDUk278CDVoQuyMF/s7Tm5jPkxLrk0eNaV
32PtyECNjMQWigyBwmlrdcalvsvQtDs3agPrV5iUts//i9JqvuSoM1j3vi7j1Uba
ZvTT/ICznUDskLHMjkgY7UdOUmF4KYuMBc4ZDrAgqWixAusKbpDYx+eGenQLRhK4
ysFW5hbVvarqPQWvmC31ivwJ/pZ2riZGsmKKjwBXcQ6cOe/7f/2OQOQshjTS6JZM
690ZMx7DPnodXtOkeWRRCvqP8q9PsQYMbaCkl9Q6vLuEgGHzxi/0cWKPaZ0hnTg=
=/dV5
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay behind reverse proxy

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Yes, that means is working, theoretically. The log won't say anything
for the next 6 hours, and after 6 hours it will just say how many
circuits it has running, uptime and relayed bandwidth. These are the
default log settings. You can increase the verbosity of the log but
it's not required.

https://atlas.torproject.org/
Search here for your relay's nickname or IP address to see its flags
and what Advertised Speed is it showing to the network. Might start
with a low value but will grow in time.

https://consensus-health.torproject.org/consensus-health.html
go here, wait for the page to load (big page) and search with ctrl + f
and enter your relay's nickname. You will see here what flags were
voted for your relay by the directory authorities.

https://blog.torproject.org/blog/lifecycle-of-a-new-relay
This will help you understand how Tor's load balancing works and what
are the phases a new relay will go through.

Constantly keep an eye out for warnings/errors in Tor's log. Report
any misbehavior to this mail list and especially by tickets on Trac at
https://trac.torproject.org/

Remember to keep your Tor up to date whenever there is a new release,
especially when the release fixes a security issue.

I am glad I could help! Now I can say thanks for running a relay. If
it's an Exit relay, that is even better!

You might want to challenge us with a different customized setup next
time for your #2-nd relay :-) Cheers!



On 3/10/2015 12:07 AM, efkin wrote:
> hey!
> 
> basically with your setup and a little trick on haproxy it is
> working now or at least the log is saying:
> 
> [notice] Self-testing indicates your ORPort is reachable from the 
> outside. Excellent. Publishing server descriptor.
> 
> [notice] Performing bandwidth self-test...done.
> 
> but nothing else on the logs since half an hour...
> 
> does it mean it is working?
> 
> thx for support!
> 
> On 03/09/2015 10:03 PM, s7r wrote:
>> Hi again
> 
>> I don't know anything about haproxy config and how it should
>> look like unfortunately.
> 
>> As for torrc:
> 
>> ORPort :3128 
>> NoAdevertise ORPort > server should be reached>:3128 NoListen
> 
>> remove Address line.
> 
>> Leave the contact info and other settings. Let us know if it
>> works this way.
> 
>> On 3/9/2015 7:50 PM, efkin wrote:
> 
> 
>>> On 03/09/2015 03:35 PM, s7r wrote:
>>>> If you are using the free nginx, community project, that will
>>>>  only allow you to deploy a http(s) proxy. Only the
>>>> commercial (paid) nginx allows you to deploy a TCP proxy
>>>> (handles all TCP traffic), which is what you need for a Tor
>>>> relay.
> 
>>> nice to know!
> 
>>>> If you want to use a proxy, you should look into a TCP proxy
>>>>  which will handle any type of TCP traffic, regardless of 
>>>> protocol. (Tor uses http for directory requests [DirPort]
>>>> but not for ORPort). Make sure your relay can reach the
>>>> other relays in the consensus and it doesn't have any kind
>>>> of restrictions or limitations such as being able only to
>>>> talk on certain ports or reach a limited number of IP
>>>> addresses, etc. Your relay needs to be able to connect to all
>>>> the other relays, so the clients can build circuits through
>>>> it.
> 
>>>> A free open source solution might be haproxy ( 
>>>> http://www.haproxy.org/ ) Maybe this will help you with your
>>>>  setup.
> 
>>> Took a look at it and is quite cool.
> 
>>>> Make sure you properly bind DirPort and ORPort to the correct
>>>>  interface and use NoAdvertise and NoListen accordingly.
>>>> Provide more information about your setup and the relevant
>>>> configs, if you are not able to do it.
> 
>>> i just setup: ORPort 3128 Address oni-on.cf
> 
>>> and some other stuff like nicks and contact info.
> 
>>> my haproxy config is somehting like this:
> 
>>> frontend oni-on bind *:3128
> 
>>> acl host_onion hdr(host) oni-on.cf
> 
>>> use_backend onion if host_onion
> 
> 
>>> it seems that when it checks for reachability at the end of 20 
>>> mins it does not manage to reach it.
> 
> 
>>>> Thanks for running a relay!
> 
>>> still trying to set it up but a pleasure.
> 
> 
>>>> On 3/9/2015 1:46 PM, efkin wrote:
>>>>> hello tor ^.^
> 
>>>>> i'm trying to setup a tor relay behind a nginx reverse 
>>>>

Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

obfs4 will not run on 0.2.4.x , you need at least 0.2.5.x or 0.2.6.x

First, upgrade your Tor.

You can use torproject.org repositories. If you are running wheezy:

1. Add the repository:
# echo "deb http://deb.torproject.org/torproject.org wheezy main" >>
/etc/apt/sources.list

2. Add the signing key:
# gpg --keyserver keys.gnupg.net --recv 886DDD89; gpg --export
A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | apt-key add –

3. Install keyring:
# apt-get update && apt-get -y install deb.torproject.org-keyring

Now upgrade your Tor, an apt-get -y install tor would upgrade to 0.2.5.1
1.

You can install obfs4proxy from deb.torproject.org too:

# echo "deb http://deb.torproject.org/torproject.org obfs4proxy main"
>> /etc/apt/sources.list
# apt-get update && apt-get -y install obfs4proxy

Now, modify your torrc to enable the obfs4 transport. Make sure you
also add ExtORPort auto in torrc so it will report some useful
statistics. obfs4proxy also supports obfs3, and some users still use
that, so if you can be an obfs3 and obfs4 bridge at the same time
(requires just one more open port) it would be great.

Sample torrc entry for enabling obfs4 and obfs3:
ExtORPort auto
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs3 [::]:port
ServerTransportListenAddr obfs4 [::]:port

To make the bridge even better, you can bind obfs3 and obfs4 to lower
ports (< 1024), if you have them free, such as obfs3 on 80 and obfs4
on 443 (for example). This will help users behind really restrictive
firewalls who only allow connections on few ports. You can easily do
this with libcap2-bin package:

# apt-get -y install libcap2-bin
# setcap 'cap_net_bind_service=+ep' /usr/bin/obfs4proxy

To make this persistent after a reboot, edit the /etc/rc.local file
and add this line before 'exit 0':
setcap 'cap_net_bind_service=+ep' /usr/bin/obfs4proxy

Hope this helps. If you don't want to use deb.torproject.org,
everything required is also included in raspbian main repo:

http://archive.raspbian.org/raspbian/pool/main/t/tor/
http://archive.raspbian.org/raspbian/pool/main/o/obfs4proxy/
http://archive.raspbian.org/raspbian/pool/main/libc/libcap2/

If you want to use raspbian repo, simply ignore the lines where you
add deb.torproject.org to your sources.list file and just upgrade,
install the required packages and modify your torrc file.

Thanks for running a bridge.


On 3/28/2015 11:47 PM, jchase wrote:
> Hello, I run a bridge on a Raspberry Pi running Debian Wheezy and 
> tor 0.2.4.26 . I have obfs3 installed and would like to upgrade to 
> obfs4. So far this has not been possible. If I understand it 
> correctly, my best bet is to update to tor 0.2.6.x and then
> install obfs4. Let me know if I'm wrong. And if I'm right, what is
> the easiest way to do that? Thanks, J. Chase 
> ___ tor-relays mailing 
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVFyjiAAoJEIN/pSyBJlsRd+MH/36/4abGF4/h/4YZuf1TG2sf
0jJLaGt8Tg3c7038+7TbVwj884hvnA/gYaJTr8sPH8+2yuIqyxBfBu5IYNCaTCgT
7beR6KY4tJv1IgoReHUsn/4PLZ6K9vsnFTu08oQwjjolGcdx4BlAbHcsm0pZaGWA
yAZlG1GKHGdn77bRHGi9F1ZKthRbMEQmXNV7abZPAbqjVFrTngOo68lDhIv46orP
YPAhXx1v08cXZjfS0jcuwwaqhJPfxfP3nJSCNcJPG47ng81/eLWr5JgU3neyPhiN
frZa2LCngPEeNlY5bjmaPrm/McmOM2Onrx9rXDEpezrCtAyQeGett2W1u/k+HI8=
=VpQT
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

J - those links are for reference only. They cannot be added in
sources.list file because they are not valid repository strings.

Here is what I've learned so far.
If you are on Raspberry Pi B/B+ (ARMv6 CPU) you will not be fully
compatible with armhf architecture from Debian Wheezy / Raspbian
Wheezy because that requires at least ARMv7 CPU. Raspberry Pi 2 has an
ARMv7 CPU quad core @ 900 Mhz which should be fully compatible with
armhf. For previous Raspberry models, some armhf packages for wheezy
might work, some not.

True, by default from Raspbian repo, apt-get will install Tor 0.2.4.26.

I was able to manually get the .deb of Tor 0.2.5.11 and install it,
and it works good, no errors:

# cd ~/ && wget
http://archive.raspbian.org/raspbian/pool/main/t/tor/tor_0.2.5.11-1_armh
f.deb
# sudo dpkg -i tor_0.2.5.11-1_armhf.deb

- -press N to keep your current torrc file when prompted-


The obfs4proxy package in Raspbian main repo is borken. I could not
install it, there is no .deb there.

We currently do not have armhf or armel packages for obfs4proxy in
deb.torproject.org, but Yawning (CC'ed) will let us know when he has
time how we can build obfs4proxy from git on Raspbian.


On 3/29/2015 10:31 PM, jchase wrote:
> Thanks for your answer. Your instructions were good and explicit, 
> but you hit on two of the problems I run into. I installed tor 
> 0.2.5.11-1 from torproject.org and got two error messages that I 
> couldn't solve. I would have to go back and re-install 0.2.5.11-1 
> to tell you what they were. In any case they weren't configuration 
> problems. I had pretty much the same problem months ago when I 
> installed a tor 0.2.5.x on Pi. Which leads me to want to use a 
> raspbian repo. only I am unable to get /etc/apt/sources.list to 
> recognize http://archive.raspbian.org/raspbian/pool/main/t/tor/
> (or variations thereof) as a repository. And in my main raspian
> repo tor doesn't go any higher than 0.2.4.26 . So simply updating
> tor does not work. How do I add 
> http://archive.raspbian.org/raspbian/pool/main/t/tor/ 
> http://archive.raspbian.org/raspbian/pool/main/o/obfs4proxy/ 
> http://archive.raspbian.org/raspbian/pool/main/libc/libcap2/ as
> one or more alternative repositories or force an install? Thanks,
> J. Chase
> 
> 
> tor-relays-requ...@lists.torproject.org:
>> Message: 4 Date: Sun, 29 Mar 2015 00:19:14 +0200 From: s7r 
>>  To: tor-relays@lists.torproject.org Subject:
>> Re: [tor-relays] Installing obfs4 on Raspberry Pi bridge
>> Message-ID: <551728e2.4030...@sky-ip.org> Content-Type:
>> text/plain; charset=windows-1252
>> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Hi,
>> 
>> obfs4 will not run on 0.2.4.x , you need at least 0.2.5.x or 
>> 0.2.6.x
>> 
>> First, upgrade your Tor.
>> 
>> You can use torproject.org repositories. If you are running 
>> wheezy:
>> 
>> 1. Add the repository: # echo "deb 
>> http://deb.torproject.org/torproject.org wheezy main" >> 
>> /etc/apt/sources.list
>> 
>> 2. Add the signing key: # gpg --keyserver keys.gnupg.net --recv 
>> 886DDD89; gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
>> | apt-key add ?
>> 
>> 3. Install keyring: # apt-get update && apt-get -y install 
>> deb.torproject.org-keyring
>> 
>> Now upgrade your Tor, an apt-get -y install tor would upgrade to 
>> 0.2.5.1 1.
>> 
>> You can install obfs4proxy from deb.torproject.org too:
>> 
>> # echo "deb http://deb.torproject.org/torproject.org obfs4proxy 
>> main"
>>>>>> /etc/apt/sources.list
>> # apt-get update && apt-get -y install obfs4proxy
>> 
>> Now, modify your torrc to enable the obfs4 transport. Make sure 
>> you also add ExtORPort auto in torrc so it will report some 
>> useful statistics. obfs4proxy also supports obfs3, and some
>> users still use that, so if you can be an obfs3 and obfs4 bridge
>> at the same time (requires just one more open port) it would be
>> great.
>> 
>> Sample torrc entry for enabling obfs4 and obfs3: ExtORPort auto 
>> ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy 
>> ServerTransportListenAddr obfs3 [::]:port 
>> ServerTransportListenAddr obfs4 [::]:port
>> 
>> To make the bridge even better, you can bind obfs3 and obfs4 to 
>> lower ports (< 1024), if you have them free, such as obfs3 on 80 
>> and obfs4 on 443 (for example). This will help users behind 
>> really restrictive firewalls who only allow connections on few 
>> ports. You can easily do this with libcap2-bin package:
>&

Re: [tor-relays] amount of unmeasured relays continuously rising since 2 weeks

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi nusenu,

Again thanks for keeping an eye on things. At least partially, the
balance of measured/unmeasured should be fixed in the new few days.

To relay operators, in the mean time, please bare for few more days
and sorry for the inconvenience, I can imagine what it feels like to
have a high capacity unmeasured relay. Developers already know that a
new bandwidth measurement system is badly needed, just need to find
workarounds for the short term until such a system will be ready.



On 5/19/2015 12:02 AM, nusenu wrote:
> now even DocTor starts to complain
> 
> https://lists.torproject.org/pipermail/tor-consensus-health/2015-May/0
05772.html
>
> 
___
> tor-relays mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVWlkwAAoJEIN/pSyBJlsRPUEH/3x9638bl0mSoq2oEpC3MazV
GgCEh/MG+6dWDKdASG0qdrpdFPt4VrihuwhIOB5l5G9x6RUhf1LEZvGjdqYiyz0Y
JRB1m4Mek8x0iHKeVQeY8VnWX3WQBEpgXc4EVUHgkTGXZByLSAueyYnviD0hGeiy
ftfaBhN6SE5nzxAVBmzHBiC5rmFl5cam3o9YxguGOkugaWeLHgHDECbQ+yjacy1N
6VjudnuuFeAu2myfo6g2W7tCHswVaDwqyUhmhuab9OUguImv0HdHoGgeJM/tn3TZ
EQuRSKYV4jhfCkzpcLvzcsueJKuLfchGyJ8JxiD/vbLuXe9swLJsUcwORg4BMQQ=
=w3+J
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

On 5/20/2015 12:07 PM, Tor User wrote:
> Hello,
> 
> We have been operating a moderately successful public tor relay for
> a while now.   Having read about how TOR works back a couple of
> years ago, I was more or less sold on the idea that if traffic
> originating on your local network uses your own TOR relay as the
> first hop (entry node), then by the time your traffic has left your
> tor relay, people in the middle can't tell the difference between
> traffic originating from your network and other (relayed) traffic
> passing through your TOR relay.
> 

It's Tor, not TOR or tor.

> I also understand that this still doesn't protect you from an exit
> node being able to see your traffic (and why you should use HTTPS
> with a high-quality cipher if it's really important), and that
> there are other ways your traffic can be analyzed -- but all in
> all, I would rather our TOR traffic enter the TOR network through a
> relay I *KNOW* I can trust (mine!) than leave it to chance.
> 

You could run your own *Exit* node on your network, and use that as a
static exit point, which will mix the traffic in your local network
with the traffic of other Tor users, and you won't have to fear that
the Exit node you are using is malicious and is logging your traffic
or doing strange stuff with it.

> We have polipo running on our public TOR relay, configured to
> accept traffic from our local subnets.  We've basically followed
> the info in this TOR doco:
> 
> https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorServer
>
>  The TOR browser bundle appears to function correctly, ie, it is
> able to start up, open circuits, etc. and we get the expected
> Congratulations! page opening a new browser window.  But when
> clicking the green onion to show the circuit of relays handling the
> browser's connection, our relay is never the first hop.
> 
> I'm using TBB 5.01a on one particular system, and for an example,
> it shows this for the circuit:
> 
> - This browser - Austria (aa.bb.cc.dd) - Germany (ee.ff.gg.hh) -
> Guatemala (ii.jj.kk.ll) - Internet
> 

The way I understand it, it looks to me that you are confusing 2
things. When you enabled polipo on the Tor relay in your network, you
just enabled a http-proxy which forwards the requests to the Socks5
proxy opened by the Tor client running on that relay (same Tor
instance). When you run a Tor relay, the client functionality is also
enabled by default, unless you specify SocksPort 0 in the torrc file.

The Centralized Tor Server allows you to have one Tor client/instance
for multiple computers in the same network. You need to run only one
Tor instance on one server, and the other users in the network do not
need to run own local Tor client instances, otherwise they will just
be using Tor-through-Tor which is a terrible idea and it hurts
anonymity in an unknown way.

The relay you are running can never be the first hop, because the
second Tor client running on your workstation is selecting another
first hop and it is using it through the polipo proxy you've provided.
In simple words, you are doing Tor-through-Tor and it is very very wrong
.


> I have tried defining an EntryNodes statement with the $fingerprint
> of our TOR relay and setting StrictNodes 1 in the TBB's torrc file,
> but it can't ever establish a circuit when I try this.  We get
> messages like this logged on the browser's tor:
> 
> 05/20/2015 04:21:20.700 [WARN] Failed to find node for hop 0 of our
> path. Discarding this circuit. 05/20/2015 04:21:20.700 [WARN]
> Failed to find node for hop 0 of our path. Discarding this
> circuit. 05/20/2015 04:21:20.900 [NOTICE] Closing
> no-longer-configured Socks listener on 127.0.0.1:9150 05/20/2015
> 04:21:20.900 [NOTICE] DisableNetwork is set. Tor will not make or
> accept non-control network connections. Shutting down all existing 
> connections. 05/20/2015 04:21:20.900 [NOTICE] Closing old Socks
> listener on 127.0.0.1:9150 05/20/2015 04:21:21.700 [NOTICE]
> Delaying directory fetches: DisableNetwork is set.
> 

Of course, you are trying to connect to server let's call it 'Bob' via
a polipo proxy running also on the same server 'Bob', e.g. trying to
connect back to self in a strange way which Tor forbids for security
reasons.

> 
> Is it possible to define your desired entry node via IP address and
> port, or some other way that does not require a successful
> directory connection/circuit first?  (so it can find the relay by
> its fingerprint)? It seems like a chicken vs. egg problem...  Or
> what about defining a directory for the client to use by its
> IP/port?  We are operating a public directory as well.
> 

No, that is not possible. Does your relay have the Guard flag so it
can be used as the first hop? Check on https://atlas.torproject.org/
and let us know what flags you have for your relay. It needs to be
fast and up most of the time in order to get the Guard flag.

> I can't find any info about t

Re: [tor-relays] amount of unmeasured relays continuously rising since 2 weeks

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Julian

Thanks for your contribution to Tor!
Please keep them running, as much as you can. We already struggle to
(at least partially) solve the issue for the short term, by launching
more bandwidth authorities. On the long term, some research groups are
working on a better bandwidth measurement system. We are all anxiously
waiting for it, but unfortunately there is no ETA for it at this moment.

To answer your question, it's not exactly true that _current system is
clearly broken_, or totally broken. It works, but does not work 100%
(e.g. we are missing some bandwidth). It's better than going back to
self advertising bandwidth. By default (if not explicitly set a
MaxAdvertisedBandwidth in torrc), Tor will self advertise the port
speed which it sees on the server where running, which is very very
often (I could say almost) of a higher value than that server can
really handle. For example, take a VPS which has a network port of 1
gbps seen by the operating system, but it's running on a cluster with
100 another virtual machines and each is individually capped at
hypervisor lever to 10mbit.  Going back to self advertised bandwidth
would assign unfair weights to some relays and cause Tor clients to
choose paths in a buggy way, we could overload the less capable relays
and cause circuit failure for clients, decreasing the Tor performance
/ user experience overall.


The bandwidth authorities are not so sensitive as directory
authorities, but a bandwidth authority is useless unless it talks to a
directory authority which is allowed to vote in the consensus. That is
why bandwidth authorities are run by the same trusted people who also
run directory authorities.

The analogy you are describing does not reflect the reality in this
situation. For the issue we are facing, no directory authority
operator has a solution, nor anyone. It's not like someone can do
something about it, but does not do it. Still, everyone is making
efforts to fix it, in the measure in which it is technically possible.
The system where we have a known number of directory authorities,
hardcoded and run by trusted people is very well researched and
studied, and it eliminates a lot of real and practicable attacks. I am
all for decentralized and distributed systems, but at this moment I
really think we are doing the best we can. Everyone would prefer Tor
to be decentralized and trustless, but this is not that simple and
cannot be done immediately. A lot of research is needed.

P.S. having the semi-centralized system we currently use (with few
Directory authorities run by trusted people) does not mean you are
100% depending on the directory authorities or that they can
compromise your anonymity. You are trusting them for consensus data
(info about all the relays in the Tor network) which your client uses
to build circuits. If something happens to the majority (50% + 1) of
the directory authorities, this would prevent the Tor network to
function at all, for anyone, but the previous activity within the Tor
network of an user won't be compromised. This is a fair trust limit I
could say, when you take in consideration the fact that total
decentralization will open the door to many other attacks, far worse
than this.


(fortunately) there is no way to 'force' a bandwidth authority or
directory authority to do anything.


Please bare little more and keep the relays running if you can. After
all, we are a community comprised in volunteers involved in research
and experiments, sometimes things like this happen. Just keep calm,
run relays and use Tor. It'll be fixed.

On 5/23/2015 8:58 AM, Julian Plamann wrote:
> I have a non-exit relay that has been up and running with 100%
> uptime on a 15mbps circuit for going on 20 days that is still
> unmeasured.
> 
> I also have an exit node on a 100mbps un-metered link that I
> brought online 7 days ago and purchased specifically to donate to
> Tor that is still unmeasured by the bwauths.
> 
> Perhaps it's time to go back to self-advertised bandwidth since
> this system is clearly broken?
> 
> Furthermore, I understand the necessity of having the bwauths run
> by trusted/known members of the development community, but what is
> the criteria for this trust? Does running a broken directory server
> for going on three weeks without taking the steps to fix it still
> fall within this "trust" definition?
> 
> --- Julian Plamann
> 
> julian (at) amity.be GPG: 0x96881D83
> 
> 
> 
> On 2015-05-22 10:32 am, Marcus wrote:
> 
>> Hey,
>> 
>> I still have the problem, that my relay (non-exit) is "not
>> measured". I tried to set up a new ID but this doesn't work. The
>> relay ist still not measured since one week.
>> (12FD624EE73CEF37137C90D38B2406A66F68FAA2) I don't know much
>> about the DA, but I checked that only two of nine have measured
>> my relay. Only gabelmoo and moria1 did measure the relay. An
>> other smaller relay I own 
>> (FFB78E1F3E29091212C23A24A9779072800E

Re: [tor-relays] How to use our own TOR relay as entry node for local network hosts

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi

Glad you understood what you are doing wrong. In this case, you can
use your relay as a guard for the clients in your network. See in my
previous email suggestion #2, and all your clients will have the
desired guard. Install Tor browser on each client and don't use proxy
setting, connect directly with StrictNodes and EntryNode.

Cheers!



On 5/23/2015 3:14 PM, Tor User wrote:
> Hi s7r,
> 
> Thank you for your reply.  There's a lot of good info in it and
> I'll be reconfiguring the clients.
> 
> The fact that I've been doing Tor-through-Tor unawares explains a
> lot. It did seem odd to have polipo in the mix, but it makes sense
> now, that would only be if the LAN clients weren't already running
> their own Tor clients (running TBB).
> 
> Our public Tor relay is an entry guard.  We don't allow any exiting
> with it but it's stable, fast, HSDir, etc. and has the guard flag.
> 
> 
> 
> On 05/20/2015 07:05 AM, s7r wrote: Hello,
> 
> On 5/20/2015 12:07 PM, Tor User wrote:
>>>> Hello,
>>>> 
>>>> We have been operating a moderately successful public tor
>>>> relay for a while now.   Having read about how TOR works back
>>>> a couple of years ago, I was more or less sold on the idea
>>>> that if traffic originating on your local network uses your
>>>> own TOR relay as the first hop (entry node), then by the time
>>>> your traffic has left your tor relay, people in the middle
>>>> can't tell the difference between traffic originating from
>>>> your network and other (relayed) traffic passing through your
>>>> TOR relay.
>>>> 
> It's Tor, not TOR or tor.
> 
>>>> I also understand that this still doesn't protect you from an
>>>> exit node being able to see your traffic (and why you should
>>>> use HTTPS with a high-quality cipher if it's really
>>>> important), and that there are other ways your traffic can be
>>>> analyzed -- but all in all, I would rather our TOR traffic
>>>> enter the TOR network through a relay I *KNOW* I can trust
>>>> (mine!) than leave it to chance.
>>>> 
> You could run your own *Exit* node on your network, and use that as
> a static exit point, which will mix the traffic in your local
> network with the traffic of other Tor users, and you won't have to
> fear that the Exit node you are using is malicious and is logging
> your traffic or doing strange stuff with it.
> 
>>>> We have polipo running on our public TOR relay, configured
>>>> to accept traffic from our local subnets.  We've basically
>>>> followed the info in this TOR doco:
>>>> 
>>>> https://trac.torproject.org/projects/tor/wiki/doc/CentralizedTorSer
ver
>>>>
>>>>
>>>> 
The TOR browser bundle appears to function correctly, ie, it is
>>>> able to start up, open circuits, etc. and we get the
>>>> expected Congratulations! page opening a new browser window.
>>>> But when clicking the green onion to show the circuit of
>>>> relays handling the browser's connection, our relay is never
>>>> the first hop.
>>>> 
>>>> I'm using TBB 5.01a on one particular system, and for an
>>>> example, it shows this for the circuit:
>>>> 
>>>> - This browser - Austria (aa.bb.cc.dd) - Germany
>>>> (ee.ff.gg.hh) - Guatemala (ii.jj.kk.ll) - Internet
>>>> 
> The way I understand it, it looks to me that you are confusing 2 
> things. When you enabled polipo on the Tor relay in your network,
> you just enabled a http-proxy which forwards the requests to the
> Socks5 proxy opened by the Tor client running on that relay (same
> Tor instance). When you run a Tor relay, the client functionality
> is also enabled by default, unless you specify SocksPort 0 in the
> torrc file.
> 
> The Centralized Tor Server allows you to have one Tor
> client/instance for multiple computers in the same network. You
> need to run only one Tor instance on one server, and the other
> users in the network do not need to run own local Tor client
> instances, otherwise they will just be using Tor-through-Tor which
> is a terrible idea and it hurts anonymity in an unknown way.
> 
> The relay you are running can never be the first hop, because the 
> second Tor client running on your workstation is selecting another 
> first hop and it is using it through the polipo proxy you've
> provided. In simple words, you are doing Tor-through-Tor and it is
> v

Re: [tor-relays] Raspberry Pi - Relay Setup

[s7r]

Just install Tor:

sudo apt-get -y install tor

and edit the torrc file:
nano /etc/tor/torrc

make it a relay by adding this content (add your values and data):
ORPort 
Nickname 
ContactInfo 
ExitPolicy reject *:*

*If you are behind NAT, make sure the ports are properly forwarded to
your raspberry pi. Use a static internal IP for the raspberry pi so the
port forwarding rules will remain active in case of a reboot.

Note the raspberry pis are ok (if the internet connection speed is also
good) but cannot handle as many concurrent Tor circuits as a real server
would. If your internet bandwidth is capped, maybe try running an obfs4
bridge on the raspberry pi.

On 6/23/2015 10:53 PM, Tor Zilla wrote:
> I did not say i want to setup an exit relay.
> 
> I am looking forward to setup a Non-exit relay
> 
> ===
> 
>> Date: Tue, 23 Jun 2015 21:39:01 +0200
>> From: t...@bruzzzla.de
>> To: tor-relays@lists.torproject.org
>> Subject: Re: [tor-relays] Raspberry Pi - Relay Setup
>>
>> I don't know in which country you live but an exit relay with your
>> private internet connection might bring you in legal trouble.
>>
>> On 06/23/2015 09:26 PM, CJ Barlow wrote:
>> > What model of NetGear do you have?
>> >
>> > A static IP is not required. You may need to setup a Dynamic DNS if tor
>> > has issues with your dynamic IP.
>> >
>> >
>> > On Tue, Jun 23, 2015, 13:22 Tor Zilla > > > wrote:
>> >
>> > Hello All,
>> >
>> > I just bought a Raspberry Pi.. Wanted to setup as a Tor non exit relay.
>> >
>> > I have read so many instructions online on how to set it up but i am
>> > facing issues with opening ports.
>> >
>> > I am using a NetGear Router and require your inputs with the same.
>> >
>> > Also is static IP mandatory for setting up a relay?
>> >
>> >
>> > Thanks,
>> > TorZilla11
>> > ___
>> > 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
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Problems with second/third relay

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello

Thanks for adding one more relay.

It's ok to have 2 relays on one IP address, both should work.

What do you mean you have enabled DMZ and port forwarding?

If you enable DMZ, that will forward ALL ports to 1 IP address in the
subnet (NAT). You cannot enable DMZ on 2 different internal IP
addresses in the same LAN. Also, if DMZ is enabled one time, port
forwarding for the second IP won't work since all ports are already
forwarded to the DMZ host.

Use static internal LAN IP addresses for both relays. IP1 for relay1
and IP2 for relay2. So after a power cutoff everything will get back
online with the same IP config and port forwards will work.

Forward port 443 to internal IP1
forward port 80 to internal IP1 (if you also use DirPort)
forward port 9001 to internal IP2
forward port 9030 to internal IP2 (if you also use DirPort)

Examples are informative, use whatever ports you want/can.

Let me know if it worked.


On 6/24/2015 5:22 PM, TORnet Zone wrote:
> Really need some help here, just cannot find the answer.
> 
> I've been running 2 middle relays for a year now, from a
> home/business IP, one DSL and the other cable. Only problems were
> brief and IP induced all has served the system well.
> 
> I recently attempted to add a 3rd relay on the same cable feed as
> one of my others, but there is no way the ORport will connect. I
> have DMZ'd the static address, forwarded the ports, changed the
> ports - the ORport just will not open. And yes I realize diversity
> is tightened, but I'm trying to help all I can on my budget. First
> - CAN there be two relays on the same dynamic address (different 
> port numbers) ? How? Do I need some form of DNS service to help?
> 
> Relay 1 is Linux 3.2.0-86 and Tor 0.2.6.9.  Relay 2 is Linux
> 3.16.0-30 and Tor 0.2.6.9. The DMZ'd relay worked until I had to
> forward 9001 to the 2nd, then it quit. Uptime was normally 40 - 50
> days until a kernel update, or something major. Both are old
> laptops on battery backups that never have power down. Router is an
> Archer C7, latest firmware.
> 
> -Gumby ___ tor-relays
> mailing list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVisK1AAoJEIN/pSyBJlsRuKAH/iCxwhmKu4jv+VprwZ7c3M5o
E5Bx01V9Dhi2AL4tu2QfSA4FQJFmvBOJr1v2LytvdLswfdale26+wZM9x/NLMlfS
E8mM5FrEiJ+vi4MmSxgx94SoeAPzFJ+dlnrNuvYihdGkAJwchT5+WdtcM0t4YqM8
CJ95LZRh3r6w36AO6RiDTYRBfG4AhsZmUjftsvSSntFTcleJJV+uC5wM9SBuUq5f
Ne9MXIXC8+pmfAsYhmS7MwkWcB8IP1k/0vgLRhh/EbZAxc5eYsEyO502TxR4HFt0
BzGMBuP0yMl4Frn4oiKnB4jiUfJPLrHc8vT5hIA8U6CA+4BYHTbKGU1tgmjP0qY=
=jdzn
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] be in time or not to be in time ?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I used to receive this message regularly from time to time on a KVM
virtual machine running Debian 7 Wheezy (Tor exit relay).

NTP process was working fine, no errors. I did manually:
# service ntp stop
# ntpdate 0.rhel.pool.ntp.org
# service ntp start

Are you using a virtual machine as well? If yes, the answer might be
that the host is overwriting your guest (vm) clock. You can either
disable hwclock, either disable ntp on guest (vm) operating system and
rely on the clock of your host server.

On 6/28/2015 12:14 PM, Toralf Förster wrote:
> Hhm,
> 
> found this in the log:
> 
> Jun 28 03:58:37.000 [warn] Our clock is 1 minutes, 23 seconds
> behind the time published in the consensus network status document
> (2015-06-28 02:00:00 UTC).  Tor needs an accurate clock to work
> correctly. Please check your time and date settings!
> 
> NTP runs fine at this exit relay since months, and I found nothing
> in the log which would tell me that sth was wrong with the time.
> 
> Any hints / explanations ?
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVkAZWAAoJEIN/pSyBJlsRzUkH/06LopXsYIV/mSMrow7e/F8I
hm8S3SP6fTpvlFXaw2q3r4NDq/TO+8apinty18UYNT6de/PaKO3BnP9uQ/8EXjcp
jK/T52W6y0T/PD/tq/yi9SLfZoL35msTeBrWc6z/+Qq0SYuJq69dt/YmJ1ml4Vah
8drG+AIDuBy8ttEKEOSvlrmgAnaqoC9+pDNLs5Sc8wpMudTseUAzL1myjrn4WBaT
QXx+UJwH5pzniZT1N6foqYL9Tzggm5Y0GigyRgpuHRqt/s49iTOfIMo9VZtf3JxX
v1tOhHs2d0Ne4TdFupZI4mTQaJpzlU/Vxls6e/VyDdrh7jQs7vKeV15GrLTlVFQ=
=wbn8
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Question about responding to abuse request

[s7r]

Hi,

Usually those are automated messages. I get them all the time as well.
They are just relaying abuse messages. The text in their message is
standard, and includes all cases so to say. If you scroll down the
email, you will see the target IP and few logs. Usually this is the
result of automated scripts talking directly to Webiron, which send the
message automatically (no humans involved) to the abuse handle of a
certain IP address.

I recommend you not to take any action unless you are contacted by
humans, with real abuse reasons. Then, you explain what Tor is, provide
some links, and if the reporter is still concerned and insists
explicitly, you could block his IP ranges from your exit. I don't see
why a sane person would ask for this, since this can be better
implemented at their side, with few firewall rules...


On 7/5/2015 8:21 PM, Patrick ZAJDA wrote:
> Hi all,
> 
> I run a Tor exit node, and I received an abuse complain from Webiron.
> In this mail, I can read the following:
> "If you run a VPN, anonymizer service (like a TOR exit or proxy node),
> or business intelligence not contracted with the site owner, then we
> request that the targeted range be blocked from your service. If it is
> being blocked, then it's at the right and choice of our clients to
> refuse access."
> So if I understand correctly, they ask me to block the targeted range
> they give me in this report.
> 
> I know I can block this IP range by adding it to my exit policy, but I
> would like to know how others exit node operators manage these type of
> requests, because I ask myself if it is not against tor philosophy to
> block access to a specific network to Tor users.
> 
> Thanks all in advance for your answers.
> 
> Best regards,
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] pinning relay keys to IPs (or not)

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello Yawning,

We need to confirm this: is a relay holding TLS connections to the
majority of the other relays?

On a relay with over 100 days of uptime (middle relay) Stable, HSDir,
etc. I have (# netstat -a | wc -l) 1942 connections. Another one, with
less uptime just has 548 connections. These relays have a small
consensus weight. A guard with good consensus weight has much more,
but anyway under the ~6400 (total number of relays in the consensus).


On 7/26/2015 7:48 PM, Yawning Angel wrote:
> On Sun, 26 Jul 2015 16:11:56 +0200 nusenu 
> wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>> 
>> [split from 'Giving away some "pre-warmed" relay keys for
>> adoption']
> 
> Ok.
> 
>>> I'm of the opinion that it may be worth adding code to pin
>>> relay identities to IP addresses on the DirAuth side so that
>>> consensus weight and flag assignment gets totally reset if the
>>> ORPort IP changes, but if there's too much churn already it may
>>> cause more trouble than it's worth.
>> 
>> I hope such code will not be added, because it renders relays on 
>> dynamic IPs basically useless. In the past ~week only there were
>> >1000 fingerprints (<3% cw fraction) using more than one IP
>> address (in that timeframe)
> 
> Hey neat, numbers, thanks. <3% cw doesn't seem that bad.
> 
> I will reiterate that such a thing only will become viable once
> the bandwidth measurement stuff sees massive improvement (and it is
> being worked on), so this isn't a short term thing, and is just an
> idea.
> 
> I question the usefulness of most of the relays running on
> residential lines in the first place for other reasons (Eg: most
> consumer routers are crap, and will probably not be able to
> simultaneously maintain a connection to every single other relay +
> bridge, which is rather unhealthy to the network overall.  Being
> able to measure this and delist/reduce consensus weight here would
> be good as well.).
> 
> If the relay's IP is constantly changing significantly faster than
> the Guard rotation interval (needs more numbers here), I'm not sure
> if they make great Guards, but this is an arma/asn type question
> since they think more about Guards than I do.
> 
> Under a Tor that has the sort of pinning behavior I envision, a
> relay that changes an IP once in a blue moon still remains useful,
> a relay that changes an IP frequently (for some definition of
> frequently) will be used as a middle only (which is still useful).
> 
> Regards,
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVtSJJAAoJEIN/pSyBJlsRykoH/2RlWBnvgg2/Ecux3BCOEH7d
UgpmBufoX5/g2wqNkixNhSVPICCbSnzie5HuIcSjZXUZ1B7YZPU86xgZPKFRm5pn
lMzgfsoUUYsOwz9PluRC0Og5YbssUIpB71jOhOaCO+RxvX034s4FVZbd++ByH1qi
rXzV+d6KRaQAB6+Togo+qHy8NTQJqoGpw8y4ikJa96puyJD95AAjs2KBwaqOUsGD
A4IGNSsEUbfRfkZURDqecasQnQPsHtH3OBlnv2/pKmlp5DuxSQJNSrqqpqDRa8su
XGtXZkYd7tqCCE6EJRau4MUaiRV5CvQImcYEmyyNSMmiPSXKwvaA7cpiYjJMga8=
=UCjN
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I think that is to maintain a backward compatibility. Tor tries as
hard as possible to maintain backward compatibility with older
versions, unless something critical which requires deprecation
regardless some relays will disappear from the consensus.

I guess this is the reason we currently prefer ECDHE but do not reject
DHE. In the future, when we are certain everyone upgraded to new
enough OpenSSL, we can safely reject DHE all the time.

On 8/2/2015 6:57 PM, starlight.201...@binnacle.cx wrote:
> At 08:26 8/2/2015 -0700, you wrote:
>> It also may not tell you their ordering preference (but it might!
>> again, you'd have to look at the code.)
> 
> That "openssl s_client" test I ran was against my 0.2.6.10 with
> openssl 1.0.2 relay.
> 
> It's certain that ECDHE is preferred over DHE, but my thought is
> that, especially with 0.2.7 dropping openssl 0.9.8 (no ECDHE), that
> relays should refuse to accept DHE connections entirely.
> 
> We've seen many downgrade attacks and who knows for certain if none
> remain buried in the openssl?  Seems prudent to kill-off DHE.
> 
> ___ tor-relays mailing
> list tor-relays@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVvkzcAAoJEIN/pSyBJlsRb+cH/28mx151I91uZT8buZwyAA3q
S1HYrNayFkb7jfSTxc11HLF6TBICH85ENlpxvMRdHVB8+rQsL50+4M39+adBSgwx
wV49UthoSK8sIjQet5e59STE+8afCa/BWXyfktQmehl4If3VXtWwE79LqKn6pfI3
aQ1iufhhkBDcRzFa0LeOI8S7Ui+WhuJcyczcPlu7A8sl6xu2tFD1v0MIsZaGeZSu
wUYiDdMtdVypkf8+NH7ddQPzvUU9pVTfSCj/Fa7z5Jr+tddLGLwiTyx0gR0nFjAm
s4O65LO8p6RPz7ExAwKc6a3uY4GTMS9aklEWfmPTfAIkT1k/zvhiV+JbiXeGqJ8=
=b48O
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] BWauth no-consensus state in effect

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

That is correct Mike Perry - (at least in my case) Tor is much slower
(any page takes more time to load) than when bandwidth authorities
were assigning weights. This happens on 2 different client computers
and one live Tails (obviously each uses a different Guard). I wouldn't
say it is now slow enough that someone wouldn't be using it, but it is
indeed slower than it was before (pre-self advertised weights).

I don't think it's a good idea to get back to self advertised weights.

On 8/5/2015 1:17 AM, Mike Perry wrote:
> Roger Dingledine:
>> On Thu, Jul 30, 2015 at 08:53:33PM +0200, nusenu wrote:
>>> Has this fallback happened before (=some experience on the
>>> potential impact available) or is this outage happening for the
>>> first time since the bwauths are in place?
>> 
>> Indeed, it happened a few times back in 2010-2011 when we were 
>> first rolling out the bwauths: 
>> https://metrics.torproject.org/torperf.html?graph=torperf&start=2009-05-06&end=2015-08-04&source=all&filesize=50kb
>>
>> 
but it's been mighty stable since then.
>> 
>> Interestingly, you'd expect a big bump in torperf response times 
>> when we switched to self-advertised weights. But there isn't
>> one: 
>> https://metrics.torproject.org/torperf.html?graph=torperf&start=2015-07-06&end=2015-08-04&source=all&filesize=50kb
>
>> 
> Some years ago, Karsten made a nice overlay of bw auth failures to 
> torperf data, which allowed us to see a 4-5X reduction in torperf
> fetch times while the bw auths were active vs not.
> 
> I just added a comment to 
> https://trac.torproject.org/projects/tor/ticket/16696#comment:3
> asking Karsten to repeat this visualization. That might be a bad
> place to do it, though. Might need a new ticket (or tickets)?
> 
>> I'm guessing this is because we have enough relays, with enough
>> capacity, to handle the current load adequately.
> 
> I'm wondering if the downtime in this case hasn't happened for a
> long enough stretch of consecutive consensus periods for it to
> impact the network. That might be one explanation. Spare capacity
> might be another.
> 
>> But that doesn't mean the current relays are useless.
>> Historically speaking, it means pretty soon more users will show
>> up, once word gets out that Tor isn't as slow as it used to be.
>> :)
> 
> I worry that the "capacity economics" involved here might not have
> the same properties as they used to, and that we might not see
> increased adoption as a result.
> 
> In particular, the switch to one guard makes it much more likely
> that a new user will pick a slow guard and this will cause them to
> have a horrible Tor experience.  With three guards, you had a much
> better chance to get at least one fast guard in that case, and then
> CBT could sort out which was which.
> 
> In my case, I usually pick my guards manually for ease of use with
> my firewall, and as a result performance is always very fast with
> the three fast guards I have chosen (I often get throughput
> 750k-1MB/sec for large transfers). In some instances where I have
> not selected my guards manually, Tor Browser is unbearably slow.
> Like really, really painfully slow. The whole time. Until I
> reinstall it.
> 
> This makes me think that the performance of people who pick guards
> from the tail is much much worse than the performance of the top
> guards, and this property likely is acting as a deterrent to
> adoption. If even a small fraction of users perceive Tor as totally
> unusable, the word of mouth is still going to be "OMG Tor is like
> SO UNUSABLY SLOW!!"
> 
> So long as this keeps happening, I suspect it is unlikely for
> people to rush to Tor because it is now faster.
> 
> I think once we expect most of the clients to have switched to 1
> guard, we should get some torperf graphs going for guards of
> various capacities, and see what the actual effects of this are.
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJVwUG0AAoJEIN/pSyBJlsRyUcH/jOkx+8YxBQMCAJyyHWtl6WJ
Ix8ItcJOkMry8Mt0pGrmlgwYQjmoP/jv9RzFMVNc60rKpSjFHxUk0YAyZfXB4Zhj
sX/ZfBdhcQv6hZZ431Iqp/D/GOdAVOGlk8XnKczddPXQc5kO+OY4pQKYV6Eotn2v
fOTuwy0pst5pcDvH/6ZTa52mN+DBrOTqlL7JY4Hx8BdWds2FpMvYWdP/Jk+GbE5m
/1QkfgRjox8sMnn+y+nbaswGjQ4y2EWjVSXU/TbJyam3XJHR1WDwrlYQma86JUGZ
Yu/u6VAyG6+JCk72bMD+ofO5yQmeo3ii2WhYTcF5H60N91p/6mKkPxOcm4Xr418=
=t/IX
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] do not run Tor client and OR relay together!

[s7r]

Hi,

Shipping tor-client and tor-relay as separate packages is the worst
thing we could do, since it's the same thing with just one config line
more or less. It will mess things up terribly.

We don't know that just yet, we are getting to fast from one thing to
another - wait until proper review over that ticket and we'll see what
needs to be done  / if something needs to be done.


On 8/16/2015 8:50 PM, Ana Lucia Cortez wrote:
> 
> On 16.08.2015 at 17:36, starlight.201...@binnacle.cx wrote:
>> Anyone who has configured a Tor SOCKS5
>> client to run in a 'tor' instance that also
>> operates as an OR relay should isolate the
>> client to a separate client-only process.
> 
>> The client function disturbs relay traffic
>> forwarding in a manner that lends itself to
>> confirmation analysis.
> 
>> See bug 16585, particularly comment 5 and onward:
> 
>> https://trac.torproject.org/projects/tor/ticket/16585#comment:5
> 
>> Perhaps read comment 10 first.
> 
> 
> It would be nice to have both installed as services by the deb-package
> or two different deb-packages for tor-client and tor-relay.
> 
> Apart from the fact that they run the same binary they are quite
> different to configure and setup.
> 
> Maybe that would help to make it easier to run relays and hidden
> services on the same machine.
> 
> ___
> 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] Calling for more Exit Relays

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

In the last 48 hours we went under the 'psychological' threshold of
1000 Exit Relays in the consensus.
Right now, Thu Aug 20 23:57:02 UTC 2015, we have:

6234 Running relays
954 Exit relays

I think we can improve this balance. Let's do it!

This is a call for everyone: Please run Exit relays, or if you are
running a middle relay turn it into an Exit relay!

I have been running high capacity Exit relays for a very long time,
and I tell you it's not a headache and it will not attract any
problems if you just take care of the abuse complaints.

During this very long time, 98% of the abuse complaints were automated
messages which can safely be ignored (fail2ban notifications,
portscans, web CMS plugins sending reports about http fetches, etc.)
and the rest were from very nice people who didn't know what Tor is
and how it works, but after explaining to them they actually liked the
idea - gives you a really nice feeling. Only 2 times I have received
email from law enforcement agents (which are just normal people like
us, doing a hard job) - a complete and clear explanation was all that
it took for them to fully understand and eliminate any doubt that the
server in question is somehow interesting to them.

Tor is _legal_ in all sane countries! We as a community are here and I
give you my word that me and others will personally assist, in the
measure and ways we can, whoever runs into troubles because of running
an exit, which is highly unlikely.

It is recommended to reject in your policy port 25 (it's not needed
and it will blacklist you for spam messages if you leave it open).
Allow all other ports, or use the reduced exit policy from
torproject.org if you want to allow only what is highly necessary.

Don't think any longer about it ;)
- - Email me directly any time if you need technical support in setting
things up, hardening the server or need a customized setup adapted to
certain conditions.

- - Email me directly any time if you have the funds needed to run a Tor
exit relay but don't know how to set it up, where to get it from or
don't want to rent and run it under your real name.

- - Email me directly any time if you need instructions about how to
deal with abuse complaints and short templates for replies.

For live chat come on IRC, OFTC network, #tor channel.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV1m+CAAoJEIN/pSyBJlsRhD8H/3NpZniYVIELenCvxKNKIEeR
J6hvSIwsAJUzlk+Hm5v74f7uzeXoLwA8z/FtzKCBVACOvUoCo1b4/2hF3wBMDfcw
CsSZC0AkkIdF+4ePSIsjAU8giOr2uXkCS9CSoRyDnIebmyx5RkSnFDXgTg6/QLJT
YJBuTrAA2anxqCHmqL9xHEDM40JhTMP6N6CR3aR4CCPkVOeELyyLTSgb637rZzUs
EuRkliktZifirhENxOHzvMVv4D4X60lXeSo1i347gdPwTGuNpiL5fPu+ET0E1sTh
Ol8Prvi6XP9yBojW7Up0q1y6083JkguLTbxQDomnqEYT7LCCqAFVBwdc1xWUdg0=
=kFIY
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Google Compute Engine rejected as relay?

[s7r]

Hi Greg,

I have forwarded the request to the relevant people. Please stand by to
get an update about it as soon as possible.


On 8/20/2015 5:17 PM, Greg wrote:
> 
> 
> On Wed, Aug 19, 2015 at 10:46 PM, Thomas White  > wrote:
> 
> I think this is from the Lizard Squad attempted (and miserably failed)
> sybil attack. The directory authorities will need to remove the ASN
> from the blacklist.
> 
>> If that's the case, then that was a year ago. Hopefully directory
>> authorities would be okay with removing the ban. Is there a process for
>> requesting that?
> 
>> Thanks,
>> Greg
> 
> 
> T
> 
> On 20/08/2015 06:00, Greg wrote:
>> Hi, I tried to spin up a relay on GCE a few days ago, and I found
>> that it was outright rejected with a message like "Authdir is
>> rejecting routers in this range". I don't have the IP handy now,
>> but I could easily get another ephemeral IP. I thought I came
>> across a thread saying that there was an attack on the tor network
>> originating from GCE, and that's why it got blacklisted. I'm not
>> finding that thread now. But is GCE going to be removed from the
>> blacklist? I realize it's not a very economical place to run a
>> relay.
> 
>> -Greg
> 

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

Re: [tor-relays] Does Setting Up a Bridge Relay Disable the Browser?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Thanks for this. But why do you want to run your bridge instance among
the same Tor daemon as the one handling Tor Browser?

If you are on Debian, install Tor package separately with apt-get
install tor (recommended you add deb.torproject.org to your
apt/sources.list file so you get the latest versions all the time -
see https://www.sky-ip.org/configure-relay-debian-ubuntu.html )

overwrite the torrc file with this:
ORPort 443
ExtORPort auto
Nickname <#yourdesirednickname>
ContactInfo <#someemailaddresshere>
BridgeRelay 1
ExitPolicy reject *:*

While you are at it, you might want to install obf4s4proxy package and
provide a pluggable transport bridge. (deb
http://deb.torproject.org/torproject.org obfs4proxy main) and add in
torrc:
ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs3 [::]:<#someport>
ServerTransportListenAddr obfs4 [::]:<#someport>



On 9/7/2015 9:11 AM, Kenneth Freeman wrote:
> This may be a naïve question, but I've fired up my 64-bit Debian
> box now that the nights are cool, and editing the torrc to
> establish a bridge relay borks the browser. I provide anonymity
> much more than I use it myself, but is the bridge relay copacetic?
> Thanks in advance.
> 
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV7SvmAAoJEIN/pSyBJlsR034H/j32IUGpjbSB8AIW6WNOWxPL
iNXGqS4KtUFPnPA8Ya6X9Wz3nEwPDl84F2OoiRsxoJ1dFp7DApoNnMtfHxeNVP5x
hsdV0c8ph0ttUt97Jng+JvWSJVGs5NEOU8Kmluthr0ZxUSUQimI+7l4imXs1JNN6
4BcsADrIOW1FExefG7itFXcARsBwr7kQD0MRZv8GLWF+vMmFiTGHRVNe5pYg+ii+
sTFQlWI9eAXAoWdwYmTUrZHQiPLrlmMFDFLk0nvKY+AjWseZL6mI/NiDAb8mwNua
awy2m4jQA1UHknj+H/cOEh0f+/HGm7vbUK7zhyKZ2R1sOO1ZNZP6cIizJkOQs2E=
=Nl0D
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Legal status of operating Tor exit in UK?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I am not from UK so I am also not familiar with the legislation there,
but running an exit should be perfectly fine.

Your ISP cannot "press" you to do anything! Only a govt. authority or
law enforcement authority or judge can legally press you to do
something ,and you really have to do it. The ISP doesn't have any
power over you, regardless, worst case scenario they can suspend your
service if they forbid Tor in their terms of usage and you have agreed
to them when you subscribed. But that's all.

The evidence of malicious traffic coming from your exit is a false
positive, and you should explain that to them. Your server does not
send any traffic of its own, unless not compromised, it just relays
anonymous traffic for Tor users (kind of an open proxy) which you do
not initiate, monitor or control therefor you cannot be held liable
for it.

On 9/8/2015 11:04 PM, Jonathan Baker-Bates wrote:
> I run an exit node with an ISP who initially indicated they would 
> not have a problem with Tor as long as I was transparent about
> what I was doing, and ran a sufficiently reduced exit policy.
> 
> They have now sent me evidence of malicious traffic coming from the
> exit. I don't think they've had any 3rd party complaints about this
> traffic, but they have expressed various misgivings about Tor in
> general. They now also want me to consider running Snort IDS on the
> outgoing traffic.
> 
> I don't intend to monitor my traffic. But it occurs to me I don't 
> know whether my ISP needs to be worried about it or not. The last 
> one wasn't, so why them?
> 
> I've asked the EFF about the legal situation in the UK, who passed 
> me to the Open Rights Group. They've not replied to my enquiry as 
> of three weeks ago.
> 
> So does anyone know of any reliable source of information on 
> running Tor exits in the UK? What would happen if my ISP pressed
> me to monitor my traffic, and I refused on legal grounds? I'm not 
> suggesting I actually do that, or that there are even any legal 
> grounds to refuse. In fact right now I'm resigned to closing down 
> the node if my ISP turns up the heat. They probably have me by the 
> balls.
> 
> But I'm at least curious, and can't immediately find any 
> information about things like public carrier status, or traffic 
> monitoring conducted by people like me when it's done in the 
> context of onion routing.
> 
> Thanks in advance for any help.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJV71h7AAoJEIN/pSyBJlsR1i4H/29sfK9UjOkQXmNwkC+nUMRn
AQBtmedG2pj0ZtBaDSeJrmcAzoTNrqOtWnW7X4zQMqdeudF0OC5f55Y6jv5qpX2w
/kE6C1f6+sbvAbQDNlNPkt45LlkChiqawQOBzowtnBkjYkRQ315lO0ofwTlSfeBs
OYG6CEURMofq1mRdT2lqe1QFPGI0aAUfxiB6eGVl7w5L3ldFq0OUJ7PzBqWuB0U8
vMjjoad5Phchn3k035UjefKoXfAho0NHr08NS4+3Gz8jTFbRUv4O3nfx8WQgi10y
BzSvU6jmoBZmMDy81dcAti74UQ55hDH9h1NmFxviwi3PHQPVCa09RmrsJNh9ZRY=
=2g/H
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Don't cap the speed if you have bandwidth limits. The better way to do
it is using AccountingMax in torrc. Just let it run at its full speed
less of the time and Tor will enter in hibernation once it has no
bandwidth left.

Example:
remove RelayBandwidthRate, RelayBandwidthBurst and
TokenBucketRefiillInterval or any other strange and unnecessary
settings you might have for bandwidth limiting. Add the following:

AccountingMax 96 TBytes
AccountingStart month 1 00:00

Search for 'accounting' here:
https://www.torproject.org/docs/tor-manual.html.en

Thanks for running an exit! More to come ;)

On 10/1/2015 3:33 PM, Dhalgren Tor wrote:
> Have a new exit running in an excellent network on a very fast
> server with AES-NI.  Server plan is limited to100TB so have set a
> limit slightly above this (1800 bytes/sec) thinking that
> bandwidth would run 80-90% of the maximum and average to just below
> the plan limit. After three days the assigned bandwidth for the
> relay is going up instead of moderating--looks like the measurement
> system has a problem in this case.  Just dropped the limit to
> 1650 to stay below 100TB with maximum load.
> 
> A good number appears to be around 65000 to 7, but 98000 was
> just assigned.
> 
> What can be done to extract proper rating from measurement system? 
> Tried setting TokenBucketRefillInterval to 10 milliseconds for
> more exact control but this has not helped.  Should an IPTABLES 
> packet-dropping limit be established?  Can the rating system be
> fixed?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWDSnkAAoJEIN/pSyBJlsRbjsIAMJy2FuqqF53oOPVm7DSVS8x
h6EPMGBhfMXBOVQdFMppv5VZhf92sLkUsSzN+OSQPY1l4uatXX6kalBxzdIRXCsT
rDeJ6EjdyR1ll2efamEhZOypkxmON5SsgCpMLs8WvKCDOGpCGkil52QMnVy7LpqC
yfVTRWiuShwegxebEus/gdWMvKlf6B8/3l2xgBbyKD2V1eGuEaGVlM2RzvwpBtg0
NnUFwFPYcFs3pcqZlX/k7bpdYyIDcwTz35zpGhUjCwJIyB8zrnmcz+LjPxtipLjg
q0Jd8EJNIJa9G7ttyO3QYo7UOF/jChplhvfyIuDJw2XwKRMbhwePdgMClAt0j3c=
=XU5L
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ouch, that's wrong.
"BandwidthBurst" and "BandwidthRate" refer to bandwidth consumed by
Tor as a client, e.g your localhost SOCKS5. If you are trying to limit
RELAYED traffic, as in sent and received by your relay functionality
you should use:

"RelayBandwidthRate" and "RelayBandwidthBurst" but these are an
inferior solution to make your Tor relay not consume more than n TB
per month. See my previous email, use "AccountingMax", checkout the
manual linked in my previous email it's highly customizable. Either
give it 23 TByetes per week, either 96 TBytes per month... as you like.

On 10/1/2015 3:48 PM, Dhalgren Tor wrote:
> On Thu, Oct 1, 2015 at 12:40 PM, Tim Wilson-Brown - teor 
>  wrote:
>> 
>> How did you set this limit? What did you write in your torrc
>> file?
>> 
> 
> was
> 
> BandwidthBurst 1800 BandwidthRate 1800 
> TokenBucketRefillInterval 10
> 
> is now
> 
> BandwidthBurst 1650 BandwidthRate 1650 
> TokenBucketRefillInterval 10
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWDS4UAAoJEIN/pSyBJlsRC50H/jTp1TWCKCFcYdbTEwX3sYtM
PYdM96IcuBCcfP3L5EpNCQj0HGWFjPPrzMWdB2/SsD/0x4Rz3rvXdAUl2cwHbQsj
Ys7h9dgfrGQUPpsqOSZNTBonROojLR0KYi2jHeceFsuypHKBnM/hWQrqVa8kY5Yz
IJoVAl92vfs1C2luJ5si+ZrfYOeDI72eLihBeC0cYpDTJNz1/j1afzeLaZkTbS5D
+A/vo8UfN/KHI5SqvSqi5qSXiOWwIkHWdAoX/at7TnvKVlTEGNE4FagyT23tFSdj
G9nf1/8N7eUeuKtKevwKJ3z5b+OEkfTxbGkB4+k5WvQla5Khy4j6wgLTylE80Go=
=om7E
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

You only mentioned the 100TB plan limit, this is why I suggested
AccountingMax. I couldn't have guessed you are talking about some
other policy limits.

The consensus weight is your bandwidth measured by the bandwidth
authorities. This is used by clients to calculate your relay's
probability from being chosen in a circuit. If it's big, yes of course
it will attract more clients. If you rate-limit it in torrc, the
bandwidth authorities won't be able to measure more than what you are
offering. Maybe use this:

MaxAdvertisedBandwidth N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits

If set, we will not advertise more than this amount of bandwidth
for our BandwidthRate. Server operators who want to reduce the number
of clients who ask to build circuits through them (since this is
proportional to advertised bandwidth rate) can thus reduce the CPU
demands on their server without impacting network performance.


On 10/1/2015 4:22 PM, Dhalgren Tor wrote:
> On Thu, Oct 1, 2015 at 1:10 PM, Tim Wilson-Brown - teor 
>  wrote:
>> 
>> Can you help me understand what you think the bug is?
> 
> Relay is assigned a consensus weight that is too high w/r/t rate 
> limit.  Excess weight appears to be due to high quality of TCP/IP 
> connectivity and low latency of relay.  Result is overloaded relay
> and poor end-use latency.
> 
>> Is Tor using more bandwidth that the BandwidthRate?
> 
> No, but relay is loaded to flat-line maximum and clearly is
> attracting too many circuits.
> 
>> If so, this is a bug, and should be reported on the Tor Trac.
> 
> Not interested in doing that.  Looking for a way to get it work.
> 
> If the relay stays overloaded I'll try a packet-dropping IPTABLES
> rule to "dirty-up" the connection.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWDTZZAAoJEIN/pSyBJlsRRXkH/2IpuxK6s0KKzq7fEMBJO+/I
/uiL2/6WGcT7L/aaFQqigqjtQ3eQpAXY6CVV9KRqfVukhjjqBTrauZ+WvfYhz0dJ
vWTeyOfpfEwMp8J3XYNrd6noBfgCR9oX3aBE9K+RRPhTGWYLjxnleAOh22t5AeA3
dYG+XoG27bKYnf4sj8y9+kibiId8Guroh54Y6F8QT3lF4j1C2nPb24y1cHn0atEG
ONWFeM8oVNGuliO3T9z5JkIhxBvOiK3DgGDM0jV1+cf8GAUDHGU4xYSX6vBlqrTc
r1aWTDuqVE98tLA38WyjSHc+a3+dfDBiJcpr0h7dFXT1GrjipYkO5VLkBPgsSjI=
=mWbS
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] why are some exit IPs missing from Exit IP DB?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Don't know if we can call it a bug.
It appears to be working, real exit IP addresses are discovered.

Check for example:
PrivacyRepublic0001 178.32.181.96
PrivacyRepublic0002 178.32.181.97
Both exit with IP: 37.187.129.166

It actually works very good, when you connect to check.torproject.org
it says OK > you are using Tor.

Also, Exonerator (and onionoo) knows how to handle it too:
https://exonerator.torproject.org/?ip=37.187.129.166×tamp=2015-10-10

It will even return the results on atlas:
http://atlas777hhh7mcs7.onion/#search/37.187.129.166

On 10/11/2015 2:27 PM, nusenu wrote:
>> Occasionally I run into a relay such as
>> 
>> Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4
>> 
>> OR ip 178.33.157.6
>> 
>> exit ip 31.7.58.37
>> 
>> Where the egress/exit IP source address is not found in the Exit
>> DB, shows up negative on ExoneraTor.  TorCheck in glaring unhappy
>> RED spits
>> 
 Something Went Wrong! Tor is not working in this browser. For
 assistance, please contact h...@rt.torproject.org.
>> Does anyone know why this happens?
> 
> 
> Such "non declared" exit IP addresses (OR IP != exit IP) are found
> by exiting through every single exit relay to detect its exit IP.
> 
> Since exits can change their exit IP address at any time the exit
> list can never be 100% accurate by design.
> 
> https://collector.torproject.org/formats.html#exit-lists
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWGuaQAAoJEIN/pSyBJlsRgLUH/14pO7pF0KTV7o8Mr4uBYc5R
VB8L59oMNxkwMn+3TcQHOp3ILR0iEIEH1p6CWdzL2mcrhQ6Nar6DMbStJl9A7Czg
+Ad7y2luQI54CzYs2tBlGUSrD1RNjUTbcTJFSekvLskYK0vpMYjkQfAWeMUJvce6
PECJ2omhlxlCgO1cdaL7yBu/F3t/6+paVF0tOezTTr4G3FGx3sQl21hdnadmKhHT
9hn03JJTH7XbLtHutkEpKULNHrwiwQ78Hvrk1wbvaXyE3o8DHR7v8vf/N4sizhxR
zGXzhWv2vPSHrTrjkUZLG+va17bN/9cNtl1X7KQ5udblx8A/KpDPjCj/MGVTOyY=
=BXoQ
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] why are some exit IPs missing from Exit IP DB?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I know those aren't related to the relay in your report, I only
provided them as an example that it works sometimes (the relay in your
report is in the same datacenter with the ones in my example so the
networking setup could be similar). Sorry if the email looked like I
misread the post. As I said, maybe this is just the limitation of the
exit-list by its design.

Good that you've opened a ticket on trac - maybe there's something we
can do about it.

On 10/12/2015 1:53 AM, starlight.201...@binnacle.cx wrote:
> You are checking the wrong IP and not reading the post.
> 
> 
> At 01:45 10/12/2015 +0300, s7r wrote:
>> Check for example: PrivacyRepublic0001 178.32.181.96
> 
> 
> At 13:29 10/8/2015 -0400, starlight.201...@binnacle.cx wrote:
>> Occasionally I run into a relay such as
>> 
>> Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip
>> 178.33.157.6 exit ip 31.7.58.37
>> 
>> Where the egress/exit IP source address is not found in the Exit
>> DB, shows up negative on ExoneraTor.
> ...
>> MANY EXIT NODES HAVE IPS THAT DIFFER FROM THE OR IP AND WORK
>> FINE. . .

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWGu9UAAoJEIN/pSyBJlsRSeYIAKCVs2tTTA1oN/bHShGZXvN+
wwZZ05ISGNIMvd/3EKG/qxm/lxygyOoDqNDCWNwTXh3v3FkoYKtTkttaHzeniSpm
ft4e1RLq62mFAl79WnNOPMhjATaP+fZc/gepRfcFYqIUTpaNLtomn3bltOvfNi7J
cTroGn+dA3ad4/U/KWkUV7ztDEG21dPqbdIm7ZVIKjapO2z19o3tPwkN+ldPmSnS
eNXVJVQDrEOr5qCwX4cDSupjIrbKY21eAynjhCyn8tvjs9Wy7Vhxbd18/fNv2YyJ
yU8/lmP+3o3bV1lBnYvRwf/haQ62y9AOPUkMv4fq/iB3qrPv3Eo+PN8wLP/S/qk=
=TI8B
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Faravahar messing with my IP address

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Unfortunately this is not the first time we see this, and it did
happen before Faravahar IP address change and before it was
experiencing very high latency (
https://trac.torproject.org/projects/tor/ticket/17338 ).

See:
https://trac.torproject.org/projects/tor/ticket/16205#comment:3
 ~5 months ago

Maybe the bogus discovery of IP address change explains this also:
https://trac.torproject.org/projects/tor/ticket/15500

There is obviously something strange going on. In addition to what
teor said, the operator should also find out exactly what kind of
anti-DoS protection system is used in that datacenter. Maybe something
upstream feels attacked when Faravahar is receiving a lot of incoming
connections and behaves in a way that is incompatible with Tor.

On 10/23/2015 1:55 PM, teor wrote:
> 
> On 23 Oct 2015, at 09:30, Green Dream  > wrote:
> 
>> I see this from time to time as well. Here's another example:
>> 
>> Oct 17 23:02:44.000 [notice] Our IP Address has changed from 
>> 52.64.142.121 to [CORRECT IP]; rebuilding descriptor (source: 
>> 86.59.21.38).
>> 
>> 52.64.142.121 appears to be an instance on Amazon's EC2. I don't
>> run any nodes on EC2. 86.59.21.38 resolves to tor.noreply.org 
>> .
>> 
>> I'm unable to find any occurrences of this happening from
>> Faravahar, however the issue seems to be fairly common. What's
>> going on?
> 
> We've had one suggestion so far: That the iptables forwarding rule
> from Faravahar's old address might not be preserving the original
> source address.
> 
> Another possibility is that authorities running directory caching 
> proxies are re-using the X-Your-IP-Address-Is header meant for
> other clients, rather than generating it fresh for every client.
> 
> A third possibility is a bug in the tor authority code, which sets 
> X-Your-IP-Address-Is to the wrong IP.
> 
> Tim
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWKswcAAoJEIN/pSyBJlsRH84IANXDcPlIfikR4IF1QWf/fXcU
YhESUQmI6CoD1Ik3Bbcfx0OA4UWZe+HsUXJlz0X8rqRPm7sQNLge5OaMVxGNMnsx
Sy4nxIpfA3Q6hA30bqTXFvEBsUCYRAaa/etw/skNIoa8XbrXvXN5+7mIBg3Ljnf3
6PfzuNYNvcllYF2iqYP42pnI9V5SzAHZCUSqVNdWiaEt/vgR6JDRiT8IoHibg7pC
SZPvltqUOjNbczIfBmlSUvTbXD6yxvH4Ewf8WF6z9QstymSjHimu6br0ev8Cs1rR
xo/e278AT4sx+fPeVme1OjcMYfYavwMl8r4/tkq9DQYLExI/byovoBcN4qO9Jks=
=3EuD
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] too many circuit creation requests

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Thanks for running a relay. Yes, the raspberry CPU is kind of slow for
Tor, especially if you are using the old raspberry-pi with arm-v6 cpu
and 512MB of ram.

RelayBandwidthRate and RelayBandwidthBurst settings are ok, you might
want to increase them since the raspberry should be able to handle:
RelayBandwidhRate 600 KB
RelayBandwidthBurst 1200 KB

Also, your consensus weight is currently 82, so you should not
experience many circuit requests from clients building circuits
through your relay. So, I think you are right and it is a result of
your HSDir flag (you are selected as HSDir for a popular hidden
service probably).

This makes me wonder if we need to reconsider the criteria for
assigning HSDir flags, a relay with a consensus weight of 82 should
not be eligible for this flag.

Anyway, can you remove DirPort from your torrc, only allow ORPort and
restart? I think we don't assign HSDir flag to relays without DirPort
set, so try this  - it is also helpful for you, since you have really
scarce CPU resources you might want to use them all for Tor circuits
and not for mirroring directory data. Let me know if this fixed it for
you.

On 10/24/2015 6:09 PM, trshck_...@riseup.net wrote:
> Hi all,
> 
> I set up a new tor relay named trshck using a raspberry pi a few
> days ago.
> 
> All was going fine until early today, when a lot of warning have
> started appearing in the log file:
> 
> "[warn] Your computer is too slow to handle this many circuit
> creation requests! Please consider using the MaxAdvertisedBandwidth
> config option or choosing a more restricted exit policy."
> 
> I've looked up this message and found some comments but nothing
> clear about how to solve the issue. I think this can be related
> with the recent acquisition of the HSDir flag.
> 
> The relay is not configured to be an exit node.
> 
> The number of open circuits has greatly increase in the last few
> hours:
> 
> "Circuit handshake stats since last time: 4860/4984 TAP,
> 228464/229242 NTor."
> 
> MaxAdvertisedBandwidth is not set, only:
> 
> "RelayBandwidthRate 200 KB RelayBandwidthBurst 300 KB"
> 
> What do you advice me to do?
> 
> Regards,
> 
> Joan Terrassa Hacklab
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWK7U0AAoJEIN/pSyBJlsRFmAH/084psmxE79WwBrErvjNZ2Fh
V/vSq3USiKpNyDuj+YDePXGhlYpGFVVQl2Amt3RJUkJ+9BIDAx4DvGuo5xkIRcN9
7MEOe08POJYnOtv+mjJfIrSoUid3D0lLWpuhnHS1v5lWFhS9I6q6V5/ORHSzJXOk
s9sgyFEVMeEOT+gBLWOizUPqQKvU/XcNrcCM6ganv/u6CQHhXlxc4oNCPbjDTOHX
i1amrYw0MpwyOFEuZr1oUiOHY3+0fyB06gr1UFb6xOI9qvepqZuP1GV/7nIJOFHN
fl91AsqINPllpaJufZ13TjRpaLhMouLnjD+f93Usn6fwr7g538/gwCMFGCtB1LQ=
=OAnm
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] too many circuit creation requests

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I have checked on atlas and your HSDir flag is gone, so if those
additional circuits where HSDir requests, they won't appear any longer.

However, keep in mind that this doesn't happen immediately. Some
clients might still use the old consensus document in which your relay
had HSDir flag, and only find out it's no longer a HSDir after the
circuit has been established so the load on your raspberry will still
exist. Give it some time and it should come back to normal in few hours.

Also, is there anything else on that raspberry which could consume
cpu/ram/bandwidth?

On 10/24/2015 9:23 PM, trshck_...@riseup.net wrote:
> Thank you,
> 
> I've tried:
> 
> DirPort 0 HidServDirectoryV2 0 RelayBandwidthRate 300 KB 
> RelayBandwidthBurst 600 KB
> 
> and restarted.
> 
> Now it still has 100% CPU and about 3500-4000 inbound connections.
> The log is full of the same warning.
> 
> Buying some equipment is a possibility. I prefer miniature
> computers because of their low consumption. What would you
> recommend?
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWLDjYAAoJEIN/pSyBJlsRqpAIAMcMq7iX+Kz5yc22IVcyGKyN
Mr25WTuScajxw4UpWJJwuXeW3JZ3z0pWiNpzD8cCU6xCPHC16gbGcAbRflgauqWW
z+r42kJ3XUO4prTlOijd2fsM3eWeoVb6OxBoTR6HQfe09QMGShszc9ybWnFx99HL
xDfVOzZzaZJTmYZzkUSxFuG+ViYjJS1UN9chxk3C7b/HgPjdM8OtE1gxb7CHR2R/
S8FR4BYjESct/E6zaNsiTaq35yz5aHTXqAF6vqahMMEccTGvakKeraSPWmmtR4SN
wJdjerXMJqCLJppC/O6JJUyzRXdApal17RGX/RQMec7dM5YY6PNvs46WnAkNyW4=
=sYM3
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Limiting Bandwidth

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Thanks for running a relay. I recommend adding these lines in your
torrc file:

 AccountingMax 1050 GBytes
 AccountingStart month 1 00:00

On 11/12/2015 12:59 AM, Billy Humphreys wrote:
> 
> Hi all, does anyone know how to make a tor relay only use x
> bandwidth, then stop? I have a 1100GB/month max limit (100GB free)
> and I don't want it automatically suspending. Any ideas? Regards, 
> Billy.
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWQ8rNAAoJEIN/pSyBJlsR1GkH/jr+lGGxo6O0Yj8Sx0Qp8ry6
mYJu9aCm1+u+oowDX3JOXnLKE5gMCC07aFEj4e/27mHliUNUkMOrrl7GM1ogYzdJ
MiQkGGxrFJS5DV6gdaB7LwaD8S425XIf/OzyoSaI9N86uIOx5EoMW7tfW6VDLzpQ
lGh9x9C6242H4alvspVHxjsbW9kEoIZVK8btVJFLTpqGNTu/v3fCPIlLF+/lgpIc
DasO7HkLYLdltsFVVbjujFFY1pMKwbiD0zQzCJN2qP2uPwvH/wfJ/tnhMiIP+iZQ
Vk8EvFSoZ4g0eu2rFlpWeIPHq/sM9ED5HODuup8uPRZpAALV0AU5vZYnAKeBhDI=
=A7Le
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

The estimated extra load looks good, it shouldn't be a problem.

Are we entirely sure we want to hardcode a static weight for each
fallback directory relay? I know we require it to be stable enough but
sometimes the weight assigned to a relay is outside the control of the
operator (more relays are added to the Tor network so consensus weight
distribution changes, the relay gets DoS-ed and becomes slow at the
next measurement).

If all the relays eligible for being added as fallback directory
relays are required to have a big enough weight, this means the
estimated extra load shouldn't be a problem for neither of them. In
this case how bad will it be if we do not hardcode a static weight and
give equal chances to all fallback directory relays to be selected by
new clients?

As you said on irc, a client will try (maybe 3) fallback directories
before giving up and going to the directory authorities.


On 12/20/2015 3:37 PM, Tim Wilson-Brown - teor wrote:
> 
> With 100 fallback directory mirrors, up to an extra 50 GB per
> fallback per month. (This is my estimate of the maximum extra load,
> averaged across 100 fallbacks. But client consensus downloads will
> actually be distributed by the fallback's consensus weight, so
> larger relays may use more.) I suspect most fallback directories
> won't notice the extra load.
> 
> Here are the details:
> 
> At the moment, new Tor clients contact a directory authority to
> download their initial consensus.
> 
> After we release the fallback directory feature, new clients will 
> contact a fallback directory mirror to download their initial
> consensus. (Bridges will also contact fallback directory mirrors,
> as they are designed to behave like clients. Most relays will
> contact an authority.) Clients will choose a fallback using at
> random, weighted based on their consensus weight.
> 
> If a client is on a slow, unreliable, or censored connection, they
> may contact several mirrors before they get a successful
> connection. (However, regardless of the number of connection
> attempts, the consensus download only happens once.) After the
> initial consensus download, clients will choose from the full set
> of directory mirrors in the consensus.
> 
> We expect that most clients will already have a consensus, it will
> only be the new installs that use a fallback directory mirror. So
> if you take the download counts for the new version of Tor Browser,
> multiply by about 1.5MB (the size of a microdesc consensus), then
> distribute that by consensus weight over the fallback directory
> mirrors, that's the extra load we expect to place on each fallback
> directory mirror.
> 
> Alternately, if you take the bandwidth that a directory authority
> uses to serve consensuses to clients, and divide by 11, then that's
> how much we expect a fallback directory mirror to handle on
> average. (There are 9 authorities, and we hope to have 100 fallback
> directory mirrors.)
> 
> Unfortunately, I don't know the number of Tor Browser downloads.
> And while I can see that the authorities use 110 - 230 KB/s of
> bandwidth[0], I don't know how much of that is client consensuses.
> 
> If we assume that the entire authority bandwidth is used for
> client consensuses, then I would expect that a fallback directory
> mirror would use: 110 - 230 / 11 = 10 - 21 KB/s additional
> bandwidth, or an extra 26 - 54 GB per month on average, distributed
> by consensus weight.
> 
> It's worth noting that the entire Tor network already uses 1Gbit/s
> to serve directory documents[1], and first-time downloads for new
> clients are only a fraction of that. So I suspect most fallback
> directory mirrors won't notice the extra load.
> 
> If you're interested in some further background, the original
> proposal is at [2].
> 
> Tim
> 
> [0]: https://globe.torproject.org/ [1]:
> https://metrics.torproject.org/dirbytes.html [2]:
> https://gitweb.torproject.org/torspec.git/tree/proposals/210-faster-headless-consensus-bootstrap.txt
>
> 
> 


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWdsFzAAoJEIN/pSyBJlsRCTsIAIe1rq9wMejw+iUzAygNo04/
qpVfbupTvCe0CcbbadAEndpboKQGVDgXSTrj7fx59DC0oQcKvOlpjyKin13xxPoy
HPV2ClurHJD2PrM7p4ZUSHhSkwL2PBQyO9X3or+RXiSeqy1E+mLEyjOT9ckjawX3
6hgLm7VD9Jj2+z2GRLp8caXjfNmIb4trYZ1G1PF/AKQdpGJhIAgOHILsuRiXI9EU
rFcpchYnXSksSfG9tZCVcQR3dHB6cejTIFpWMijdoLtmdy+CeDumwJa5C5CK1WCX
ncERnai+KFFOQZZx3s8UyzaU8Lyk+spGL5tt5jQ8qaVPv5muKwvoK/RyzgMmto4=
=XhXY
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor not reading medium-term signing key.

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

Let's recap (hope I am not missing something):

a) you make sure master_id_secret_key is available in
/home/[user]/.tor/keys
b) you run # tor --keygen and provide the correct passphrase
c) you *move* the newly generated ed25519_signing_secret_key and
ed25519_signing_cert *FROM* /home/[user]/.tor/keys *TO*
/var/lib/tor/keys or wherever your Tor datadirectory is (depending on
your OS / distro) and reload or restart Tor. You don't need to shut
down Tor while you use --keygen, you can only reload (HUP) or restart
after you've moved the new key and cert.

and you still get the same notice that the medium term signing key is
going to expire soon?

If yes, can you let me know other details about your setup? Do you use
a SigningKeyLifetime parameter in your torrc?

Also, the directory doesn't need to be /home/[user]/.tor/keys if you
are willing to pass it with --datadirectory argument (Tor will just
need write permission in the target folder):

# tor --datadirectory /some/path --keygen (the master_id_secret_key
needs to be inside a keys folder in /some/path, eg:
/some/path/keys/ed25519_master_id_secret_key).

The new medium term signing key and cert will be saved in the same
folder and you have to manually move them to your working Tor's
instance datadirectory folder as explained above.

We are working on making this simpler by allowing to manually set the
master id secret key path and ask for a different output folder for
the created files.


On 1/4/2016 9:53 PM, 12xBTM wrote:
> So my medium-term signing key expires tomorrow, and Tor notices.log
> is all up and down about:
> 
> Jan 04 19:22:46.000 [notice] It looks like I should try to generate
> and sign a new medium-term signing key, because the one I have is
> going to expire soon. But OfflineMasterKey is set, so I won't try
> to load a permanent master identity key is set. You will need to
> use 'tor --keygen' make a new signing key and certificate.
> 
> Now, that's great and all, so I tossed my master_id_public_key and
> the master_id_secret_key_encrypted into the folder they were
> originally generated in, which is:
> /home/[user]/.tor/keys/ed25519 Turned off Tor, ran "tor
> --keygen" Gave my password. It generates a new signing_cert and
> signing_secret_key in the same directory. And now, no matter what I
> do, Tor keeps giving the same notice over and over again that the
> keys are expiring.
> 
> The documentation for this feature is slightly lacking. So, if
> anyone knows what I'm doing wrong, that'd be very helpful.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWit+iAAoJEIN/pSyBJlsR7d0IAICb4VKb3nlTJF1ZTekfgvy9
dP10RvZ6sLMgdvdPg3flN+f2ApUgMmxDj+CpK06GUEHdVM9w0fPQiP5I8ECcCw/Z
bRYaEq5hZ82DUzf8ISMSBKD7uD6cwJ1ja8R29+hGYFpnsK2Cxb9Dz+Rp+4VjGpfp
fTWD/MfVdOMU9SVvG4G2JH62pATx8DyUNiGjmJ3VRlJ3E//r6hgd1dKNtIk5p7BF
f+RpdkPXnA6fOqHIjUJYztC5QX/q4BwzhAUp3Jvs+pK42q18+pdGL8wPnmi0/NWb
ZbiSKUDtCeZBEDOR6D9pfMIqJMdCQd8SEN1barq0135fb6SVevxN+gSJYrHwgcs=
=ZMga
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor not reading medium-term signing key.

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 1/5/2016 12:13 AM, 12xBTM wrote:
> Now I'm getting permission denied, still out-dated key, and
> missing master_id_secret_key errors, which are unsurprisingly
> fatal.
> 
> Jan 04 22:41:33.000 [warn] Could not open 
> "/var/lib/tor/keys/ed25519_signing_secret_key": Permission denied 
> Jan 04 22:41:33.000 [notice] It looks like I need to generate and
> sign a new medium-term signing key, because I don't have one. To do
> that, I need to load the permanent master identity key. Jan 04
> 22:41:33.000 [warn] We needed to load a secret key from 
> /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't find
> it. Did you forget to copy it over when you copied the rest of the
> signing key material? Jan 04 22:41:33.000 [warn] Can't load master
> identity key; OfflineMasterKey is set. Jan 04 22:41:33.000 [err]
> Error initializing keys; exiting
> 
> Which is funny, because the [user] has permission over 
> signing_secret_key, and the ed25519_master_id_secret_key is totally
> in /var/lib/tor/keys/.
> 
> 
Yes but for security reasons we usually run Tor as a different user
than [user]. In Debian for example it's debian-tor in FreeBSD is tor_

So:
# chown -R debian-tor:debian-tor /var/lib/tor/keys/*

if you are using debian, if not substitute debian-tor with the user
running Tor on your system.

Retry the steps in my previous email with this additional step finally
and see what happens.

> 
> At this point, I just disabled OfflineMasterKeys because there's
> just not enough information available for me to go about this. If
> you know of a way to completely regenerate signing keys, master
> keys, and whatever other keys I need besides the one for my
> fingerprint, that'd be nice, because I'm fairly certain things are
> completely screwed up now since Tor can't find or access the the
> signing_secret_key or master_id_secret_key. I'll be sure to
> implement that key regeneration in a week or so when I can correct
> the keys on this node, until then, I'll leave this exit node off
> until I'm sure it's using valid keys, because there's no point in
> having a faulty exit node.
> 
> secret_id_key, secret_onion_key, and secret_onion_key_ntor weren't 
> touched (I think). So it's the others keys I need to fix.
> 
> I'll try this OfflineMasterKeys thing when more operational
> information is released about it. Because, not only do I not know
> what I'm doing, I don't even know what it does at this point.
> --keygen on the master key and writing it automatically to a [user]
> directory made it property of [user] instead of debian-tor. Also,
> what is master_id_secret_key_encrypted used for if Tor says it
> can't use an encrypted master_id_secret_key?
> 
> I'm absolutely a linux noob, and I know that's not helping.
> 
> 

Why do you use offline master key in this case and not simply allow
Tor to work with the defaults? Usually the offline master key
functionality is for those who have time to attend to the relays and
periodically renew keys and also know how to do it.

OfflineMasterKey needs no more information than it already provides:
tells Tor never try to generate or load master id secret key.

Hint: when you run # tor --keygen in console the command is run as
[user] and files are stored in home/[user]/.tor/keys and are owned by
[user].

The Tor instance runs under debian-tor, so debian-tor needs access to
/var/lib/tor . Of course [user] also has access in /var/lib/tor
because it's above debian-tor most probably in your setup. But when
you move the signing cert and medium term signing key from
/home/[user]/.tor/keys to /var/lib/tor/keys they are still owned by
[user] and debian-tor (Tor instance) can't access them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWiwBaAAoJEIN/pSyBJlsRQOgIALTwGY37fPTrqtAjfBU/+FCZ
6KHw0Mcd6IB9nnI+XN+ShsggIMdtESGFiyui5Vez1T2wFgXvBfyW6WNELTrFsMBc
pykU+b4Lhkq6eIRVyXPLaplK2SqZlcPfF2rlI7opXnW+bIKKoNfqztU97AHOQEMD
AyOSjG3gkOo9n2cRyNpcZTDrPZ2lPoV5klhpL3L+YbMCygpnUNhyOVB1ih1l3jhp
4MnDTwa/edwvPFqSBblo9QKVQdnvIMxE8EEAXEUZ2rRSXN+9zh9P/5AgfGHw7sSw
arsQ2tdmdhRcoKZN1cCEA/Ud4WrUkxT3K6lw/9XiuP50laeFxnsisj9+j+bNZQg=
=9vha
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Why is Tor trying to check the wrong ORPort/DirPort addresses?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I have experienced exactly the same problem with similar networking
configuration and reported it here:

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

It's being worked on.

In your case, however, it appears that the Address argument isn't
working and we need to find out why. I only want to highlight not to
confuse Address with OutboundBindAddress which are separate things and
both needed. The only difference in your setup vs mine is the Debian
version (you are on Jessie, I was on Wheezy). Please retry with these
lines in the config:

ORPort 50.7.178.99:444
DirPort 50.7.178.99:83
OutboundBindAddress 50.7.178.99
Address 50.7.178.99
RunAsDaemon 1
[add your other required config lines such as Log notice file and
DataDirectory]

Do this for every instance and substitute the IP address and ports per
each one. After you make sure the configuration files for all your Tor
instances contain the above data do what teor asked and provide the
relevant section of the debug log.

On 1/9/2016 12:42 AM, Tim Wilson-Brown - teor wrote:
> 
>> On 9 Jan 2016, at 01:22, David Tomic > > wrote:
>> 
>> I got a little bit excited a few minutes ago when I discovered
>> https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt
>>
>>
>> 
However, that doesn't appear to have made any difference either.  For
>> some reason the reachability tests are still insisting on trying
>> to connect to .102.
> 
> Tor should only fall back to using an interface address when it
> fails to parse the Address torrc option. So you may have found a
> bug in the tor function resolve_my_address(). (Tor should also
> probably pay attention to the address in the ORPort line when
> testing reachability, but that's a separate issue.)
> 
> Can you please choose a tor instance with this issue, and provide: 
> * The exact Address, ORPort and DirPort lines (or the entire torrc,
> if you're able) * The debug-level log output for the first and
> second calls to resolve_my_address() * there will be a lot of
> output here, and it can reveal sensitive info - don't leave debug
> logging on all the time!
> 
> Tim
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com PGP 968F094B
> 
> teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F
> B5A9D14F
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWkE8uAAoJEIN/pSyBJlsR54oH/2UqOIL4UugD5024s9q1ZEw4
lp+K8c3vGcgLgI/l2Nm0hI95X1RwX6+bNjmtVpw1oC9Cc4wIM21ngrU9kRiveLZc
scoYj+N8bBoyMTpXG01mWEKT/4H5rmvOYdoxYlL5+7tMtGdjGKJ3BigZSk2+D8n+
b1Z5zszr2WElGIF9WNoJCD8iFqCLGUDSCHB0ZJ/+tPqKYqy4ffQT4dyQjscqh26u
6KwxrdnU4GkOYjtW5QYK1LoIvvwVKjjLUSNlTb3D9P6IljzQVfhcDkLw8j0Ksl4r
bwG4dfgZ84dteXfK15hGmqidVAC1hJm4+zxRGJ+FrRT7S9k66r7u8Wl0zfw9Fek=
=G5K3
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Nameservers fail and come back at the same time?

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

This isn't new, and it happens with any DNS resolver (ISP resolver,
Google or OpenDNS, custom DNS resolver on localhost running unbound or
bind, etc.).

I have experienced it on all the exits I ever run, it's the most
common warning. There's a ticket for it opened by me:

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

When I opened the ticket, we thought it may be a libevent issue; that
makes the nameserver look down while it is not, but see comment 6 in
the linked ticket - that might be a cause also.

In the mean time until we resolve this just keep the exit running with
a localhost unbound or bind resolver and don't use Google or OpenDNS
resolvers. It's best that an exit relay runs its own resolver.

On 2/1/2016 5:46 AM, Tristan wrote:
> After sending tor a HUP, I now have errors from OpenDNS and Google
> DNS servers. I opened a support ticket with the provider to find
> out how to use their provided nameservers. Looks like I just need
> to keep fiddling. At any rate, I'm still getting plenty of traffic,
> and the servers come back almost instantly, so it shouldn't be
> making too much of an impact.
> 
> Thanks for the help!
> 
> On Jan 31, 2016 5:41 PM, "Tim Wilson-Brown - teor"
> mailto:teor2...@gmail.com>> wrote:
> 
> 
>> On 1 Feb 2016, at 10:38, Tristan > > wrote:
>> 
>> Well, my VPS nameservers are domain names, not IP addresses, so
>> I can't use them directly. In the meantime, I added Open DNS to 
>> resolv.conf, but I still get errors from Google DNS. Do I need
>> to reboot to apply changes to resolv.conf?
>> 
> You likely need to send a HUP to tor to get it to re-read your DNS 
> configuration.
> 
> Maybe Google DNS is not reliable from your location, so you could 
> put another name server first? Or perhaps investigate resolving
> your VPS DNS manually, then using their IP addresses as well?
> 
> Tim
> 
>> On Jan 31, 2016 3:27 PM, "Tim Wilson-Brown - teor" 
>> mailto:teor2...@gmail.com>> wrote:
>> 
>> 
>>> On 1 Feb 2016, at 08:19, SuperSluether >> > wrote:
>>> 
>>> I'm not sure how many DNS servers are configured because I 
>>> never configured them. I just installed Tor and edited the 
>>> torrc file with my port, exit policy, and bandwidth options. 
>>> Where would I add/configure DNS servers?
>> 
>> Typically, by editing /etc/resolv.conf. But some platforms
>> automatically generate it using the files in
>> /etc/resolvconf/resolv.conf.d/
>> 
>> It should be fairly straightforward, if not, search the Internet
>> for a HOWTO for your platform.
>> 
>> Tim
>> 
>> Tim Wilson-Brown (teor)
>> 
>> teor2345 at gmail dot com PGP 968F094B
>> 
>> teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F
>> B5A9D14F
>> 
>> 
>> ___ 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
> 
> Tim Wilson-Brown (teor)
> 
> teor2345 at gmail dot com PGP 968F094B
> 
> teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F
> B5A9D14F
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWsNTyAAoJEIN/pSyBJlsRyRIH/Rld4INBEbLR8FMCYMvhNbi8
b9kUSzh5s44mfZCf5DG/zBKPiEqGoZZxiV6R4BuNBYL6VnuxrDSEm26D/U2NFO7m
FPO4hbLpjej40piR+2q9FHwWKOmJgWjKq5nql1qRviVmX4fPXeQJ8UzT+Ue/wCKb
4xRtasaSdJY12SuaseLOVKDhFZqBWzn7BFnpMaRDx42MjJpq82OFNEk0Ew/TW1ii
TNzRNMEBFFlNAgh6lEbg9UIhvJQhF9RFItEPaahxudfiHGgCitf0Zj7XJRt64B9g
Ca0uBMbFBPMTNnKzNnvfnw1Sg6zBsRa0XUuAVwFJlAy6jrFGkVlSTbIH2nZpnLk=
=3Fue
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Issues with offline master key functionality

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello - see inline

On 2/3/2016 3:49 PM, Riccardo Mori wrote:
> Hi everyone,
> 
> Two months ago I decided to try the new ed25519 key introduced in
> Tor 2.7 with OfflineMasterKey set so I can keep the master key in
> a different place and just upload the medium-term signing key every
> month. Last month everything went ok: I renewed the key and Tor
> accepted it. This time instead after generating the new signing key
> with
> 
> # tor --datadirectory path_to_my_master_key --signingkeylifetime
> '1 months' --keygen
> 

Why do you use such a value for SigningKeyLifetime when the default is
30 days already? You can just skip --signingkeylifetime and have
medium term signing key valid for 30 days (1 month). I am not totally
sure *1 months* is a valid argument here (could be, not sure) - why
not the default 30 days or more than 1 month?

Your problem is kind of strange so need to make sure of some things,
apologies in advance if the questions seam too obvious. Before
answering to all these make sure you try without --signignkeylifetime
or with other argument than *1 months* like 2 months, 6 months, 10
days, 30 days, etc.

- - path_to_my_master_key is the path to the folder containing a 'keys'
subfolder which contains the ed25519_master_id_secret_key or (_encrypted)?

- - the user running the 'tor --keygen' command has read/write
permissions to the targeted folder from --datadirectory?

- - is the date on the server where the 'tor --keygen' command runs correct?

- - fixing the permissions you mean changing the owner of the files to
the user actually running the Tor daemon on your system? (debian-tor,
_tor, etc.)

> and uploading ed25519_signing_cert and ed25519_signing_secret_key
> and fixing the permission, Tor keep saying
> 
> 
> Feb 03 07:27:40.000 [notice] It looks like I need to generate and
> sign a new medium-term signing key, because the one I have is
> expired. To do that, I need to load the permanent master identity
> key. Feb 03 07:27:40.000 [warn] We needed to load a secret key
> from /var/lib/tor/keys/ed25519_master_id_secret_key, but couldn't
> find it. Did you forget to copy it over when you copied the rest of
> the signing key material? Feb 03 07:27:40.000 [warn] Can't load
> master identity key; OfflineMasterKey is set. Feb 03 07:27:40.000
> [err] Error initializing keys; exiting
> 
> 
> That raises two questions to me: - why does Tor think the new keys
> are already expired? - why is Tor searching
> ed25519_master_id_secret_key? With OfflineMasterKey set it
> shouldn't care about the master secret key

It doesn't -- the only problem is that it warns when it shouldn't.
Only a log message issue which is known and reported here:

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

> 
> Thank you, patacca
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJWsjCiAAoJEIN/pSyBJlsRPXEH+gODzo++tMKUFs6e++4L3Cg5
MPdAXG76/wIhNllrRvV9mD3OoMMRo3uG+2rgKYfoff26enRT2JKcUXDcVM1Pu8cF
nIfDFHMNJGkghHhVO72VOEaW9rGPof7lyqB3SBVQLpWmaYlEpM7FGx0g9by974zX
E8JpfMW9jEnmAQY42bYfaEhoa1uC3lYbIAWIgQFN1FRKm2xMnz0g4EbzunN39xAa
UdHU+s9cIwjmtL4prjxFu+kVmTlWJrZo8HL1DfYdMqAZAu5vcYhvBTvNrjMY4jHT
3mLJoZO8FFXCfpswcQz1Kr9VICUacNH4nKXxXoupqObVNwp1merWLVQ1Q+nF+HI=
=BZ0V
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[s7r]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

More information is needed.

Please indicate the type of virtualization used (VMware, Xen, KVM,
OpenVZ), your operating system and Tor version as well as the "out of
memory" log messages you mentioned - are these from kernel logs or
Tor's log?. Setting Tor's log level to debug mode or info mode could
also help.

On 2/26/2016 1:19 AM, 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?
> 
> Thanks, Steve
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBCAAGBQJW0GtYAAoJEIN/pSyBJlsR0TIIAMnMD34Qn3LBOHMh3ITGMQtk
FvIvQZZPv9iOuggZpn8DP1GoU4Zxr08Cuxct4GTrJfTanvB33RMs6DuMm6cZB7f9
haSpu7hvE1vMf/9vkhwkrBR8BfAWQ+Nzm5EgkyH8nZd2/oMN0ZUL5QM5Arnd7gMQ
xDj+wJZmvIKHEgkjFfc+2JmnNuVKVKDUK27fj/O28lEg1AS4CtC9sOgEZeySzxmE
AtDW4nfn1PE+ihoLF6oM5gvpuYG87XUJuuT/Yzh6R/KfzHyr2wJgvd7irB1w4163
v5QIMcpUxa/jvaUApSNAfnah0QI1IZHQU6/CInMJpXoMCegX/BGZVxzVEEWteug=
=vipy
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Bandwidth Fallen Off Drastically

[s7r]

Hello,

Your relay seams fine on atlas:

http://atlas777hhh7mcs7.onion/#details/A290A9E71ADFC2FB1C80E64EF851A4B905450105


It has an observed bandwidth of 582.23 KB/s
Advertised bandwidth of 512 KB/s
and burst 716.8 KB/s

Which is exactly as per your configuration.

The consensus weight is 613, which is totally normal for this value of
observed bandwidth.

Tip: if you are on a limited bandwidth plan, better set AccountingMax
and do not cap the speed via RelayBandwidthRate / RelayBandwidthBurst.
Instead let it run at its maximum speed for less than an entire month
rather than capping it to few KB/s to ensure maximum n GB/TB are
consumed within a month.

On 3/14/2016 6:19 PM, Daryl Styrk wrote:
> Didn't some University just drop 5000 relays into the network?
> 
> On Mon, Mar 14, 2016 at 11:13 AM,   wrote:
> I have been watching my middle relay for the past four days and I
> can't figure out why my bandwidth has gone to hell. I have
> RelayBandwidthRate at 500 KB and RelayBandwidthBurst at 700 KB, but
> my bandwidth has fallen almost down to zero. I have removed the
> AccountingMax setting so it should be available for service, but it
> appears to be sitting idle.
> 
> fingerprint is 'stealth A290A9E71ADFC2FB1C80E64EF851A4B905450105'
> 
> Tor Version 0.2.7.6
> Debian 7.0
> 1 Meg of Memory on VPS
> 



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Who operates the bridge with nickname antirio?

[s7r]

Hi Karsten,

Does the bridge with hashed fingerprint
678912ABD7398DF8EFC8FA2BC7DEF610710360C4 fulfill the requirements you
are looking for? It appears to me it handles more clients than antirio
bridge, yet I ma unsure about the IPv4 and IPv6 distribution (don't know
how you count them) - if this is ok please let me know exactly what you
want me to do and how to check the statistics you mention, and i'll
revert with a complete report.

Is it just building Tor from your `task-18460-2` and starting Tor with
the same bridge identity?

P.S. this bridge is already running 0.2.8.1-alpha git
1f679d4ae11cd976+26ab2e0 - I assume your patch isn't merged already?

-s7r

On 3/27/2016 10:11 AM, Karsten Loesing wrote:
> Hi everyone,
> 
> does anybody here know who operates the bridge with nickname antirio?
> 
> https://atlas.torproject.org/#details/16609212922F6F1077A1BBA299709E19F9A3FB65
> 
> I'm asking, because that bridge has a nice distribution of IPv4 and
> IPv6 clients:
> 
>   bridge-ip-versions v4=48,v6=64
>   bridge-ip-versions v4=56,v6=72
> 
> We have a bug where IPv6 addresses are included in bridge-ip-versions
> statistics but where consensus downloads via IPv6 addresses are not
> counted.  It would be very valuable to test the patch for this bug on
> the antirio bridge or on another bridge with at least 1/2 of clients
> connecting via IPv6.  (When looking yesterday I didn't find another
> bridge with that property.)
> 
> The patch is commit b79d859 in my task-18460-2 branch:
> 
> https://gitweb.torproject.org/karsten/tor.git/log/?h=task-18460-2
> 
> In theory it should be sufficient to cherry-pick that commit from any
> other recent tor branch.  It just changes three lines of code.
> 
> More details on the ticket:
> 
> https://trac.torproject.org/projects/tor/ticket/18460
> 
> Thanks!
> 
> All the best,
> Karsten
> 




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] TORRC Exit not obeying httproxy

[s7r]

Hi,

First, thanks for running a relay.

Those settings do not ensure the EXIT traffic generated by your server
goes via any proxy.

OutboundBindAddress IP - this is the IP address Tor will use for
outgoing connections. This is the IP address which will be seen by
destinations accessed by Tor clients using your server, this is the IP
address which will receive abuse complaints.

HTTPSProxy service:port
HTTPProxyAuthenticator name password

These 2 settings refer for Tor usage as a CLIENT, not as a relay. This
means that the proxy listed at HTTPSProxy will be used by your Tor to
create its own circuits. They do not count for the relay usage.

In simple words, if you use that Tor instance as a client (SocksPort
127.0.0.1:9050 or whatever) either locally on that VPS either via a SSH
tunnel, and you build a circuit to connect to browse a website, Tor will
connect to the Guard (1st relay in the hop) via the proxy at HTTPSProxy.

But if I use your VPS as an exit in my circuit, the client functionality
at your side has nothing to do with it, and I will just get the IP at
OutboundBindAddress.

What you are trying can be achieved via more complex upstream iptables
rules, which will force all traffic going through a proxy. There is no
torrc option for configuring a proxy for EXIT traffic. Also, an exit
shouldn't only allow http/https traffic.

I would go for the easy option here which is convincing your vps
provider that:
- your vps is not infected in any way and it only relays anonymous
traffic for privacy concerned users, helping a global network of over
7000 volunteers
- your vps is properly secured and uses up to date software and it is
well protected from unauthorized authentications
- you will keep the vps for as long as you can, and only the ip address
of your vps will be affected, which is dedicated, their other customers
will have no draw back of any kind
- you will respond to all serious (non automated) abuse complaints send
by authorities within 48 hours after they are forwarded to you.

hope this helps, keep running exits!

On 6/11/2016 1:49 PM, Dr Gerard Bulger wrote:
> My tor exit node has been using a https proxy for a long time with great
> success in that I have had no abuse complaints directed to me and my VPS
> provider.   Until recently.   
> 
> Traffic has increased as I made the bandwidth wider, which might be an
> explanation.
> 
> I am getting complaints directed to my actual IP.   
> It looks as if tor is sending data DIRECT and not obeying the lines
> completely, all the time.   TORRC
> OutboundBindAddress  IP  (second IP of server)
> HTTPSProxy service:port
> HTTPProxyAuthenticator name password
> When I took out the OutboundBindAddress I just got complaints directed to
> the first IP.
> 
> I assumed the lines FORCED proxy use.   This might not be the case in higher
> traffic?
> 
> Gerry
> 




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Handling abuse - like to get your help please

[s7r]

Hello,

Thanks for running an exit relay.
That is just an automated email message. You do not want to reply to
every single automated message you receive, firstly because these
replies go into a black hole and they are not read by any humans, so
your effort may be useless.

Generally, you should only reply to abuse reports which are personalized
and properly addressed, indicating a clear problem or concern, sent by
simple internet users, authorities, investigatory bodies, etc. The
emails don't have to come from some organization/government/authority in
order to demand reply, simple concerned users are also rightful to
receive a human written personalized reply. You will quickly learn to
make the difference between an automated message and a real abuse report.

Over 90% of the abuse reports are fail2ban automated emails, emails sent
by intrusion preventing systems / firewalls - some of them clearly state
it's an automated message, others claim not to be responsible for the
content, others are addressed to 'whom it may concern', these are all
the same, copy/pasted text emails spammed to the abuse addresses.

These are not by any means strict rules, you are free to reply to
whatever you want, this is just my advice and purely informational. I
run quite a bunch of exits.

On 6/17/2016 11:12 PM, pa011 wrote:
> Thank you Michael, solving that obviously easy question :-)
> 
> So what was this "attac" then about, on which way, how can I see that ?
> 
> Nice weekend to all
> 
> Paul
> 
> 
> Am 17.06.2016 um 21:53 schrieb Michael Armbruster:
>> On 2016-06-17 at 21:51, pa011 wrote:
>>> Thank you both !
>>>
>>> @ Michael: that’s exactly what I did so far and in the past
>>> @ Moritz:  I will try my best - yes it was an automated response with
>>> just an name in Germany and no IP given, that I could possibly block
>>>
>>> "HTTP/1.1 404 293..."  are these the ports the traffic went trough ?
>>>
>>
>> Hi,
>>
>> Glad to hear other people already helped you out with your first question :)
>>
>> To answer this one: No, this is just the HTTP version (so protocol and
>> version), the HTTP status code (404 for "Not Found"; file was not found
>> on the server) and the size of the message that was transmitted to the
>> client, 293 bytes in this case.
>>
>> Best Regards,
>> Michael Armbruster
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [warn] eventdns: All nameservers have failed

[s7r]

Hello,

This warn is known for some time. It's safe to ignore this warning no
matter how many times you see it in your log file, IIRC it's a libevent
issue when DNS resolvers are idle. All my exit relays have multiple such
lines in the log files constantly.

It's highly important to run your own resolver on localhost 127.0.0.1
such as unbound or bind. Installation is pretty straight forward since
you need only a resolver. You will still get this warning even with your
own resolver hosted on localhost regardless if you use unbound or bind,
it's unrelated to this warning message, but using a local resolver will
help privacy of the users using your exit. It's the recommended way to
run exit relays.

On 6/19/2016 10:59 PM, pa011 wrote:
> Jun 19 20:24:38.000 [warn] eventdns: All nameservers have failed
> Jun 19 20:24:38.000 [notice] eventdns: Nameserver 8.8.4.4:53 is back up
> 
> 
> I do get this in my logs on an exit (Tor 0.2.7.6) several times every hour.
> 
> The /etc/resolv.conf contains
> 
> # Generated by SolusVM
> nameserver 8.8.8.8
> nameserver 8.8.4.4
> 
> Is it really best to set only one DNS like specified here
> https://trac.torproject.org/projects/tor/ticket/11600 ?
> 
> Or are there better working solutions?



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] suspicious "Relay127001" relays

[s7r]

On 7/6/2016 4:50 PM, Ivan Markin wrote:
> Andreas Krey:
>> That will cause issues for everyone that happens to select your
>> relay and the 'blocked' relays in a circuit - the connections will
>> just fail, and the user will wonder what happened, and why TBB
>> doesn't work.
> 
> Sure, I made a notice that you shouldn't do it if you care about the
> users (may be it was vague):
>> [Note also, that it makes performance poorer compared to the case
>> when it's defined by policy]

Why will you be running a relay if you don't care about the users?
Seriously now.

The path of a circuit is selected by the client (i.e. user). So, each
and every relay / bridge, in order to be considered a valid one, should
be able to extend a circuit when requested to any other relay, otherwise
everything gets broken. Setting this locally at relay side, with no way
for the applied change to reach the Tor client (user) will have terrible
usability effects. Trying to come up with a way so that Tor clients /
users can learn about such changes will over complicate everything with
no benefits and additional attack surface.

By design the only clean way to deal with bad relays is to exclude them
from consensus, a consensus that everyone uses, change applied only at
directory authorities side -- this is why we use the consensus majority
system which is well studied and understood as opposite to other more
decentralized solutions.



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Questions about Tor consensus weight & swag

[s7r]

shruub via tor-relays wrote:
I also (stupidly) tried to have a cron restarting

my tor daemon daily which also resulted in the latter. So I wonder, if
there is any way to have a relay run more stable and I suppose with a
somewhat higher consensus weight (I can only asssume making some further
changes in advertising bandwidth etc.



Restarting it on demand is the worst thing you can do. Even if it's 
overloaded, it's much better to leave it running as overloaded and have 
stable uptime history than to restart it. Restarting it makes you lose 
flags, and it also might be the reason your consensus weight was lowered.


If you know the limits of your resources you are better of by using:

RelayBandwidthRate X MBytes
RelayBandwidthBurst Y MBytes
MaxAdvertisedBandwidth Z MBytes

(I prefer just using the first two without MaxAdvertisedBandwidth).

It's usually a good idea to have RelayBandwidthBurst much bigger than 
RelayBandwidthRate. Example X = 8 Y = 20, you will see constantly 8 MB/s 
via your machine. If that is OK for your CPU, RAM and bandwidth, 
otherwise use other values.


If you don't have enough bandwidth to overload your CPU/RAM you don't 
need to set this as Bandwidth authorities will assign your relay such a 
low weight that it won't reach the bottleneck.




My second question(s) is/are concerning the tor swag (I hope that's
allowed to ask here). Firstly, what is the actual Speed requirement? In
the tor ecosystem, every unit is MBs, and only on the swag site its KBs.
But if my calculations are correct, 500KBs = 50Bs = 0.5MBs which
doesn't really make sence, imo(but I probably misscalculated somewhere).
Secondly, does running mean it's uptime (aka Last Restarted) or the Time
it was first seen?
You can set MBytes, GBytes, KBytes - don't need to compute yourself the 
Bs in order to reach a desired value of MBs.


As for what is the minimum required speed, there are mixt opinions here. 
There is _certainly_ a threshold where a relay becomes a problem rather 
than useful, when the resources spend to measure it, include it in the 
consensus and deliver its descriptors to clients overweight the speed it 
provides. There's not a value established yet for this as far as I know, 
but it certainly should be one. 500 KBs is too little for our days, IMO, 
at least 1 MB/s is even too little for mobile devices on 3G (we have 5G 
ready...).


You mean the `Running` flag? That means the relay is `running` $now 
where $now is the last time the majority of directory authorities voted 
that they can reach your relay (usually, last authority vote).


you also have `last restarted` and `first seen` separately for the other 
values you mentioned. `first seen` is only used for metrics, historic 
purposes while `last restarted` has some effect over flags (`HSDir`, 
`Guard`, `Stable`, etc.).


Thanks for running a relay!



OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Comcast blocks ALL traffic with tor relays

[s7r]

xmrk2 via tor-relays wrote:
Any ideas on how to combat this? I was thinking about including some 
false positives in tor relay list. Imagine including some Google 
servers' IP addresses - Comcast customers suddenly cannot connect to 
Google, unless Comcast stops this blocking... or simply whitelists 
Google. But those false positives sound ugly and a bit malicious, not 
sure it is a good idea.




This sucks big time, if true. I am trying to ping Comcast from a middle 
relay IP address and it seams, to work, I guess you mean AS33651 - 
Comcast Cable LLC. Anyway, it could be, at latest consensus there is no 
single relay (middle or exit) hosted in AS33651.


I am not sure about the false positive solution, I see only downsides, 
including but not limited to:


- it's not ethical for Tor Project to do this, e.g. stating another 
company's infrastructure (say Google IP address space) is part of a 
network when in fact its not. I get it that the goal is privacy oriented 
and in good faith (freedom faith) but it seams rather inappropriate;


- there is no evidence that a blocker might use a list of relays 
provided by Tor Project's metrics portal (I am confident nobody does it 
because it's less effective) - they can just run a Tor client and get a 
copy of a consensus and extract from there IP:PORT IPv6:PORT and do from 
there whatever they please;


- if you include such false positives in the consensus you have to 
simulate dummy Tor relays on those "hot" IP addresses, like providing an 
onion key, RSA identity and ed25519 identity, thus looking like a relay, 
state some bandwidth for it, etc - in this case how will a Tor client 
know which relay is dummy and which not, in order not to try to 
establish circuits that fail, ultimately producing a terrible user 
experience for all users. Same applies for other relays, not just 
clients, that need to produce connections with the dummy relays. If we 
somehow mark them as "dummy", it will be pretty stupid and obvious and 
waste of effort as the blocker can simply understand the "dummy" marker 
and it's done, I guess it's pretty obvious.


I already wrote about this publicly, and also wrote a mail to EFF. Hope 
I am not spamming, I feel this is quite important issue and am a bit 
frustrated by the lack of attention it gets.




Not at all, this is very interesting and not spamming at all. I think it 
is unacceptable for this to happen, and I think all Comcast customers 
should quit if this is true - large internet corporations are trying to 
move on from "IP address identifications" as in only a beginner that 
discovered the internet one week ago still thinks of the IP address as 
"identification of a certain individual / entity", everybody is moving 
to advanced layers of authentication on per device basis, cryptographic 
public key, etc. Comcast if they do such a thing they set themselves 25 
years behind the industry they operate in. And this can create many 
unwanted effects, someone should try to do something about this but I am 
not sure what we Tor volunteers *can* do to help with this, especially 
the ones that are not Comcast customers. EFF is the best start IMO.




OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Middle relay IP blocking

[s7r]

li...@for-privacy.net wrote:

On Samstag, 5. August 2023 08:40:42 CEST Marco Predicatori wrote:

secureh...@gmail.com wrote on 8/4/23 01:46:

I tried reporting a similar issue a few months ago (post wasn’t approved
by
moderator). I was running a relay from my home ISP. After a short while
certain websites became inaccessible from other computers in my home
network that shared the same public IP. After trial and error with other
IP addresses (non-Tor) I realized commercial gateway services had
blacklisted our IP address.


Same here, middle node. In order to access some sites, I have to shut down
briefly my modem in order to obtain a new IP, and for a while all goes
smoothly again.


Hi @all,

Just my 2 cents. Is this worth the hassle?
Calculate your power consumption 24x7x30 @home.

For 1-5$ you can get a VPS.
This exit has 1GB RAM and 1CPU and costs $3.50/month
https://metrics.torproject.org/rs.html#details/376DC7CAD597D3A4CBB651999CFAD0E77DC9AE8C

Search or ask for offers on LEB & LET:
https://lowendbox.com/
https://lowendtalk.com/discussion/185210/tor-relay-bridge

$websearch: cheap vps unlimited bandwidth
IONOS 1,-EUR/Month - 1GB RAM - 1vCore unlimited bandwidth - prepaid (=no 
contract term)
https://www.ionos.de/server/vps

Dedicated server for $15 per month: 4 Cores/4 threads - 16GB DDR3 - 5 usable 
IPv4  :-)
https://www.nocix.net/cart/?id=261


While all the above is true, a thing to remember is to make sure we 
don't end up all renting too many VPS'es or dedicated servers in the 
same places / same AS numbers - we need network diversity, it is a very 
important factor, more AS numbers, more providers, more physical 
locations, etc. So, running at home is super good and recommended from 
this perspective, provides us with the diversity we need, however not 
being to login to online banking to pay an electricity bill because of a 
middle relay is also way too annoying.. however who can afford the 
hassle should definitely run a middle relay or bridge at home (even Exit 
relay, I do run an Exit relay at my office place and I had one police 
visit in like 8 years or so).


The problem here is with the people who treat 1 IP address = 1 person, 
this assumption which is 3 decades old should disappear once and 
forever. I cannot imagine what kind of an IT/security expert would use a 
black list (haha) that contains Tor relays (double haha) and also 
applies same restrictions to *middle* relays (triple haha). There are so 
many ways to properly handle an IP address that sends 
robotic/unrequested traffic which are so obvious I'm not going to spam 
the list to enumerate them.




OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Running an exit relay in Italy

[s7r]

Eldalië via tor-relays wrote:

Hello there and thanks everyone for your answers to my message about middle
relay blocking. Reading them I feel trying to solve the blacklisting of my IP
would be overkilling.
Since I have a chance to get a cheap VPS, I will try to migrate the relay on
it. And since the relay would be on a dedicated IP, I'm thinking about
making it an exit. Of course I must consider the law, and I'd like to read some
references and listen about experiences from other operators before seeking
professional (expensive, I guess) legal advice.
My concerns are the following, but I would appreciate any other thoughts as
well. The relay would be in Italy so Italian and EU laws apply.



Thanks for the intent of running a relay especially an Exit one.


1. Would I bear any responsibility for the use of the relay? I'm aware of
the "mere conduit" concept (that is applied in the EU too) but Italy may
have some crappy additional law I'm not aware of.


Not that I am aware of. Please note that I do not reside in Italy but I 
know personally someone there that holds a hosting / internet related 
company and has to comply with the laws there. So he is not forced to 
maintain any data nor have customers identified in any way (not even 
email address).



2. Would I be subject to any data retention or data monitoring obligation?


No. You must act as a public service and not be able to technically 
filter or examine the traffic (e.g. don't install tracing tools or 
whatever, don't try to interfere with the traffic).



3. Would I be subject to any user identification obligation?


Not at all. You just run an open source software.


4. Would I risk the police knocking on my door even if the relay runs on a
datacenter and not on my home network?



No, if the relay is not on your home network no. There is a bigger 
probability for the ISP where you host the relay to be annoyed by abuse 
emails and try to shut down your service, or also I saw you mentioned 
VPS - an Exit relay will consume steadily bandwidth and CPU, which are 
two things hosters don't like when you max use on a shared resource such 
as a VPS. Probably they will ask you to migrate to a dedicated server 
that does not have pooled/shared resources. You could probably mitigate 
by using RelayBandwidthRate and MaxAdvertisedBandwidth torrc parameters 
to some values...


I think these type of problems will be more of a hassle for you than the 
"law", because you are not breaking any law by running an Exit relay, to 
the contrary - you make it better for everyone, for activists and for 
journalists and to the mission of providing unlimited free uncensored 
information and news to everyone.




OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] obfs4 bridge current setup is not entirely clear

[s7r]

Hi,

I ran into some new IP space and I decided to change a cluster of obfs4 
bridges that are more than 4 year old. When I set them up I don't 
remember spending so much time.


So, Debian latest and Tor latest from deb.torproject.org nightly.

GoLang from the official website (as it's the latest version) and 
obfs4proxy cloned from its default git repository.


1. The page at 
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs 
a small revision.


This page must be changed, for Debian it doesn't work simply $ edit 
tor@.service tor@default.service , change to NoNewPrivileges=no, save 
and quit.


For me it only worked by editing
/lib/systemd/system/tor@.service and 
/lib/systemd/system/tor@default.service with NoNewPrivileges=no and then:


$ sudo systemctl daemon-reload.

Setcap command is ok but it also need to mention to install the package 
in Debian libcap2-bin as well as an additional step:


Under Debian, if obfs4proxy is installed in a different place, for 
example like in its git documentation /usr/local/bin/obfs4proxy then you 
also need to edit this file:


/etc/apparmor.d/abstractions/tor

and add one line (or change the default obfs4proxy line to):

  /usr/local/bin/obfs4proxy Pix,

Substitute path if different and then:
$ sudo systemctl restart apparmor.



2. It was recommended on the mail list that obfs4 bridges should not 
open their ORPorts publicly to prevent scanning the entire 1-65536 port 
range and determine it's a Tor bridge. OK.


But if you try:

ORPort 127.0.0.1:auto
ORPort [::1]:auto
AssumeReachable 1 # needed to skip ORPort reachability test

Tor will start but it will constantly complain in the log with:

[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor 
address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 
'Address ' and 'OutboundBindAddress '. If you are behind a 
NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
 NoAdvertise'.


[warn] The IPv6 ORPort address ::1 does not match the descriptor address 
REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 
'Address ' and 'OutboundBindAddress '. If you are behind a 
NAT, use two ORPort lines: 'ORPort  NoListen' and 'ORPort 
 NoAdvertise'.


I guess it's OK to continue to run it even with this as I do understand 
the log messages and it's the desired effect, but isn't it confusing for 
less experienced users? They might think something is wrong when it is not.


The recommended way is to add a simple logic to skip that check, because 
we can't remove it, it's vital necessary for relays (not bridges) behind 
NAT or dynDNS or whatever. So if BridgeRelay 1 is set and 
$some_transport enabled, ignore the ORPort and descriptor check / log. 
and instead check the pluggable transport if port open and listening.


Or even better, code a pluggable transport port reachability test before 
building and uploading the descriptor, by cloning the code that does 
this for ORPorts to the pluggable transport ports. This would need a 
proposal that covers all use cases.



3. ServerTransportListenAddr can be used just once and it's difficult 
for dual-stack which is now the vast majority.


It's known for many years that each pluggable transport supports just 
one ServerTransportListenAddr line, the second one is simply ignored. 
Tickets for this exist.


So what is the best way to for an user to open both IPv4 and IPv6 
pluggable transport ports?


In Debian I have achieved it by using as wildcard 
ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian 
binds to all IPv4 and IPv6 addresses on all interfaces, but this might 
not be the same for all operating systems.


Also, how does BridgeDB determine in case wildcard [::] is used if the 
pluggable transport is IPv4, IPv6 or both? Which one is used when 
BridgeDB sends this bridge to clients?




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays