Re: [tor-relays] publish current AuthDirMaxServersPerAddr limit?

[Roger Dingledine]

On Sun, Feb 12, 2023 at 01:08:56PM +0100, Sebastian Hahn wrote:
> > On 12. Feb 2023, at 11:46, nusenu  wrote:
> > would it be possible to publish
> > the currently enforced value of AuthDirMaxServersPerAddr
> > on some tpo website? Maybe consensus-health.tpo?
> 
> that's a bit hard to do automatically, as the value is currently not
> exported by the dirauths. We'd need a feature to include the value in
> the votes, then it could be displayed. Not sure if the network team
> would work on such a feature, I'd be in favor.

Good idea. I've implemented it in my ```ticket40753``` branch,
described here:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40753

moria1 is including its AuthDirMaxServersPerAddr value in the
consensus params section of its vote, which makes its way to this
webpage:
https://consensus-health.torproject.org/#consensusparams

I'm not sure if this is the best possible design (we're sort of
blurring the line between what is a ConsensusParam and what isn't),
but it should be an easy and safe change at least. :)

nusenu: note that once enough dir auths vote this param, they will
compute a 'consensus' value for it in put that value in the consensus,
but nothing actually looks at or uses that consensus value.

--Roger

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

Re: [tor-relays] Police request regarding relay

[Roger Dingledine]

On Tue, Apr 11, 2023 at 12:09:15PM +, Finn wrote:
> Hello everyone,
> 
> We are hosting multiple relays under our AS 210558 and received an email from 
> a local police station in Germany requesting user data, nothing unusual.
> 
> The weird thing is, that the relay in question is only a relay and not an 
> exit node since its creation (185.241.208.179) 
> (https://nusenu.github.io/OrNetStats/w/relay/B67C7039B04487854129A66B16F5EE3CFFCBB491.html)
>  - anyone has an idea how this happens?

Thanks for running relays!

Do you know what kind of user data they wanted?

It looks like your relay has been a Guard relay (i.e. has had the Guard
flag) for most of the past year. One possibility is that they have
somehow decided that a user they are trying to track uses your relay
as one of their Guards. That is, in this scenario they decided that the
user connects to your relay consistently over time, so they are asking
you to help them learn more about that user.

Of course, your Tor relay in its default settings doesn't have any useful
data for them, and you should keep it configured that way.

It is unclear how much people might be trying to do "guard discovery"
attacks in practice, and also unclear how well they might work -- there
is a lot of research on this class of attacks in theory but not much is
known about whether it matters in practice.

And who knows, it could be something else: maybe they are just fishing
for general information, or maybe they are intentionally creating useless
work and stress for you and your hosting provider to discourage you from
wanting to help Tor users.

More reading on the 'guard discovery attack' topic:

* PETS paper, From "Onion Not Found" to Guard Discovery:
https://petsymposium.org/2022/files/papers/issue1/popets-2022-0026.pdf

* The Vanguards idea:
https://blog.torproject.org/announcing-vanguards-add-onion-services/

Part of the vanguards idea is implemented by default in Tor 0.4.7:
https://gitweb.torproject.org/torspec.git/tree/proposals/333-vanguards-lite.md
https://gitlab.torproject.org/tpo/core/tor/-/issues/40363

Hope this helps,
--Roger

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

Re: [tor-relays] Tor Relay Operator Meetup - April 15th, 2023 at 19 UTC

[Roger Dingledine]

On Thu, Mar 30, 2023 at 11:04:25AM -0300, gus wrote:
> The next Tor Relay Operator Meetup will happen on April 15th, 2023, at 19 UTC.
> 
> We're still working on the agenda, feel free to add your topics and/or
> questions on the pad:
> https://pad.riseup.net/p/tor-relay-op-meetup-april-keep
> onionsite:
> http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor-relay-op-meetup-april-keep
> 
> WHERE
> Room link: https://tor.meet.coop/gus-og0-x74-dzn
> 
> Registration
>  
> No need for a registration or anything else, just use the room-link
> above. We will open the room 10 minutes before so you can test your mic setup.
>  
> Please share with your friends, social media and other mailing lists!

Reminder! This event is in 21.5 hours, which depending on your
time zone might count as "tomorrow". :)

Looking forward to seeing you there,
--Roger

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

Re: [tor-relays] Security implications of disabling onion key rotation?

[Roger Dingledine]

Thanks Nick! I endorse Nick's response, with two additions:

On Thu, Jun 01, 2023 at 09:07:17AM -0400, Nick Mathewson wrote:
> Onion key rotation limits the time range in which this kind of attack
> is useful: it will only work for as long as the onion key is listed in
> a live directory.

For bridges it is a little bit different, because bridges don't have
an onion key listed in any public (consensus style) directory document
that clients get. Rather, the client connects to the bridge directly and
fetches a full timestamped descriptor from the bridge, which is signed
by the bridge's identity key, and which includes the onion key that the
client should use.

So if you have broken an old (rotated) onion key for a bridge, the
proper attack involves MITMing the connection to the bridge, breaking
or stealing the bridge's identity key too, and crafting a new descriptor
that lists the old onion key.

Whereas if the bridge never rotates the onion key, then you would be
able to successfully attack the CREATE cell that the client sends to
the bridge -- but only if you could see it, which would involve MITMing
the connection to the bridge and also being able to convince the client
that you are the bridge, which I think implies having or breaking the
identity key too. Doesn't seem so bad.

> (Now, any attacker who can steal your onion key can probably also
> steal your identity key too, if you don't keep that offline, and use
> it to impersonate you for even longer. The advantage of using a stolen
> onion key is that it's much harder to detect; all the attacks I can
> think of that use a stolen identity key involve, whereas the
> onion-key-theft attack occurs when you are already in a perfect
> position to be a MITM.)

"...involve publishing a new signed document which others could notice"
maybe?

Though for the bridge case, the attack could be more subtle, in that you
could provide a specially signed descriptor only to your victim user,
who would then learn the special onion key from that descriptor, use it,
and never know that other users received a different descriptor.

An attack like that isn't so bad though, because we still have the second
hop and third hop in the circuit, producing their own forward-secret
session keys with their own properly rotated onion keys, and having the
protections that Nick describes.

--Roger

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

Re: [tor-relays] Security implications of disabling onion key rotation?

[Roger Dingledine]

On Wed, Jun 28, 2023 at 02:09:34AM -0600, David Fifield wrote:
> Thanks, that was a subtlety I had missed. Since we are writing about
> bridges, I mostly want to give the bridge perspective. We had formerly
> written this:
>   A relay's current onion keys appear in the Tor network
>   consensus; when clients make circuits through it, they expect it
>   to use certain onion keys.
> We've now changed it to:
>   Tor clients cache a bridge's onion public keys when they
>   connect; subsequent connections only work if the cached keys are
>   among the bridge's two most recently used sets of onion keys.

Makes sense.

> So it sounds like compromise of an onion key is no worse than compromise
> of an identity key, because with an identity key an attacker could cook
> up and sign a new onion key. The exception is that if an attacker
> somehow got an identity key but not current onion keys, and it's a
> bridge that's affected rather than a relay, then the attacker would not
> be able to fool clients that had previously connected and cached the
> past genuine onion keys.

Right. But that window where the cached version protects you is quite
narrow -- it looks like modern clients fetch a new bridge descriptor
every TestingBridgeDownloadInitialDelay (3 hours) (see where we set
next_attempt_at in learned_bridge_descriptor()), and not too long ago
we fetched a fresh bridge descriptor hourly.

The reasoning for the frequent fetches is that fetching the bridge's
descriptor over a one-hop circuit is a low cost operation, and it doubles
as a crude liveness check (since if it succeeds, the bridge should work
for real circuits too, and if it fails, we should mark the bridge as
not working currently).

When Tor starts up with a cached bridge descriptor with a timestamp we like,
I imagine it is not long until we attempt to fetch a fresh descriptor. I
haven't checked our current behavior though. But I would not rely on
this onion key caching for security.

Hope this helps!
--Roger

___
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

[Roger Dingledine]

On Mon, Aug 07, 2023 at 11:28:32PM +0300, s7r wrote:
> 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

Yes, exactly this. If you are interested in running a non-exit relay at
home, and you can tolerate the hassles from occasionally finding that
some service doesn't want to hear from you, then you are definitely
helping the diversity of the Tor network.

Having the Tor traffic concentrated at a few cheapo providers like Hetzner
and OVH is not only scary in the sense that too much traffic goes through
too few cables, but it's also scary because it increases the appeal for
somebody to attack those few companies, either by breaking into their
infrastructure to watch traffic or through more traditional insider
threats like getting an employee there to help them monitor traffic.

The internet already has uncomfortably many bottlenecks -- too few
undersea cables, too few Content Distribution Networks (CDNs), too few
app stores, etc.

> (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).

Follow this advice only with great caution. :) Many people happily
run their exit relay from their home, but it only takes one fresh new
cybercrime detective (trying to make a name for himself by kicking down
a door at 7am, and with no idea what Tor is) to ruin your day.

--Roger

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

[tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

Hi folks!

EFF has launched their advocacy campaign for getting more Tor relays
running at universities:

https://toruniversity.eff.org/
https://www.eff.org/deeplinks/2023/08/announcing-tor-university-challenge
https://www.eff.org/press/releases/eff-launches-tor-university-challenge

We're focusing on universities in particular, not just to get more
capacity for the Tor network, but also to strengthen the connections
between the Tor network and academia. Universities are great locations for
Tor relays for education (Tor is part of every cybersecurity curriculum
these days), for community (growing connections between students and
research groups), and for research (helping the Tor network stay strong
so people can use it for research):

https://toruniversity.eff.org/administrators/
https://blog.torproject.org/tor-heart-pets-and-privacy-research-community/

Having more relays at universities is especially useful because it can
help others to see that running a relay is a normal and straightforward
thing to do.

So: if you are at a university, or you know somebody who is and want to
help them, please consider setting up relays there. It can be anything
from an exit relay (the most useful to Tor users, but the most work in
terms of local advocacy and relationship-building), to a non-exit relay
(still very useful to Tor users, because we need more network diversity),
to a non-NATed Snowflake bridge (currently used most by people in Iran
to get around their censorship and reach the Tor network).

We started the campaign with thirteen institutions that are already
running relays and/or other public infrastructure pieces:

Technical University Berlin (Germany)
Boston University (US)
University of Cambridge (England)
Carnegie Melon University (US)
University College London (England)
Georgetown University (US)
Johannes Kepler Universität Linz (Austria)
Karlstad University (Sweden)
KU Leuven (Belgium)
University of Michigan (US)
University of Minnesota (US)
Massachusetts Institute of Technology (US)
University of Waterloo (Canada)

Hopefully this list will make you impressed / excited / jealous and you
will want to get your university onto it. :)

Later steps in the campaign will be to understand which universities
have IT departments that understand and value Tor, and which ones try
to block you from using Tor on their network or block Tor users from
reaching their webservers. We are also imagining to do an OONI workshop
to help people do "how well does Tor work on this network" tests.

Here is the internal coordination/roadmap ticket if you want to follow
along in detail:
https://gitlab.torproject.org/tpo/community/relays/-/issues/67

Thanks!
--Roger

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

Re: [tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

On Thu, Aug 10, 2023 at 11:18:46AM -0600, Gunnar Wolf wrote:
> Yes, I do!
> 
> Please add to the list:
> 
> Universidad Nacional Autónoma de México
> 
> We have been running two relays since 2017/2018, and enabled two additional
> relays (in the same VM / IP address) recently.

Awesome! I will pass your contact info to Cooper, who will add you to
the internal lists he is tracking.

I missed some relays-running-at-educational-institutions on the first
pass, because we don't have an easy way to look up "which relays are at
universities?" If anybody wants to help work on that, it's
https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40022

We also have a handful of known great relay operators, such as the ones
run by ibiblio at UNC and a few in Germany, who didn't answer my mails
yet and I expect that eventually we will add them.

Cooper showed me the beautiful shiny challenge coins that he made to
send to university relay operators. They are a work of art. I believe his
plan is to send them to people once their relay has been up for a year,
i.e. some people qualify already but the people who newly start a relay
in response to this EFF campaign will have to keep it going for a while
to earn the shiny object. :)

--Roger

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

Re: [tor-relays] Tor Weather : Node-Flag [Guard] Alert

[Roger Dingledine]

On Tue, Sep 26, 2023 at 07:44:29PM -0400, denny.obre...@a-n-o-n-y-m-e.net wrote:
> I received the following message from Tor Weather. According to Tor Metrics, 
> this exit relay still has no Guard flag.
> 
> Another - slightly more recent - exit relay 
> (25FC41154DCB2CAE3ABD74A8DFCD5B90D2CFFD57) is on the same server and IP,
> and still has the Guard flag (although with 0% guard probability).
> 
> Should I do something with this info?
> 
[...]
> > We have detected that the node - 3B85067588C3F017D5CCF7D8F65B5881B7D4C97C 
> > associated
> > with your subscription has lost the Guard flag
> > for more than 1hr(s). This may impact the performance of your service.

Thanks for running relays!

The low-complexity answer: no, don't worry about it. The Guard flag
doesn't really matter for exit relays these days, because the bottleneck
in the Tor network is exit capacity, so clients won't be using exit
relays for their first hop anyway. And even if they weren't exit relays,
I would also say don't worry about it -- run your relays, enjoy feeling
good that you're contributing, and don't feel like you need to be gamified
into collecting all the flags like pokemon.

The medium-complexity answer: you can check out the
individual votes about your relay by going to the bottom of
https://consensus-health.torproject.org/#relayinfo and putting your
nickname or fingerprint there. As you say, the Ernest relay currently has
seven votes for Guard, so it gets the Guard flag, but the Alberta relay
only has 4 votes for Guard, and it needs a majority (5 out of 8) so it
doesn't get it. It's clearly right on the edge. I think the difference is
in measured bandwidth: moria1 and longclaw think it is above the median
bandwidth they see, while gabelmoo and maatuska and bastet think it is
below their median. I would not be surprised if it wavers back and forth,
getting and losing the Guard flag, for the next while.

(This medium-complexity answer is a bit more complex because the
consensus-health website can't reliably fetch each vote from each
directory authority each hour. For example, it's missing tor26's vote
this round. But those votes can still be found in the metrics data set,
e.g. https://collector.torproject.org/recent/relay-descriptors/ )

And the high-complexity answer is that you can see the individual
cut-offs published by each directory authority about your relay, in
their individual vote documents (some assembly required).

$ grep -A10 "^r Alberta" v3-status-votes|egrep "^(stats|w)"
w Bandwidth=4092 Measured=2700
stats wfu=0.997242 tk=845547 mtbf=128371243
w Bandwidth=4092
stats wfu=0.996686 tk=1534488 mtbf=709353
w Bandwidth=4092 Measured=2200
stats wfu=0.999081 tk=2596023 mtbf=2391699
w Bandwidth=4092 Measured=2000
stats wfu=0.999053 tk=2493149 mtbf=2234701
w Bandwidth=4092 Measured=1900
stats wfu=0.999090 tk=2558326 mtbf=2324742
w Bandwidth=4092 Measured=2000
stats wfu=0.999031 tk=2455223 mtbf=2224108
w Bandwidth=4092
stats wfu=0.998203 tk=1692074 mtbf=1269334
w Bandwidth=4092
stats wfu=0.987932 tk=2331276 mtbf=241054

and you can read about what these stats mean at
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2629

Hope this helps,
--Roger

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

Re: [tor-relays] Relay Bandwidth Limit

[Roger Dingledine]

On Mon, Oct 16, 2023 at 01:18:01PM +, Dan wrote:
> Hi all,
> 
> I’ve been running my first relay for a few weeks now. The VPS provider I 
> chose provides 5TB of bandwidth per month so I have set AccountingMax to “5 
> TB” and AccountingStart to
> “day 1 00:00”. It looks as though my relay is going to blow past that limit 
> based on the average data transferred per day and how many days are left in 
> the month. Will it simply stop transferring data when the monthly limit is 
> hit?

Yes, that's how it works.

The one catch to keep an eye out for is that different ISPs count
bandwidth differently, and by default when you set AccountingMax to 5
TBytes, it means up to 5 TBytes in each direction. If your ISP means
"2.5 TBytes in each direction" when it says 5TB of bandwidth per month
(i.e. it counts each byte twice), then you could be in for a surprise.

See the AccountingMax section in the man page for more details, and
see the AccountingRule option in the man page for how to tell Tor that
your ISP means something different than Tor expected.

--Roger

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

Re: [tor-relays] Relay Bandwidth Limit

[Roger Dingledine]

On Mon, Oct 16, 2023 at 09:40:17AM -0400, John Broome wrote:
> My experience with the Snowflake container is that it will blow through the
> bandwidth limit for the month, and your VPS will cut you off until the next
> billing cycle.

Yes, this is correct, the standalone Snowflake does not have rate
limiting built-in currently.

But, running a Snowflake bridge in a container is a different topic
than running a Tor relay (or a Tor bridge).

--Roger

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

Re: [tor-relays] "Failed to find node for hop #1 of our path"

[Roger Dingledine]

On Thu, Nov 09, 2023 at 06:33:08PM -0500, William Denton wrote:
> Lately my relay hasn't been seeing much traffic, which I didn't notice for a
> while, but now I'm turning my attention to it.  I just updated to 0.4.8.9
> and see these notices (with some lines cut out):

Thanks for running a relay!

Do you know if you were seeing those messages on earlier Tor versions too?

> Nov 09 13:36:42.000 [notice] Tor has not observed any network activity for 
> the past 521 seconds. Disabling circuit build timeout recording.
> Nov 09 13:38:03.000 [notice] Failed to find node for hop #1 of our path. 
> Discarding this circuit.

These are client-side messages, that is, your Tor is acting as both a
relay (because you configured it that way) and a client (in case you
try to use it that way), and it is not finding itself to be stable as
a client.

These particular circuits are probably the exploratory testing circuits
that Tor clients make at first, to understand how fast their network is
in order to avoid using the bottom 20% ("long tail") of circuits that
take the longest to make.

> There are hundreds of those notices about failing to find a node for hop #1.
> (I don't know why it complains about the network being down to 2013 seconds
> (over half an hour), because I didn't notice anything, but there were scores
> of the same warnings before that.)
> 
> What would cause this, or what could I do to identify the problem?

Well, the first question is, are you sure your network connection is
stable and working this whole time? An easy explanation would be that you
had connectivity problems during that time, and from a relay perspective
Tor just sat there patiently not minding that nobody was arriving, but
from a client perspective it noticed that something was wrong and said so.

I am guessing that this is your relay:
https://metrics.torproject.org/rs.html#details/2A6E7ABF43F9796AD4A13DF2B2047F90E7291A5F

Another possibility, which I don't think applies in your case, is that
your relay is so overwhelmed with traffic, and/or is rate limiting all of
its traffic, that the client-side testing circuits are squeezed out. But
based on the bandwidth graphs I don't think that's happening here.

--Roger

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

Re: [tor-relays] EFF's university Tor relay campaign

[Roger Dingledine]

On Thu, Aug 10, 2023 at 03:19:06AM -0400, Roger Dingledine wrote:
> EFF has launched their advocacy campaign for getting more Tor relays
> running at universities:
> 
> https://toruniversity.eff.org/

Cooper has posted an update on how the campaign is going:
https://www.eff.org/deeplinks/2023/11/tor-university-challenge-first-semester-report-card

Highlights include:

* we have made contact with more already-existing relays at universities,

* we now have some new relays running at universities,

* and we have made better contact with European NRENs (the national-level
university internet connectivity organizations), particularly the ones in
Switzerland, the Netherlands, and Greece.

> So: if you are at a university, or you know somebody who is and want to
> help them, please consider setting up relays there. It can be anything
> from an exit relay (the most useful to Tor users, but the most work in
> terms of local advocacy and relationship-building), to a non-exit relay
> (still very useful to Tor users, because we need more network diversity),
> to a non-NATed Snowflake bridge (currently used most by people in Iran
> to get around their censorship and reach the Tor network).

This part is still true! No time like the present to get involved. :)

--Roger

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

Re: [tor-relays] Relay question

[Roger Dingledine]

On Fri, Dec 08, 2023 at 03:19:49AM +, Mulloch94 via tor-relays wrote:
> Greetings, I was directed to this relay subscription by the owner. I've 
> recently started my own relay and everything has went smooth for the first 
> few days. Then the relay mysteriously went offline for a period of 8-9 hours.

What do you mean by offline? The computer was offline? Or, the relay
process was not running? Or, the relay process was still running but it
was no longer reachable from the outside? Or something else?

I think there aren't enough hints so far for us to guess what happened,
i.e. there is still some mystery.

> Happened while I was sleeping I think, but any rate it came back on after I 
> restarted the tor daemon and rebooted the server. I'm starting to think my 
> firewall configurations might have been the culprit, even though I ran a very 
> rudimentary setup. Basically just:
> -A INPUT -p tcp --dport  -j ACCEPT
> -A INPUT -p tcp --dport 9050 -j ACCEPT
> -A INPUT -p tcp --dport 443 -j ACCEPT
> -A INPUT -p tcp --dport 80 -j ACCEPT
> -A INPUT -j DROP
> 
> Default ACCEPT on OUTPUT

I am no iptables expert, but (a) this sounds like it should work, and (b)
you probably don't want that 9050 line in there, since your Tor relay's
socksport is intended to be only listening on localhost. (Opening up
the firewall for 9050 shouldn't hurt any though, so long as Tor still
only listens on localhost.)

> My ORPort is on 443, so I don't see how this could be interfering. I noticed 
> my server reboot got rid of all my rules, so I'm thinking that could've been 
> the issue. If so, what other ports should I add? Do I even need a firewall 
> for the relay? I don't do anything else with that server, so If it doesn't 
> need a firewall to stay secure I won't use one.

Opinions differ on the importance of firewalls, but technically no,
you would be fine without any sort of rules like these, so long as you
keep track of what applications are running on the system and make sure
things aren't listening on the outside that you didn't intend. If you
aren't a confident and experienced sysadmin though, the firewall rules
are probably helpful because they simplify the question of how much
surface area might be exposed to the world.

> One more thing, I had a flag on my relay that said I needed to "update the 
> descriptor." It went away after rebooting my server as well, could that been 
> the issue?

That sounds normal-ish, and it implies that your relay stopped running
somehow, before that reboot. Next step would be to check the Tor logs,
check the system logs, otherwise try to better understand what is
going on on your computer.

--Roger

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

Re: [tor-relays] Relay migration

[Roger Dingledine]

On Tue, Jun 04, 2024 at 04:42:50PM +, Eldalië via tor-relays wrote:
> Hello everyone.
> I have to move somewhere else a a (middle) relay I have been running for a few
> years. It will be down for 2-4 weeks, then be back online in a different
> location, with different ISP, at better speed. But it will run on the same
> hardware and software. Should I keep the same keys, or start from scratch?

Thanks for running relays!

I would say that either choice is reasonable. So if there is one that
makes you feel happier about your contribution, go with that one. :)

Having a relay downtime of 2-4 weeks though could really increase the
time until you get flags like Guard back, due to some design flaws in
how the directory authorities track stability. (The simple version of the
issue is: we treat downtime as much more serious than not-existing-yet.)

So for that reason I would probably pick 'start from scratch' if I were
doing it. Making a new set of keys is easy and simple and doesn't really
hurt anything.

--Roger

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

Re: [tor-relays] Why should we avoid adding bridges fingerprints in MyFamily?

[Roger Dingledine]

On Sun, Jun 23, 2024 at 07:30:00PM +, Edward Cage via tor-relays wrote:
> Quick question about the fingerprints of our bridges. It's clearly written
> in torrc that we should not include them in MyFamily.

Correct.

> I don't well understand why, especially because:
> - Every bridge, and their fingerprints, are publicly listed on Tor
> Metrics;

Actually it is the *hash* of the fingerprint (hash of hash of key)
that is publicly listed in Tor metrics. This way you can look up your
bridge if you know its fingerprint, but other people can't learn more
about your bridge just based on the relay-search page.

> - The contact email is disclosed for each of them, and it allows our
> bridges and relays to be easily linked to a same operator. (or should we use
> a different email address for each bridge?)

It is fine to use the same contactinfo on your bridges and relays --
because it won't help somebody discover your bridge address or bridge
fingerprint if they don't already know it.

Ultimately the right answer is to move to a better design for declaring
families. The current best idea is Proposal 321:
https://gitlab.torproject.org/tpo/core/torspec/-/blob/HEAD/proposals/321-happy-families.md
with more details here:
https://gitlab.torproject.org/tpo/core/tor/-/issues/40134
and a suggestion at the end of that ticket by trinity that seems like
it could be a good short-term fix.

I think all of the core devs who might work on Proposal 321 are instead
working on Arti though, so at this rate it will be a long while until
the topic sees progress.

--Roger

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

Re: [tor-relays] Tor Metrics 'Running' flag is back for bridges who don't publish the OrPort

[Roger Dingledine]

On Sun, Jun 23, 2024 at 09:28:23PM +0200, li...@for-privacy.net wrote:
> A few months ago there was a recommendation to not exposing OrPort for 
> bridges.
> This had the unpleasant effect that all bridges were 'red' on Tor Metrics, 
> even though they were running perfectly fine.
> I noticed yesterday after the meeting that everything is 'green' again.
> https://metrics.torproject.org/rs.html#search/ForPrivacyNET
> 
> Thank you, I believe these 6 people did that:
> https://gitlab.torproject.org/tpo/network-health/team/-/issues/318

Right -- I think we are still in the process of fixing that issue. The
current situation as I understand it is that bridgestrap measures whether
your obfs4 port is reachable, and it uploads these results to the metrics
sites, and the metrics sites use them if available instead of looking
at Running.

But currently the "uploads to metrics" step happens once a day, while
bridgestrap produces results way more frequently than that.

And in the past there were surprises where the metrics side would say
something like "I'll call you running if bridgestrap said you were
reachable within the past three hours" -- which is a great design if
you are getting the bridgestrap results rapidly, but not great if you
get them once a day.

So, I'm glad to see that your relay was green again for a bit, but I
fear a bit more work remains until we get there *consistently*. :)

--Roger

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

Re: [tor-relays] Seeking Advice on Running Multiple Tor Relays or A Bridge

[Roger Dingledine]

On Sat, Jul 06, 2024 at 06:34:37PM +, Alessandro Greco via tor-relays wrote:
> I have some experience running a Tor relay, and I am now interested in 
> setting up another one. I plan to do this using my home internet connection, 
> which is an FTTH line with bandwidth up to 2 Gbps.

Thanks for running a relay!

> I have read that it is possible to run multiple relays on the same node, but 
> I am unsure how to configure this.

If you're using the tor deb (e.g. on Debian or Ubuntu), it comes with
a tool to set up multiple tors. "man tor-instance-create" to get started.

There is also the possibility of using the fancy automated
deployment tools that some of the bigger relay operators here
use, which probably only makes sense if you are already familiar
with these automation tools (a popular one based on ansible:
https://github.com/nusenu/ansible-relayor ).

In either case, make sure you have enough memory in your system to
handle each Tor relay: relays can use 1 or 2 gigabytes of memory each
during normal operation, but when the network is under load it can go
much higher than that.

> Additionally, I am curious about what would be most beneficial for the Tor 
> network today: a highly resilient bridge or multiple relays managed from the 
> same node?

If you have the bandwidth (which it sounds like you do), the multiple
fast relays will be much more useful to the network.

See also https://2019.www.torproject.org/docs/faq#RelayOrBridge

> Is it feasible to operate both at the same time? This is probably not the 
> best idea since the bridge's IP address would be public, right?

It is technically possible yes, but as you say, having a public relay
on the IP address will undermine the effectiveness of your bridge on
that IP address.

The same logic is also why we don't recommend running two different
kinds of bridges on a single IP address: if one of them gets discovered
and the censor blocks by IP address, then the other will stop working too.

> I am looking for guidance on the best course of action to support the Tor 
> community.
> Thank you in advance for your assistance,Aleff.

Thanks for wanting to help!

--Roger

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

Re: [tor-relays] Bridge node configurations and where to find them (semi quote)

[Roger Dingledine]

On Sun, Aug 25, 2024 at 12:40:02PM +, Alessandro Greco via tor-relays wrote:
> In the past, I set up a middle relay node, and today I am looking to 
> experiment with configuring a Bridge node to support the Tor project and its 
> community.

Great!

Be sure to run your bridge on a different IP address than you run your
public relay(s): there are censors out there that pull the list of public
relays and block them by IP address, so if you have a bridge on one of
these known addresses it could end up blocked this way.

> First, I will summarize the `torrc` configuration file (I have removed the 
> ports as they differ from the standard ones):
> 
> ```
> BridgeRelay 1
> ORPort 
> ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
> ServerTransportListenAddr obfs4 0.0.0.0:
> ExtORPort auto
> ExitPolicy reject *:*
> ```

Looks good. You don't need the ExitPolicy line (you're just setting it
to the default), but it doesn't hurt to have it there.

And if this is on Debian and your Tor deb applies apparmor, you might
need to do the 'systemctl edit' steps listed on
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/
in order to let Tor launch obfs4proxy.

> I have set two limits on the connections:
> ```
> BandwidthRate 300 MBytes  # I want to determine how much bandwidth I can 
> allocate without impacting my network usage.
> IPv4Only
> ```

That's a huge bandwidthrate, so I expect your bridge will never get
anywhere close to reaching it. This is fine too. Also be sure to learn
about 'BandwidthBurst' in case its behavior is surprising to you.

The IPv4Only entry isn't a valid torrc line, so maybe you mean something
else there like writing that on your ORPort?


> As for the information settings, I have used the usual `ContactInfo` and 
> `Nickname`.

Sounds good.

> While reading the `torrc` documentation, I discovered the Sandbox feature, 
> which is still in development. In this regard, I would like to ask whether 
> using experimental features like this on Bridge nodes is advisable or not. 
> Personally, I would find a feature like this very useful.

Sure, feel free to turn on "Sandbox 1". If it works for you, great. If
it breaks for you in a way that you think is a bug, consider filing a
gitlab ticket.

> Should an anti DDoS system be configured?

I would say you don't need to mess with those options, especially for
a bridge, unless some sort of overload starts happening to you.

And for bridges you probably won't see any sort of overload -- most of the
time they get very little use, because either they remain mostly unknown
(so the load doesn't grow that high), or they become too known and then
the censors block them (so the load doesn't stay high).

If you are excited to use more bandwidth than your obfs4 bridge turns
out to use, consider running a headless snowflake proxy:
https://snowflake.torproject.org/#extension
and scroll down to "Run a standalone proxy" which leads to
https://community.torproject.org/relay/setup/snowflake/standalone/

> I wanted to ask how I can further contribute to the Tor Project's research, 
> as I have read that there are "Statistics" features that allow the collection 
> of useful information for the developer community. I have two main questions 
> about this:
> 
> 1. Is it advisable to use experimental features or those that collect 
> information on a Bridge node (assuming there is a difference between a 
> Bridge, a Guard/Middle relay, and an Exit Node)?
> 2. If the answer to the first question is yes, what are all the features that 
> I can include in the `torrc` file to passively support research within the 
> Tor Project?

Feel free to mess with your torrc options if you find it fun. Remember
that you shouldn't need to mess with them for normal operation though.

Search for the 'STATISTICS OPTIONS' section in 'man tor' to see the
options. Your Tor will write out its daily aggregated summaries in stats/
in your DataDirectory.

That said, looking at the code it seems we auto-disable some of these
statistics options when you are not a public relay:

  /* Only collect other relay-only statistics on relays. */
  if (!public_server_mode(options)) {
options->CellStatistics = 0;
options->EntryStatistics = 0;
options->ConnDirectionStatistics = 0;
options->ExitPortStatistics = 0;
  }

so don't be surprised if some of them have no effect.

> Finally, I would like to ask what information should be kept confidential 
> when managing a Bridge. For example, I know for sure that it is important to 
> keep the IP address confidential to avoid the risk of being blacklisted, but 
> are there any other pieces of information that need to be protected?

There are two categories of data you want to keep safe:

(1) IP address and relay identity fingerprint. The fingerprint is the hash
of the public key, and people can use the fingerprint to look up sensitive
details of the bridge like its address. (The hashed fingerprint, aka hash
of hash of public key, is s

Re: [tor-relays] Dynamic upload limit

[Roger Dingledine]

On Sun, Feb 16, 2014 at 08:54:07PM +0100, Bram L wrote:
> Before I do so, however, I am curious whether it actually
> contributes to the Tor network.
> I noticed it takes time for the bandwidth to increase, and if my
> daytime upload limit is low (e.g. 80 kb/s) and unlimited (Gb/s) at
> night, my overall contribution could be very limited due to the time
> it takes Tor to utilize my available bandwidth.

Right -- as you note, the bandwidth authority measurers have no
notion of looking for daily/weekly/etc patterns like this.

> Do you have any insights in this matter?

A better bet might be to simply run your relay, at the Gb/s rate,
only during the times when you're allowed to use the fast rate. The
relay won't get the Guard flag because it won't be suitable for use at
that rate enough of the time, but the bwauths will remember their last
measurements of it each time it comes back, so it should get back in
use pretty quickly after returning each day.

You could even arrange to have it come back an hour or two before you
want things to ramp up, so there's time for it to get into the consensus,
get noticed by clients, etc.

--Roger

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

Re: [tor-relays] Obfsproxy help

[Roger Dingledine]

On Sun, Feb 23, 2014 at 03:59:59PM +1100, Zenaan Harkness wrote:
> Presumably something in your etc/tor/torrc file?

Right:

"Feb 22 20:14:38.441 [warn] Failed to parse/validate config: Unknown option
'3'.  Failing."

Sounds to me like you have a line in your torrc that starts with "3",
and of course Tor doesn't know what to do with it.

Did you edit your torrc file, and break it in some way?

> If you are running bleeding edge tor, it might pay to subscribe to
> tor-dev, and if you are subscribed there, that might be the best place
> to post bleeding edge issues (just an idea - I don't recognise your
> problem sorry).

No, posting issues like this on tor-dev won't help anybody. :)

Asking on IRC will probably provide a more useful answer:
https://www.torproject.org/about/contact

--Roger

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

Re: [tor-relays] (no subject)

[Roger Dingledine]

On Tue, Feb 25, 2014 at 10:15:11AM +1100, Zenaan Harkness wrote:
> I'm on Debian and did a service tor reload (not restart) and tor
> crashed! I didn't realise immediately, took may be a minute to realise
> and restart. Anyway apologies to any connections that were going
> through this relay.
> 
> Should I report a bug to Debian?

First check your logs -- it's likely that it's not a crash, but rather
Tor read the new torrc file and either couldn't parse it or refused to
switch to the new parameters.

> Also, this morning, my relay is back up, but no longer with HSDir
> flag. Is this due to setting that option in the torrc file? And if so,
> I guess it is recommended to disable that option?

To disable which option? You should leave HidServDirectoryV2 alone in
general, and let the Tor directory authorities decide whether you're
stable enough to be used.

--Roger

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

Re: [tor-relays] (no subject)

[Roger Dingledine]

On Tue, Feb 25, 2014 at 02:27:22PM +1100, Zenaan Harkness wrote:
>  tor
> should never stop running (or crash) with just a config file reload!

Alas, I disagree. The alternative is that it *doesn't* stop running,
yet you think it's using the new torrc file when it isn't. That would
be a worse kind of surprise.

Unless you have a third alternative that is better? I agree that the
current state is not great.

That said, we *do* have a partial answer, in the init script itself -- it
runs Tor with --verify-config to make sure that the config file itself is
parseable. So the remaining trouble is when the config file is parseable,
but the requested changes are incompatible with Tor's current state.

> DisableDebuggerAttachment 0
> 
> This is the only change, the one which subsequent to adding that
> option, and running service tor reload, tor apparently stopped
> running, as above.

Yes. Please read your Tor logs where it explains why.

https://www.torproject.org/docs/faq#Logs

> So the only change that I am aware of that could have caused the HSDir
> flag (as shown in arm) to go away, was either that option
> (DisableDebuggerAttachment 0), or simply the fact that the relay
> crashed (or somehow otherwise stopped running).

It's the latter -- the HSDir flag is a function of the stability of your
relay. See
https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1867

--Roger

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

Re: [tor-relays] new relay acting strange

[Roger Dingledine]

On Thu, Feb 27, 2014 at 05:24:13AM +0100, Athena Lester wrote:
> Hello,
> This is the first tor relay I have set up, it has been running for going on 4 
> days. I was waiting for the 3 day lag period I have read about but still no 
> activity, besides the 30 MBs or so per day. It is running on my vps located 
> in the Netherlands. The thing that is strange is when I search for 
> "windywillow" on the atlas it finds two relays, same ip's, same ports. the 
> thing is they both say that the server has been down for the last 3 days when 
> it has been running and recieving a trickle of activity with no adverse log 
> entries. I noticed a day ago that I lost the "Valid" flag. nothing has 
> changed as far as know since it was valid so I'm at a loss.  Here are the 
> links to the two atlas pages.  Any help would be appreciated.
> 
> https://atlas.torproject.org/#details/F51A8E6C811D3C8F2436BE0029E95E67CB0DF3D0
> 
> https://atlas.torproject.org/#details/90B97451822C0881C0652A7DA7430A73BCAF3769

This url:
https://metrics.torproject.org/relay-search.html?search=5.178.64.203
shows that it started out with the F51A... identity key, was in the
consensus for one hour, and then switched keys (perhaps you reinstalled,
or you started running the Tor daemon with a different DataDirectory?),
and then it was in the consensus two times a few days ago with a new key,
and that's it.

Ah ha!

You advertise an ipv6 address:
or-address [2a00:1ca8:37::d85a:e8d5]:29888
which appears to be unreachable.

You are the second person to have this problem -- the directory
authorities are choosing to mark you as non-Running because not all of
your addresses are reachable. I wonder how we can make it more obvious
to the relay operator when this situation occurs?

--Roger

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

Re: [tor-relays] External connections to port 9050

[Roger Dingledine]

On Thu, Feb 27, 2014 at 11:39:55PM +0100, Jeroen Massar wrote:
> On 2014-02-27 23:12, Greg W wrote:
> > I turned on some logging on my firewall today to help troubleshoot and
> > issue and noticed a load of connections from external addresses to port
> > 9050 on my exit node. I don't think that should be publicly accessible.
> > Am I wrong about it being publicly accessible and does anyone else see
> > lots of connection attempts on that port?
> 
> 9050 is the standard relay port, as other relays connect to your relay
> (and then, likely, exit), it is quite logical that you see those
> connections.

No, 9001 is the standard relay port. 9050 is the standard socks port.

Greg, try connecting to 9050 from outside your firewall, and see what
happens?

I think what you might be seeing is that some folks who sell lists of
open proxies have decided to scan Tor relays on port 9050, just in case
they left it open.

--Roger

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

Re: [tor-relays] External connections to port 9050

[Roger Dingledine]

On Fri, Feb 28, 2014 at 09:22:10AM -0600, Greg W wrote:
> Roger,
> 
> You've confirmed my thoughts. I suspected that some people were bulk
> scanning relays/exits looking for open proxies too which is why I was
> curious if any other operators were seeing this. Thus far today I've got
> 175,000 connection attempts from 220 distinct IP addresses. I think I'll be
> sending some abuse emails and writing a new fail2ban rule!

Great! Except, please hesitate before sending those abuse mails --
isn't that exactly the sort of thing that makes it hard for people to
run Tor exits? :) We've only got this one Internet.

--Roger

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

Re: [tor-relays] is comcast throttling relays?

[Roger Dingledine]

On Fri, Feb 28, 2014 at 09:35:40PM -0800, Steve Rich wrote:
> I think you guys are right, thanks.
> 
> The question I have now however is, should I set my RelayBandwidth limit to 
> 250k?
> 
> Currently the advertised bandwidth is 1MB/s, which doesn't see right.

You should definitely rate limit (both rate and burst) to slightly
under your actual capacity, especially if you're on an asymmetric link
like comcast.

Otherwise your relay happily reads plenty, since the download is so fast,
and then drops it all on the floor when it tries to upload it again.

For many more details here, see my HAR 2009 video:
https://blog.torproject.org/har2009-video-tor-performance

--Roger

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

Re: [tor-relays] Are zealous connections to directory port common?

[Roger Dingledine]

On Fri, Mar 14, 2014 at 12:23:50PM -0400, Tora Tora Tora wrote:
>  Why would any IP address need
> more than one (or several simultaneous) connection is beyond me.

See https://trac.torproject.org/projects/tor/ticket/9969 for one case.

I wonder if these are clients running Tor versions from back before we
did directory fetches tunnelled over the ORPort -- clients from that long
ago would launch quite a few requests to the DirPort of various relays,
and since we disabled the v2 directory status documents, maybe there's
a bug where they keep asking if they don't have anything they like.

--Roger

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

Re: [tor-relays] new fingerprint after update

[Roger Dingledine]

On Sat, Mar 22, 2014 at 03:26:07PM +0100, Oliver Schönefeld wrote:
> i updated from Tor 0.2.3.25 (relay 266C0CADC79F802C554019887324A57332A1DA70) 
> to Tor 0.2.4.21 yesterday and the relay fingerprint changed to 
> 07E333A3B979C27739096C5B2EE10D7C8E3D8FFD.

https://www.torproject.org/docs/faq#UpgradeOrMove

> I looked in the manual and tried adding a DirAuthority line in the torrc 
> file, which looks as the following:
> DirAuthority 123tor *:9030 FINGERPRINT
> 
> But then Tor doesn't start.

Yeah, that's not at all what DirAuthority is for. Can you help us
understand what made you think this was a good idea to try, so we can
fix it in the man page? :)

> I also tried writing the old fingerprint in the fingerprint file,
>but it's changed to the new one everytime i start Tor.

Hopefully the above faq entry helps.

Thanks for running a relay!
--Roger

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

Re: [tor-relays] Best price/efficiency ratio

[Roger Dingledine]

On Sat, Mar 22, 2014 at 10:33:01PM +0100, Rick Ross wrote:
> Question how long you'll stay in the Top 50. Maybe you are lucky but
> probably the ISP will end your contract for "abusing" fair use
> policies/TOS. Best case they'll throttle you down. Let us know in 30 days :)

Or maybe more than 30 days -- once it gets the Guard flag, which it should
do real soon now, it will have a temporary dip before it grows higher.

https://blog.torproject.org/blog/lifecycle-of-a-new-relay

--Roger

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

Re: [tor-relays] Relay configuration for FreedomBox

[Roger Dingledine]

On Sat, Mar 22, 2014 at 01:03:43PM -0700, Lance Hathaway wrote:
> On the plus side, obfs3 is still pretty strong, and it's one of the
> common pluggable transports right now. Scramblesuit is not live in the
> official bundles yet (AFAIK), but it just released and has some pretty
> robust-looking defenses against active probing and other attacks. If
> you're working on something new to deploy, these should be included,
> without a doubt. They may indeed be deprecated in future, and in the
> worst case may become unusable or make the bridge more susceptible to
> being blocked. But if you go with a plain bridge or obfs2, you're
> already in your worst-case scenario. You have nothing to lose and
> everything to gain by enabling the newest pluggable transports.

Agreed. If the goal in setting it up as a bridge is to be useful to
users who are otherwise censored from the Tor network, then running
pluggable transports like obfs3 and ScrambleSuit will go a long way
towards actually doing that.

For context, currently Tor works out-of-the-box (you don't even need a
bridge) in nearly all countries except China, where vanilla bridges and
obfs2 don't work currently:
https://blog.torproject.org/blog/how-to-read-our-china-usage-graphs

Periodically Iran and Syria block SSL by DPI, which also takes out
vanilla bridges.

If you want to be conservative, pick obfs3 and wait for ScrambleSuit
to get more mature.

> I would highly recommend adding the Tor package repository to the
> FreedomBoxes. As explained in [0], this won't always give you the
> latest version of tor, but it will provide security fixes. My hunch is
> that it will almost always also be a little fresher than Debian
> stable.

Yes -- I would consider doing this as much for security as for anything
else. Debian stable can lag pretty far behind the actual Tor stable
releases (depending on which year you're looking).

--Roger

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

Re: [tor-relays] Relay configuration for FreedomBox

[Roger Dingledine]

On Tue, Mar 18, 2014 at 10:59:30PM -0400, James Valleroy wrote:
> The FreedomBox project [1] is planning to include Tor in the upcoming
> 0.2 release. FreedomBox is intended to be used as an always-on server,
> so its Tor node has been configured as a bridge relay.
> 
> There is also a need for FreedomBoxes to be able to find each other
> regardless of location or restrictive firewall. This feature is not
> yet completely implemented for FreedomBox, but it will likely involve
> each box running a Tor hidden service, and making the initial
> connection to other boxes over the Tor network.

Running as a bridge and a hidden service at the same time is likely fine,
but you should read through
https://blog.torproject.org/blog/protecting-bridge-operators-probing-attacks
to be aware of some potential issues there.

In short, running the bridge could make it easier for somebody
to guess-and-check whether that hidden service address is
associated with that bridge. So if the hidden service is primarily a
reachability-despite-NATs thing, rather than a "you'll never find out
where I am" thing, sounds great.

> Here is the configuration that we are currently using in /etc/tor/torrc:
> 
> ORPort 4431
> BridgeRelay 1
> Exitpolicy reject *:*

Are these things going to be on the network directly, i.e. without
requiring manual port forwarding by the operator? If so, you might
explore whether you prefer "ORPort auto" for more variety.

Also, if these things are going to *be* the network connection (I've
lost track of what all freedombox might be), you might also look at the
contributed traffic priority script:
https://gitweb.torproject.org/tor.git/blob/HEAD:/contrib/linux-tor-prio.sh
but a) if it's just a bridge, it's probably not so big a deal in terms
of competing with the user's traffic, and b) it looks like that script
really wants you to tell it about the network's speed, which will be
hard for you to guess. So nice idea in theory, but probably not worthwhile
in practice.

--Roger

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

Re: [tor-relays] Exiting only port 8333

[Roger Dingledine]

On Mon, Mar 17, 2014 at 09:39:05PM +0100, Mike Hearn wrote:
> I would like to be an exit for port 8333 only. I have configured my relay
> to do this, but I am not being listed with the relay flag and do not see
> any traffic exiting my node (at least not using arm). I saw an FAQ that
> says this is because you have to exit web traffic to get marked as an exit.
> I do not wish to do this.
> 
> Is there any way to exit just one port?

Your exit policy means that you would allow a stream to exit if a
client asked you for it. The trouble is that most Tor clients build
their circuits preemptively -- before they know what destination stream
they'll be asked to connect to. The Exit flag is an approximation for
"probably will be able to handle whatever stream request shows up".

So your relay will actually get used in practice for exiting, in
the case where the client doesn't have any currently open, adequately
fresh circuits that would allow exit to port 8333. In that case it will
make a new circuit, choosing from all exits whose exit policies allow
that stream. But so long as things are going smoothly, there should be
preemptive circuits around and ready, so this case should be rare.

Another reason for the Exit flag is to help clients do load balancing --
e.g., avoid putting traffic for the first and second hop on relays that
probably have other clients putting traffic on them for the third hop.

https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.BwAuthorities
https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt

In that sense, you actually don't want the Exit flag for your relay,
because it would make clients less likely to use you for their first and
second hop, because they'd figure you're busy handling exit streams for
other people.

The challenge there is that to do this load balancing more accurately,
we have to have an accurate model for what total network load to expect
for a given exit policy, so clients can take it into account. Since
it's hard to know what that model should be in practice (see
e.g. http://freehaven.net/anonbib/#cset12-modeling for more discussion
there), and also it's especially hard to predict how it should change
over time, it seems to me that a really simple approximation is more
likely to be robust.

Hope that helps to explain the tradeoffs,
--Roger

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

Re: [tor-relays] Why would consensus weight would be declining like this?

[Roger Dingledine]

On Tue, Mar 18, 2014 at 05:02:07PM -0400, Tora Tora Tora wrote:
> Declining dramatically
> 
> https://atlas.torproject.org/#details/90743CFA1B93295B9334CC0C625D22990AABA25F
> 
> vs
> 
> https://atlas.torproject.org/#details/CC2F7C6ED12B67CB3882B98213E02DEF2CB82293
> 
> that is holding steady

A fine research question. A lot of the questions from
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
apply here too.

One theory is that it's a result of variance -- they're both relatively
small relays, so one stream that uses lots of bandwidth and randomly
happens to pick this relay could be enough to skew a few bandwidth tests,
pushing you down for a while.

In theory it should recover, since both relays are publishing similar
underlying self-measured bandwidths:
https://exonerator.torproject.org/serverdesc?desc-id=825feea5d643a228e121d0fbfdecf47acff4870f
https://exonerator.torproject.org/serverdesc?desc-id=ec726fe88dbc60d18b3402fff2bace3564292546

But it might take quite some time to adjust, since the bandwidth
authorities don't measure very often.

--Roger

___
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

[Roger Dingledine]

On Sat, Mar 15, 2014 at 02:56:36PM -0800, I wrote:
> You should at least change the ssh port immediately now that you have
>published the address.

No, this is bad advice.

First because Tor relays (and their addresses) are public anyway.

And second because having an ssh port exposed to the Internet will draw
enough scans that it had better be secure, regardless of whether running
a Tor relay nearby to it draws any more attention to it.

(Please don't spread fud about the risks of running relays. Especially
as there *are* risks, like any other Internet service.)

--Roger

___
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

[Roger Dingledine]

On Sat, Mar 15, 2014 at 08:46:44PM +, eugene zhukovsky wrote:
> I am trying to setup Tor relaying, but it doesn't work so far.
> Windows 8, private vpn.
> I opened ports 80,443,9001 and 9030 (both TCP and UDP) on my Comcast router
> to be forwarded to the box I'm trying to configure.
> I added inbound and outbound rules in the firewall setup for ports
> 80,443,9001 and 9030 (both TCP and UDP)
> but I'm still getting
> 
> Mar 15 15:30:58.654 [Warning] Your server (62.210.167.197:443) has not
> managed to confirm that its ORPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.
> Mar 15 15:30:58.658 [Warning] Your server (62.210.167.197:9030) has not
> managed to confirm that its DirPort is reachable. Please check your
> firewalls, ports, address, /etc/hosts file, etc.

Hi Gene,

Assuming your relay is still running, it sure is acting weird. Port 443
answers but doesn't do anything useful, and port 9030 doesn't answer
at all.

I'd say your best bet (since there was quiet here) is to show up to irc
and see if people can help you in a more interactive way.

https://www.torproject.org/about/contact#irc

Thanks for wanting to help,
--Roger

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

Re: [tor-relays] "Invalid length on ESTABLISH_RENDEZVOUS."

[Roger Dingledine]

On Tue, Mar 04, 2014 at 07:12:36PM -0500, Tora Tora Tora wrote:
> I am testing 0.2.5.2-alpha for non-exit relay and seeing lots of
> "Invalid length on ESTABLISH_RENDEZVOUS" errors. Any cause for
> concern?

Should be harmless, and hopefully we'll fix it sometime. I've opened
https://trac.torproject.org/projects/tor/ticket/11279

Thanks!
--Roger

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

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

[Roger Dingledine]

Hi Christian, other tor relay fans,

I'm looking for some volunteers, hopefully including Christian, to work
on metrics and visualization of impact from new relays.

We're working with EFF to do another "Tor relay challenge" [*], to both
help raise awareness of the value of Tor, and encourage many people to
run relays -- probably non-exit relays for the most part, since that's
the easiest for normal volunteers to step up and do.

You can read about the first round from several years ago here:
https://www.eff.org/torchallenge

To make it succeed, the challenge for us here is to figure out what to
measure to track progress, and then measure it and graph it for everybody.

I'm figuring that like last time, EFF will collect a list of fingerprints
of relays that signed up "because of the challenge".

One of the main pushes we're aiming for this year is longevity: it's
easy to sign up a relay for two weeks and then stop. We want to emphasize
consistency and encourage having the relays up for many months.

So what are the things we'd want to track?

- Number of relays signed up that are Running, over time.
- Total bandwidth history of these running relays, over time.
- Maybe a graph showing the total number of bytes ever contributed
  by these relays? That would impress people perhaps.
- Total consensus weight of these running relays, over time.
- Something emphasizing duration -- e.g. the total consensus weight of
  the subset of the relays that have been in the consensus for 90% of
  the past month, 2 months, 6 months, etc. Are there better ideas here
  I hope? We'll want to be cognizant that if we're in the first week
  of the challenge, the 2 month graph will be empty and thus look sad.
- Something comparing the above numbers to the total numbers. Given how
  huge some of the relays are lately, it would be easily to visualize
  the new contribution as a tiny irrelevant fraction, which could be
  disheartening to new relay operators even if their relays will actually
  become a big deal with some patience. What are some strategies for
  making this work right? E.g. a layer graph showing y layered on top of
  x where y is the new contribution, rather than a percentage-of-total
  graph that shows approximately 0%.

We could also imagine more niche categories. For example, if we're hoping
to get people to sign up relays at universities, we could imagine that
the folks running the challenge give us a list of fingerprints of relays
that self-identify as being at universities, and then we do up the same
set of graphs with that subset of relays.

So, Christian, others, how much of this is possible as-is or with some
limited tweaking, with Globe and related scripts? I am hoping the answer
is most of it. :) I also cc Karsten because a lot of this overlaps with
the metrics scripts, but I am expecting Karsten to push back against
the idea of integrating these measurements more with the metrics project.

Any other ideas for what to measure to help people know whether their
contribution is being worthwhile?

[*] Please don't take this mail as any official announcement, or timeline,
or any of that. At this point we need to collect people to help make
this happen, not collect news stories.

Thanks!
--Roger

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

Re: [tor-relays] Avoiding sinkholes

[Roger Dingledine]

On Fri, Mar 28, 2014 at 08:36:06AM +0300, r...@goodvikings.com wrote:
> It's on that list since at some point a botnet talking through tor to
>its C&C server used my exit node to do so

Actually, it could easily have been a computer security researcher who
used Tor to access that address, not realizing the collateral damage he
was triggering. A growing number of malware researchers and antivirus
companies use Tor to reach various parts of the Internet, because
otherwise the bad guys recognize their IP address and special-case them.

As Moritz says, this is alas not an easy game to win. Not long ago
I learned that the .mil domain refuses to hear any packets from my
computer, which runs one of the directory authorities (and it's not
even an exit relay!). That meant my postfix became convinced that all
mails to or from .mil addresses were spam, since their name doesn't
resolve. Bad news for the Navy researchers who are signed up to, say,
the petsymposium.org mailing lists.

The real fun is going to start when these blacklists try to bully us by
blacklisting the whole /24 nearby, in hopes that our neighbors will lean
on us to cut it out.

I still enjoy rereading http://paulgraham.com/spamhausblacklist.html as
linked from https://www.torproject.org/docs/faq-abuse#TypicalAbuses

--Roger

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

Re: [tor-relays] tor relay recommended upgrade procedure?

[Roger Dingledine]

On Sun, Mar 30, 2014 at 11:21:02AM +1100, Zenaan Harkness wrote:
> > The Debian install script evidently gives tor 30 seconds to
> > disconnect, since it did stop tor after 30 seconds.

This is actually Tor's behavior. From the man page:

   ShutdownWaitLength NUM
   When we get a SIGINT and we're a server, we begin shutting down:
   we close listeners and start refusing new circuits. After NUM
   seconds, we exit. If we get a second SIGINT, we exit immediately.
   (Default: 30 seconds)

But you're right that the Debian init script has a bound on the time
it will let Tor sit around before it gives up and declares that it has
failed to do what you asked. See:
WAITFORDAEMON=60
in /etc/init.d/tor

> > HOWEVER: killing tor in 30 seconds seems to me a little harsh on all
> > those anonymous connections that were previously going through my exit
> > relay. Can those clients (if they need) pick up their connections
> > after about 3 minutes? It appeared that all connections were
> > completely gone when I finally got tor restarted

As soon as your relay goes away the circuits will be cut, and the streams
that clients had on those circuits will be cut too. Whether those clients
will automatically reconnect those streams on new circuits depends on
the application.

> > Is there are a gentler way such as "don't take new connections, notify
> > clients we are going down for an upgrade" but allow continuation for
> > say up to 10 or 30 minutes?

You could set ShutdownWaitLength to something much larger. You'd want to
either do a controlled shutdown of Tor on your own, or modify the init
script so it knows you raised the value of ShutdownWaitLength.

> There is of course MaxAdvertisedBandwidth -
> so ought this option be set to say zero for say 10 or 20 minutes,
> before stopping/upgrading the server (either manually by admin, me, or
> assuming admin config allows this)?

No, a change to the advertised bandwidth of your relay will take hours
to propagate to clients.

> > Would that be better or could that be worse eg for privacy,
> > correlation attacks etc?
> 
> Should I forward this question (or rather, create a thread) "optimal
> tor relay upgrade protocol" on tor-talk?

This list is the better choice.

--Roger

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

Re: [tor-relays] Lots of tor relays send out sequential IP IDs; please fix that!

[Roger Dingledine]

On Mon, Mar 31, 2014 at 11:12:05PM +0200, Jann Horn wrote:
> Well, the subject line pretty much says it all: Lots of Tor relays send out
> globally sequential IP IDs, which, as far as I know, allows a remote party to
> measure how fast the relay is sending out IP packets with high precision,
> possibly making statistical attacks possible that could e.g. pinpoint the 
> entry
> guard a user or hidden service uses.

[Please don't cross-post on multiple lists -- you will splinter the
responses.]

For extra fun, check out this paper that turns this issue into a potential
anonymity attack:
http://freehaven.net/anonbib/#tcp-tor-pets12

Their suggestion for a fix iirc was that the Linux kernel should get
fixed.

--Roger

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

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade

[Roger Dingledine]

On Tue, Apr 08, 2014 at 07:00:53PM +0200, Andreas Krey wrote:
> On Tue, 08 Apr 2014 17:01:18 +, Moritz Bartl wrote:
> ...
> > immediately, especially larger relays. But don't worry too much, you'll
> > get your flags back eventually. :)
> 
> But my name only very eventually?

Correct.

Actually, I'd like us to take this opportunity to throw out the Named
and Unnamed flags entirely. I think we've done pretty well at teaching
users to use $fingerprints rather than nicknames in the few cases where
they actually want to specify a particular relay.

And only two-ish directory authorities still track and vote about Named
and Unnamed, so it's not like we're getting an actual robust consensus
these days about what nickname should map to what key.

It would be great to have somebody think through the implications of
what exactly we'll lose by dropping them, so we can make a more informed
decision. Maybe that could be one of you? :)

--Roger

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

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade

[Roger Dingledine]

On Tue, Apr 08, 2014 at 04:35:39PM +0100, mick wrote:
> Moritz Bartl  allegedly wrote:
> > Yes. You made it generate new keys, so it is a "new relay" as far as
> > Tor is concerned. This is why not everybody should generate new keys
> > immediately, especially larger relays. But don't worry too much,
> > you'll get your flags back eventually. :)
> 
> But Roger's blog post makes no mention of the advisability (or
> otherwise) of a mass re-generation of keys. All it says is that best
> practice states this would be a good idea.

The first iteration of my blog post said something like "if you run many
fast and stable relays, consider spreading out your relay identity key
replacement over the next week so we don't unbalance the network."

But I removed that sentence a little while later, when it became clear
that nobody knows for sure but quite possibly an attacker could have
extracted key material from vulnerable relays. If that actually happened,
I think we probably want new identity keys asap, *especially* from the
big relays, and we'll be happier tolerating a couple of bumpy days while
the network recovers.

Fun times,
--Roger

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

Re: [tor-relays] URGENT: active OpenSSL "Heartbleed" attack on Tor Nodes

[Roger Dingledine]

On Tue, Apr 08, 2014 at 06:30:28PM -0400, starlight.201...@binnacle.cx wrote:
> Have been running Tor relay with
> AddressSanitizer and it crashed this
> morning.

People on #tor are helping us enumerate vulnerable relays, so while this
plausibly is an instance of "somebody testing for the vulnerability",
it doesn't tell us much more about whether bad guys are doing attacks too.

> Anyone running a Tor relay with OpenSSL
> 1.0.1 should update the library or
> rebuild against an older version
> immediately

Agreed.

You probably want to discard your relay identity keys afterwards too.

See the big threads about exactly this topic.

--Roger

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

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade

[Roger Dingledine]

On Tue, Apr 08, 2014 at 07:31:43PM -0600, Jesse Victors wrote:
> I'd recommend that every relay operator delete their keys as well,

Not every. Those on OpenSSL 0.9.8, e.g. because they're using Debian
oldstable, were never vulnerable to this bug. I imagine there are some
FreeBSD or the like people out there in a similar boat. And Centos
people, etc.

--Roger

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

Re: [tor-relays] NSA knew about Heartbleed

[Roger Dingledine]

On Sat, Apr 12, 2014 at 08:45:23PM +, Delton Barnes wrote:
> "Two sources familiar with matter" could merely be two computer security
> experts who have an unsubstantiated opinion that the NSA was exploiting
> this beforehand.  We have no idea how credible these sources are.

I agree.

I'm assuming that particular article is nonsense until somebody shows up
with some actual details. I guess it's hot to point at NSA conspiracies
these days. But doing it in this case undermines the *actual* NSA
conspiracies that we should indeed be upset about.

Maybe there *is* yet another NSA conspiracy here, but I don't believe
in one any more after reading the article than before it.

> That said, if you carefully parse the statement from DNI, it seems to me
> to imply they were aware of the Heartbleed vulnerability in 2014.  Why
> would they say "before 2014" instead of "before its disclosure Monday"
> or something?

Careful here -- the article is selectively quoting, maybe to stir things
up more. The actual phrase from the DNI denial is "before April 2014".

In any case, the conclusion ("oh crap, upgrade and throw out your
old keys") is still accurate.

--Roger

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

[tor-relays] Rejecting 380 vulnerable guard/exit keys

[Roger Dingledine]

Hi folks,

I'm attaching the list of relay identity fingerprints that I'm
rejecting on moria1 as of yesterday.

I got the list from Sina's scanner:
https://encrypted.redteam.net/bleeding_edges/

I thought for a while about taking away their Valid flag rather
than rejecting them outright, but this way they'll get notices
in their logs.

I also thought for a while about trying to keep my list of fingerprints
up-to-date (i.e. removing the !reject line once they've upgraded their
openssl), but on the other hand, if they were still vulnerable as of
yesterday, I really don't want this identity key on the Tor network even
after they've upgraded their openssl.

If the other directory authority operators follow suit, we'll lose about
12% of the exit capacity and 12% of the guard capacity.

I/we should add to this list as we discover other relays that come
online with vulnerable openssl versions.

Also these are just the relays with Guard and/or Exit flags, so we should
add the other 1000+ at some point soon.

--Roger

!reject F4E5A0C6C4D16FC99A3BDFD21896CE235647B97B
!reject 12F8D3D730EF098DD2233C138A0E131BA677F850
!reject 40295942E7FD178041195ADA13211D44F60D095A
!reject E163ADFB3423032D1BD3C1F6DD11CB2CB681581C
!reject BA998001D8F8E82EEFBDFA209EF57C0D6ED43F03
!reject A0FD1D7BDDB6625415CAC276B2F697870C27D054
!reject 6B53D408A434C2410FADA8224097CC60A441F7C5
!reject 350A0BD2E19CB579AFA07044CCE36AA745E0D4A1
!reject B264587B3111E164F13BEEB3E6384BEB090A79C6
!reject 159B02C7E7A1C25ADFCACE1FBCDA4BE5409208A0
!reject F704E08CC17216B0C43200182251ACF9AE6470C4
!reject 52C4B4640D3C82C5AA9C8CA25B488EBB4D0CBD34
!reject 2619F0A7B8A30158508A0F2F62337CEAE59CA811
!reject 9D172726FFD5137AEECF8743531A74920D9EE47E
!reject D0CB7037D93347670186891DDFBB6E9A7EB07D30
!reject 871AAA5F1C35A079FECE244CDC57B60715FD9E2F
!reject 47CF431990A13D704E741EC2A758A6217BC83231
!reject 84B1DE82F5CCA2BF48EE7FFA6D945BF07B18
!reject 752E45EA529780870B86A7CC0D2F87AC261F5D61
!reject BA2E24BFBC252309147F17B8E857803068AAD9F0
!reject C6AB4DAD86C2B174BFF80C6632D10EB622FF3929
!reject D9BD073372A673F82D6A8CF52816007BBA079C83
!reject 9FDA5E5A3592E67971DE2CA814876047B19BFEB9
!reject FA8D3B3037E87F748B3136C50A80286E9001C9A7
!reject CC881BD62788C109CD80A1465663AC7D0E4713A8
!reject 9806173149269DA95A8F20026E24D731CDFCF3A6
!reject 267A1B3B125777B95EAA3FE7CA12F72A0A151114
!reject A2651BA4D07DD170B5D98286CAED4DC49F6C5250
!reject 675CA53EFDAA0FAA5548185E0075467AEBA985C6
!reject 022ECEFCB8579C0781DD853C8EF800DF4DDBAE2E
!reject 9B33BF08D4DFEEB950CFA29988147C94047854F8
!reject 04DD268043A964B70A20522E06D0120DED6693C3
!reject 0C63FD6B10D3A69075023306AE4D8CC1B4798FA5
!reject 5A0EF08FC99F236C5E48FB52E649F092088D009C
!reject FCEB0DE6A6F39C1702A14C49DD89EE71C01D4030
!reject 56A9793DB3419A91E8CB1D8B9A12716EE2BCD680
!reject 59F17DCACB73AC04B7556A9C96992CCE25F23361
!reject F3528AA125ECE6CB9E51178839ACA327ACA115C2
!reject 9AB511B6894566C1CF56043CE60077D213CF1A1A
!reject EB179ADFC3D48D9C91F589B5F608F6B83FAEF9A2
!reject 2E82398CCD16B2370B9A22D5A77DF23953818133
!reject 753CE4C36BADF440E9BBB3E75725AAD9444B16CA
!reject D8CE3F0FFE2A62666237EC5C707B478F543DE993
!reject 10D3D623F1EA0AD53BFBE8F524FC98C356D641B1
!reject BC61403552B104B858087FD8A1C28E2FB936B11A
!reject 3DD231994EA5AAD21B5C5F24F42CED792E4C863E
!reject 906B7EC12E84909D9FE791BF8FE7776D9DA68BA6
!reject 0ED5D4583C4C1B89158983C456686A516DF547C7
!reject B1844022C451790EEE0488E8B457295A8B4FED0B
!reject 7CD747FAC2606289C7C5A697D56783CA7E1CFD43
!reject 7FDBB23959F9BF1FEDD616D81F1C3F006A308615
!reject 8E0038A1389F87FCE92A1ADC683118A111CF75AD
!reject 530C7B75A491C27142CC6DA9783F4B6C8E12801A
!reject E44B751CF8DB08EACD0EDF7492E6FADAAFBD2BF1
!reject 9A13BC3189C5CA80E1C7D302609692D507F7F23A
!reject 8C42C633ECA9092875CA3F36B2CCF64C5D8A1BF7
!reject 575E996F84E5AAD229A599488ADA7266424D6716
!reject A0E9707331B0DA4168A5AD56794464D7CBCA8DE1
!reject 2226B5E9EACA6D145CDDA6CD0C26D6116D9130E1
!reject 2FC4B4F42E3092B6BD1E946956608D4E75492E49
!reject 4ED18C3739170D0D9D92DD0B056BEE2FB1FE6614
!reject BB45741133305A6B66E3C4DF99E7C9B863D54CBE
!reject E5E2F5DD193CCDBF4C80F52557D3A1F13260A64A
!reject AF3B568FFD839BF009997C06789F23C278C1F7B4
!reject 59D5AE2B295BE328B3390ACE70DC2DA643159B9F
!reject 5C288A412ABDECC121E476563A1176395C6E33EF
!reject 472C713E1B47A1490FD9E37D704D7B486F4C1F81
!reject 84E13FA9DB4781AE2A251B856C4CACB2ED0E2EC7
!reject 46313EF43C4E49171FAD75A3737B34A2CAB7C35F
!reject 8F71D03CE8AA8F0D4B548294B85ABA5A98E19B92
!reject 913AB76AADBC921DC6D3B07D084E7E82EFAE04F7
!reject 6DAABD45F218E1F110EE6722240571E98B77A741
!reject BD802D886F8E49A274967FDB6975749FFA4844BD
!reject C34CCB5236821F52F62EF3A110DCF20F4B2AC025
!reject 0B65BDAD97310FCA25F793EEDE78E80433772AB9
!reject 92F958BABE181EB41E362E2A608C9CFA3CB2539D
!reject D679D2953A977C4416E30E3032D7BA79361E7B4B
!reject 4B5A811E250B640C290C45BC7A4BB4F4B1C88E29
!reject 38169A8751F22CA38CD11C8F0B1C0E0F55B816EC
!reject 315D5684D5343580D409F16119F78D776A58AEFB
!reject 1C05ACAA138797EDA5AC3527C1198648D81C182B
!reje

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

[Roger Dingledine]

On Wed, Apr 16, 2014 at 08:03:51PM -0700, Andrea Shepard wrote:
> > http://charon.persephoneslair.org/~andrea/private/hb-fingerprints-20140417002500.txt
> 
> The SHA-256 hash of that file, for the sake of stating it under a PGP
> signature, is:
> 
> dadd2beca51d1d5cd7ffe7d3fe3a57200c7de7e136cad23b0691df2fbe84ee3f

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

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

--Roger

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

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

[Roger Dingledine]

On Fri, Apr 18, 2014 at 01:40:17AM +0200, Tobias Markus wrote:
> Tor circuits (a "way" through the Tor network) and thus nodes are
> entirely chosen by clients based on the consensus given by dirauths
> (see my earlier post). The ExcludeNodes statement you use basically
> instructs the Tor *client* part not to use the specified nodes in
> their circuits.
> 
> If you run a relay, you don't have to undertake any action because of
> Heartbleed except rotating your keys (deleting all keys in
> DataDir/keys), updating OpenSSL and restarting Tor. (Moritz Bartl sent
> an E-Mail to tor-relays explaining all this in great detail on
> 4/8/2014: "Relays vulnerable to OpenSSL bug: Please upgrade")

Correct.

--Roger

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

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

[Roger Dingledine]

On Thu, Apr 17, 2014 at 12:17:02AM -0400, Roger Dingledine wrote:
> Thanks Andrea. 374 of the 380 lines from Sina's file overlap with yours.
> 
> I've moved moria1 to reject the union of the two lists.

Four other directory authority operators have also blacklisted these keys,
and they've now been dropped from the network.

For comparison, we moved from 5421 Running relays earlier yesterday,
to 4354 Running relays now. Many of the affected relays were tiny,
but there sure were a lot of them.

In the future, when we catch our breath a bit more, I'll start logging
the rejected descriptors, and send another round of mail to everybody
who set their ContactInfo to let them know to dump their keys and upgrade.

Oh, and since it's going to confuse people, at the same time as this
change we also have been cutting relays running Tor 0.2.2.x out of
the network:
https://trac.torproject.org/projects/tor/ticket/11149
That's currently ~240 relays, but again they're mostly quite small.
https://metrics.torproject.org/network.html#versions

--Roger

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

Re: [tor-relays] Relay down, "rejected", help

[Roger Dingledine]

On Sat, Apr 19, 2014 at 09:19:26AM -0700, kbesig wrote:
> Install of tor-arm went well enough, no error msg's.
> 
> ~$ sudo -u debian-tor arm

You're using arm dangerously. See item #14 on
https://www.torproject.org/docs/tor-relay-debian
for the safer way to run arm with your Debian / Ubuntu relay.

And you'll want to follow the other instructions on that page too.

Also, I have no idea what all you might have messed up with your attempts
to do things the wrong way, so you might need to back some of those
changes out too.

Good luck, and thanks for running a relay!
--Roger

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

Re: [tor-relays] Relay down, "rejected", help

[Roger Dingledine]

On Sat, Apr 19, 2014 at 02:15:52PM -0800, I wrote:
> >>> 
> > Wow, I always thought that *was* the "safe" way to run arm.  I wonder
> > where we both got the advice to do it the dangerous way.
> 
> from ARM
>  [ARM_NOTICE] Arm is currently running with root permissions. This is not a 
> good idea, and will still work perfectly well if it's run with the same user 
> as
>Tor (ie, starting with "sudo -u debian-tor arm").

Yep.

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

Damian is planning to revise arm at some point, but at least this part
of it has been frozen without much development for a long time now.

If you want to help out, this might be a good opportunity. :)

--Roger

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

Re: [tor-relays] Announcing the removal of Tor v0.2.2.x relays

[Roger Dingledine]

On Mon, Apr 21, 2014 at 01:36:53PM +, Nusenu wrote:
> Question arisen from looking at the relays by version graph:
> 
> If you look at that graph you see that on 2014-04-08 the number of
> relays (in the consensus) running 0.2.2.x were about zero,
> and now (2014-04-21) we are back at about 170 v0.2.2.x relays.
> 
> https://metrics.torproject.org/network.html#versions
> 
> Why is that?
> Has the decision postponed/revisited due to the concurrent reduction of
> relays (heartbleed)?

The changes are in
https://trac.torproject.org/projects/tor/ticket/11149
which is merged to git master and will be out in Tor 0.2.5.4-alpha.

So only when a majority of directory authorities are running with that
patch will the 0.2.2.x relays be cut out of the network.

But it's actually more subtle than that -- it's more accurately described
as "only when 5 or more directory authorities are online and not running
the patch will those relays be published".

https://consensus-health.torproject.org/ indicates that three authorities
are running the patch, so six aren't. If two of those six went offline,
that's enough for the remaining authorities to not put together a majority
of Running votes for the 0.2.2.x relays. It happens that two of those six
(turtles and dannenberg) *did* go offline while they were waiting to do
the openssl bug cleanup.

--Roger

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

Re: [tor-relays] Relay not gettings flags, changing IP

[Roger Dingledine]

On Mon, Apr 21, 2014 at 05:08:57PM +0200, Niels Hesse wrote:
> I updated OpenSSL, removed my keys and restarted the Tor service on my
> Debian relay.
> Now I have been running it for 3 days and I still haven't gotten any flags
> and the relay is not visible in Atlas.
> 
> Arm keeps saying:
> "[NOTICE] Our IP Address has changed from 141.101.117.220 to
> 141.101.116.220; rebuilding descriptor (source: METHOD=RESOLVED HOSTNAME=
> tor-relay.onlineprivatliv.dk)."
> 
> Here's a screenshot:
> http://puu.sh/8hBlM/71bbcb5aff.png
> 
> I am not sure what is going on here. Do you have any idea?

% host tor-relay.onlineprivatliv.dk
tor-relay.onlineprivatliv.dk has address 141.101.117.220
tor-relay.onlineprivatliv.dk has address 141.101.116.220
tor-relay.onlineprivatliv.dk has IPv6 address 2400:cb00:2048:1::8d65:74dc
tor-relay.onlineprivatliv.dk has IPv6 address 2400:cb00:2048:1::8d65:75dc

Your host resolves to two different A records.

Tor keeps changing its mind about which one it should use, presumably
because of some "randomize the order in which you return the A records"
algorithm in some resolver somewhere.

The simplest answer is to set the Address line in your torrc to explicitly
tell it your IP address. The better answer is to figure out what's up
with your hostname and fix it.

(Also, it seems like it's not reachable? But then, I'm not sure which
IP address I should be checking. :)

--Roger

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

Re: [tor-relays] Exit node rejection of special IPv4 blocks

[Roger Dingledine]

On Wed, Apr 23, 2014 at 03:12:36PM -0400, Zack Weinberg wrote:
> I'd like a sanity check on this list of special-purpose IPv4 blocks
> which I'm currently forbidding in the CMU exit node's policy.  I'm
> most uncertain about denying access to multicast (224.0.0.0/4) and
> 6to4 router anycast (192.88.99.0/24) -- I *think* there are no
> scenarios where someone would actually need to get at either of those
> via Tor, but I could be wrong.


Hi Zack,

Best practice is to only block addresses and destinations that you know
you don't want to reach. When you block addresses where somebody tells
you there should be nothing there, you're narrowing out the future. If
the RFC changes tomorrow and you don't notice, suddenly you're blocking
connections to a piece of Africa or whoever gets that IP space. And if
indeed nobody is using it, why block it?

Thanks!
--Roger

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

Re: [tor-relays] MaxAdvertiseBandwith

[Roger Dingledine]

On Wed, Apr 30, 2014 at 06:42:27PM +, jchase wrote:
> Hi,
> I have a non-exit relay running Tor 0.2.25 on a Pi. Consensus weight 37.
> exit-policy: reject *:* Now I??? back from vacation and my relay has 1600
> incoming conncts and arm warns me that my bandwidth is too small to
> support so many incomers. Would I kindly restrict my reject policy or
> limit my MaxAdvertiseBandwidth. Which I believe is no longer
> supported(?). Can anyone help me cut down on the traffic and the notices?
> J. Chase

First, there is no Tor 0.2.25 version.

But second, assuming you mean some old version, you should upgrade.

Depending on which relay you are (I think you didn't say?), this
might have happened because you got the Guard flag:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay

I'm pretty much convinced at this point that trying to run a Tor relay
on tiny hardware like this is not a workable idea. You could be a bridge:
https://www.torproject.org/docs/faq#RelayOrBridge
but I agree that's less fun.

--Roger

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

Re: [tor-relays] relay not receiving very much traffic

[Roger Dingledine]

On Sun, May 18, 2014 at 08:51:57PM +0200, Tim Semeijn wrote:
> It looks like your node is running as guard. This usually drops your traffic 
> for a   while before it builds up again.

Tim is referring to the phenomenon described here:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay

And it looks like that dip and rebuilding already happened:
https://atlas.torproject.org/#details/94F9D8D35C4A4851B1DAF85F70F90DB95065E81E

> >I deployed a new tor-relay about 2 months ago. It runs on a server with
> >2 Quad-cores, 8GB RAM and 1Gbit connection.

So yes, this is a mystery. I wonder if you have a 1gbit connection to
some parts of the Internet but not most of them?

How much bandwidth your relay uses is also a function of how much
spare capacity there is the network right now: so long as the green
and blue lines in this graph:
https://metrics.torproject.org/network.html#bandwidth
are far enough apart, then you won't necessarily be saturated with
traffic. But it's still odd that you never see spikes higher, assuming
your network can really handle it.

> >Is this normal or may I have configured something wrong?
> >
> >Last time I had a relay running I received 100Mbit+ traffic...

What are the differences between your old torrc and your new one?

--Roger

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

Re: [tor-relays] hardening a tor relay

[Roger Dingledine]

On Fri, May 23, 2014 at 06:16:56PM -0300, Noilson Caio wrote:
> Block all output like http and smtp in my netfilter (Gnu Linux);
> 
> -A OUTPUT -p tcp -m tcp --dport 80 -j DROP
> -A OUTPUT -p tcp -m tcp --dport 110 -j DROP
> etc ..

Relays need to allow connections to all outgoing ports.

If you do lines like the above, your Tor relay will be unable to reach
other Tor relays that chose port 80 or port 110 for their ORPort or
their DirPort. (People choose those ports because some users are behind
firewalls that only allow connections to those ports.)

https://www.torproject.org/docs/faq#OutboundPorts

--Roger

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

Re: [tor-relays] Confirm IPv6 Setup as Exit Node

[Roger Dingledine]

On Thu, May 22, 2014 at 10:01:19AM -0700, Adam Brenner wrote:
> For IPv4 I am running a Reduced Exit Policy[1]. Those entries are in
> my torrc file, however, Atlas is showing none of those policies[2]!

Really?

https://atlas.torproject.org/#details/6269EC22B7970ACDE4AF09F6ADE67CEB0C7F7964
looks like it's showing all your (v4) exit policy lines.

Globe:
https://globe.torproject.org/#/relay/6269EC22B7970ACDE4AF09F6ADE67CEB0C7F7964
shows them too (for maintainability reasons we are alas phasing out atlas,
even though imo Atlas's layout looks nicer).

I agree that it looks like globe and atlas don't show your accept6 line.
I've opened this ticket for this issue:
https://trac.torproject.org/projects/tor/ticket/12124

Thanks,
--Roger

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

Re: [tor-relays] Confirm IPv6 Setup as Exit Node

[Roger Dingledine]

On Thu, May 22, 2014 at 01:17:17PM +0600, Roman Mamedov wrote:
> On Wed, 21 May 2014 22:51:49 -0700
> Adam Brenner  wrote:
> 
> > I have setup a Tor exit node and IPv4 appears to work (will get a real 
> > test in the next 48 hours). I would like to confirm my IPv6 setup as I 
> > have found the documentation on this subject lacking (or my googling 
> > skills suffering!)
> 
> I googled "Tor IPv6" and the first hit is:
> 
>   https://people.torproject.org/~linus/ipv6-relay-howto.html
> 
> what exactly do you find "lacking" in that document? To me it seems to do an
> excellent job in explaining everything one needs to know in a concise and
> clear manner.

It looks like this document is a bit out of date, e.g.
https://trac.torproject.org/projects/tor/ticket/6026 has been fixed for
a while now.

If somebody here is looking for a good way to help out, perhaps you
would like to move this document over to the Tor wiki, e.g.
https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto
and then help update it?

--Roger

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

Re: [tor-relays] hardening a tor relay

[Roger Dingledine]

On Fri, May 23, 2014 at 06:30:08PM -0400, Roger Dingledine wrote:
> Relays need to allow connections to all outgoing ports.
> 
> If you do lines like the above, your Tor relay will be unable to reach
> other Tor relays that chose port 80 or port 110 for their ORPort or
> their DirPort. (People choose those ports because some users are behind
> firewalls that only allow connections to those ports.)
> 
> https://www.torproject.org/docs/faq#OutboundPorts

If anybody is looking for a good project to get used to Stem or txtorcon
and to help out the Tor network, here's a great one: build pairwise
circuits between all relays, to see which of them can reach each other
and which can't, with the goal of understanding how far from a clique
our network topology actually is, and then helping with an awareness
campaign to correct it if it's a problem.

I've written up more details and ideas here:
https://trac.torproject.org/projects/tor/ticket/12131

--Roger

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

[tor-relays] Best way for normal OS X users to run a relay?

[Roger Dingledine]

What is the best way to run a relay on OS X currently?

Now that the Vidalia bundles are deprecated and hard to find, I believe
we have no packages or bundles for OS X other than TBB 3.x?

So either "install from source, write your own init script, hope you
know what ulimit -n is, good luck with that" or "install tbb3 and edit
the torrc, still hope you know what ulimit -n is" are the current options?

Compare with https://www.torproject.org/docs/tor-relay-debian
for the Debian/Ubuntu users, where our deb takes care of a lot of these
things for them.

Assuming my summary is accurate, what are some good ways to move
forward here?

Thanks!
--Roger

___
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

[Roger Dingledine]

On Sat, Jun 28, 2014 at 09:51:08AM -0700, Kali Tor wrote:
> So, no way to offer DS while setting AccountingMax?

Correct.

At least in the scenario in this thread, not advertising the dirport
is a good choice by Tor, since it saves all your bandwidth for 'real'
Tor traffic.

The key thing to realize is that normal Tor traffic is bidirectional (that
is, it's symmetric -- it comes in and then goes out again), but traffic
you serve over your DirPort is only unidirectional. So you'll reach your
accountingmax quicker while wasting (not using) half of that bandwidth.

See also
https://trac.torproject.org/projects/tor/ticket/871

--Roger

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

Re: [tor-relays] 'relay early' attack detection at the infrastructure level

[Roger Dingledine]

On Fri, Aug 01, 2014 at 10:08:41PM -0400, krishna e bera wrote:
> According to
> 
> https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
> 
> the RELAY_EARLY cell has common legitimate uses.
> How can we distinguish an attack from those?

Correctly-behaving Tor relays never send RELAY_CELL cells backwards
(towards the client) on the circuit.

So if you see one, it's somebody not following the protocol.

--Roger

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

Re: [tor-relays] 'relay early' attack detection at the infrastructure level

[Roger Dingledine]

On Sat, Aug 02, 2014 at 03:38:51PM +1000, Zenaan Harkness wrote:
> >> the RELAY_EARLY cell has common legitimate uses.
> >> How can we distinguish an attack from those?
> >
> > Correctly-behaving Tor relays never send RELAY_CELL cells backwards
> > (towards the client) on the circuit.

Gah. I should have written RELAY_EARLY above. Sorry for the confusion.

> > So if you see one, it's somebody not following the protocol.
> 
> Might be a stupid question sorry, but why not just block such
> relay-early packets coming in the wrong direction?

New relays do block them. Actually they close the circuit and warn,
since once somebody has violated the protocol like this, it's unwise to
let them continue interacting with you.

Or is that what you meant?

--Roger

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

Re: [tor-relays] managing bandwidth quotum

[Roger Dingledine]

On Tue, Aug 26, 2014 at 06:43:04PM +0200, Kees Goossens wrote:
> A question on how to manage a bandwidth quotum of my internet provider.
> I run a non-exit relay on a hosted server with 1000 GB bandwidth per month.
> 
> In essence, should I 
> A- only set the AccountingMax, and let the relay figure out the 
> RelayBandwidthRate & RelayBandwidthBurst by itself
> B- set the AccountingMax, and set RelayBandwidthBurst to whatever the 
> provider will allow (much higher than the average rate)
> C- set the AccountingMax, and set RelayBandwidthRate to the average rate 
> (quotum/31 days), and optionally set RelayBandwidthBurst
> D- only set the RelayBandwidthRate to the average rate, and hope that I don?t 
> go too much over my quotum

https://www.torproject.org/docs/faq#LimitTotalBandwidth suggests
setting accountingmax and then setting the relaybandwidth* options
to run for at least half your allocated time.

So for 1000GB per month, assuming you mean 500GB each way per month,
or 16GB each way per day, it suggests

AccountingStart day 0:00
AccountingMax 16 GBytes
RelayBandwidthRate 320 KBytes
RelayBandwidthBurst 5000 KBytes

Alas, 320 KBytes isn't very much these days, so you should maybe
experiment with other options, like raising it higher.

> This could perhaps be rephrased as:
> - is it better to offer a high bandwidth for part of the month and then 
> hibernate, or 
> - should I offer a lower average bandwidth for the whole month?

Usually we suggest the latter, so relays can have more stability. But
your average would indeed be quite low then (thus probably not
attracting much use compared to the many faster relays).

> Details:
> I?ve set ?AccountingMax 450 GB? with the appropriate accounting start 
> (conservative, since I log in occasionally too).
> 450 GB / 31 days => 168 KB / sec average 
> Setting ?BandwidthRate 168 KB? seems to severely underutilise the relay.
> Setting ?BandwidthRate 1000 KB?, to force usage of the relay, uses the relay 
> bandwidth at a much larger rate (2670 KB/s consensus weight), and will cause 
> hibernation after ~25 days.  

Hibernation after ~25 days sounds great, since you're up for most of the
month and also you're using most of your bandwidth. I wonder if the FAQ
should be updated? Or if you should make a wiki page with more examples,
and we can link to it from the faq?

--Roger

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

Re: [tor-relays] Authdir is rejecting routers in this range

[Roger Dingledine]

On Fri, Aug 29, 2014 at 09:51:33PM +, Davíð Steinn Geirsson wrote:
> I rented a dedicated server to run a tor relay (100Mbit/s) to
> contribute to the network. On this machine, tor gives messages like
> these on startup:
> 
> http status 400 ("Authdir is rejecting routers in this range.")
> response from dirserver '<...>'. Please correct.
> 
> The server is hosted with https://fdcservers.net/.
> 
> Did I just get unlucky in picking a provider? Is there a way to check
> these things before spending money on setup + monthly fees?

Yeah, 50.7/16 and 204.45/16 were where the Sybil relays came from:
https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack

We were rejecting all relays from these subnets for a while. But then I
removed that config from moria1 and asked some of the other directory
authority operators to re-allow them too, since the attacking relays
are long gone. Looks like not enough of them have done so. I'll ask
them again.

Thanks,
--Roger

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

Re: [tor-relays] Time information

[Roger Dingledine]

On Tue, Sep 02, 2014 at 07:19:02PM +, Marcin Gondek wrote:
> Sep 02 21:11:52.000 [info] channel_tls_process_netinfo_cell(): Received 
> NETINFO cell with skewed time from server at x.x.x.x:449.  It seems that our 
> clock is ahead by 1 hours, 19 minutes, or that theirs is behind. Tor requires 
> an accurate clock to work: please check your time and date settings.
> 
> Should I worry about it? Logs seems to little strange and looks that
>other servers provide it's local time without any timezone.

It isn't a bug, but it is not great that some Tor relays have the
wrong time. But so long as they aren't *too* wrong, it isn't the end of
the world. I just counted them up, and I think there are about 30 relays
with wrong clocks, out of the 6000 or so total. That's pretty good.

I think those relays are probably seeing complaints in their logs,
since while you see those at info-level because they're not directory
authorities, when you notice that a directory authority disagrees with
your clock, it's logged at warn-level severity.

I wonder how to get them to notice more consistently?

--Roger

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

Re: [tor-relays] fingerprint info propogation

[Roger Dingledine]

On Sun, Sep 07, 2014 at 01:00:38AM +, ja...@icetor.is wrote:
> Sorry if asked before,
> made a stupid oversight restarting one of my exits yesterday, had
> duplicated the fingerprint file from another node. Changed the file to
> the correct nickname today (I know nicknames are depreciated now) and
> reset tor, how long will it take this change to propogate to the network?

Hi Jason,

The fingerprint file is just written out for your benefit. It's never used
by the relay -- the relay uses the actual key, not just the fingerprint
of the key.

See also https://www.torproject.org/docs/faq#UpgradeOrMove for more
details about what counts as your relay's soul. :)

Thanks!
--Roger

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

Re: [tor-relays] Correctly setting up arm

[Roger Dingledine]

On Mon, Sep 22, 2014 at 09:34:40PM +0100, Chris Whittleston wrote:
> Previously, I've run arm using 'sudo -u debian-tor arm'. As was mentioned
> here previously, this is not how you should run it - in fact there is a bit
> of documentation to suggest how it should be done.

Yep. See https://trac.torproject.org/projects/tor/ticket/10700
for the discussion.

> Unfortunately I'm having
> some issues getting arm working correctly as described here in step 14:
> 
> https://www.torproject.org/docs/tor-relay-debian.html.en#after
> 
> Having added my user (pi) to the debian-tor group, I try to run 'arm' and
> get the following:
> 
> Failed to read authentication cookie (permission denied):
> /var/run/tor/control.authcookie

What Tor version are you using? There was a bug in Tor 0.2.5.1-alpha
through 0.2.5.6-alpha that broke cookie auth for this situation:
https://trac.torproject.org/projects/tor/ticket/12864
It is fixed in 0.2.5.7-rc.

> I've tried reinstalling arm, relogged and checked that I'm in the right
> group still using 'groups' (which I am) - no joy.
> 
> CookieAuthentication wasn't initially enabled, turning it on makes no
> difference, I get the same error.

As Grace pointed out, torrc isn't the only config file that your
Tor deb uses.

> Am I missing something when it comes to setting up CookieAuthentication? I
> guess I must be...although it seems strange that I was getting that error
> even with CookieAuthentication disabled.

If the Tor version hint doesn't do it for you, I'm not sure what the
next step is. Hopefully it does. :)

--Roger

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

[tor-relays] Help collect hidden service usage stats?

[Roger Dingledine]

Hi folks,

If you are comfortable compiling Tor from git, and you want to help
investigate what fraction of Tor network load comes from hidden service
use, I have a shiny new git branch called hs-stats that will collect
per-thirty-minute statistics about number of circuits and number of cells
your relay sees that have to do with exiting, with hidden services, with
circuits where you're not the final hop, and a fourth none-of-the-above
category.

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

It skips all circuits and cells that come from non-relays, which should
help make sure the stats aren't useful for hurting anonymity.

It doesn't automatically send the output anywhere -- it just writes it
to its notice-level log for now. So you'll need to either send me the
log lines, or add them to the trac ticket like I did here:
https://trac.torproject.org/projects/tor/ticket/13192#comment:2

Preliminary results are that load from hidden services is actually
a tiny fraction of overall load.

A bonus use from these statistics would be to learn what fraction of
load comes from exit connections vs middle connections, for relays with
various consensus flags.

And of course, it's possible there are bugs in how I'm doing the
counting. I'll keep investigating to make sure I'm doing it right.

Thanks!
--Roger

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

Re: [tor-relays] My relay hibernated unexpectedly

[Roger Dingledine]

On Fri, Oct 03, 2014 at 08:51:46AM -0400, Derric Atzrott wrote:
>   [notice] Configured hibernation. This interval began 2014-10-03 15:00:00; 
> the
>scheduled wake-up time is 2014-10-03 15:00:00; we expect to exhaust
>our quota for this interval around 2014-11-03 15:00:00 (all times
>local)

It looks like Tor thinks it is in the interval that started at
2014-10-03 15:00:00. But then:

>   [notice] Commencing hibernation. We will wake up at 2014-10-03 15:00:00
>local time.

It looks like Tor thinks it is not yet 2014-10-03 15:00:00.

> Note: I stripped the timestamps out because I am viewing these on a different
> computer and had to retype them.

I think the timestamps here might be really useful, to sort out what
time Tor actually said these things.

--Roger

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

Re: [tor-relays] GoodBadISPs revamp?

[Roger Dingledine]

On Mon, Oct 13, 2014 at 02:09:50AM +0100, Thomas White wrote:
> Anyone with access to create a new page on the list and we can add
> subsections to a new page containing the dated responses from each
> company on their policy towards Tor hosting.
> On 13/10/2014 01:56, subk...@riseup.net wrote:
> > should the community start a revamp project (or start a whole new
> > list)? i'd be willing to donate my time to help get this started if
> > need be.

Sounds great, please do!

Also, while we're on the topic of good interactions with ISPs, let me
reiterate something I said back in November:

"""
I worry about the "slash and burn agriculture" approach to running Tor
relays, where you set up an exit relay, and if anybody gets angry you move
on to another ISP. That approach is really appealing since it's simple,
but it assumes the Internet is infinite. If in fact we're destroying
land without regard to sustainability, and we run out of land...

Today's interactions with ISPs influence Tor's future viability.
"""

from
https://lists.torproject.org/pipermail/tor-relays/2013-November/003240.html

Thanks!
--Roger

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

Re: [tor-relays] Obfuscated bridges and tor-arm

[Roger Dingledine]

On Thu, Oct 16, 2014 at 01:12:44PM +0200, justaguy wrote:
> Does the tor-arm tool display the used BW of the obfuscated bridge or
>only the normal non obfuscated bridge?

It should display the used bandwidth of the Tor program, which
includes all the various ways that people can talk to it.

That said, there might be bugs where the obfsproxy traffic is "local"
to the Tor program, so it doesn't count it as bandwidth used. But in
that case it would still count the traffic to/from the Tor network.

Let us know if you find problems!
--Roger

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

Re: [tor-relays] Anonbox Project

[Roger Dingledine]

On Thu, Oct 16, 2014 at 11:56:57AM -0700, Mike Perry wrote:
> As a result of their claims not matching up to reality, I've been
> debating writing a blog post warning about the various issues with
> Anonabox

I think a blog post teaching people about the issues is a fine plan.

I was thinking something like:

- Many people keep wanting to build a magic anonymity box. And it's
really appealing to not have to change your behavior or your
application settings, and just magically get anonymity, so I can
understand why the idea keeps popping up.

- Unfortunately, if you just route all your traffic through Tor,
you're only solving half the problem: all the application-level issues
remain. First this is a problem when you use your Chrome over Tor and
then wonder how websites are able to recognize you anyway (remember
all the protections that Tor Browser adds over vanilla Firefox). And
second, as you say in your post here, it's a problem because of all the
chatter that comes from background applications, update attempts, printer
notifications, and so on that most systems do by default these days.

- To be fair, some expert users may still get a benefit from Torifying
their traffic. For example, if they've already set up a firewall to
block everything they don't want talking, and now they want to use
an application that's hard to configure a proxy for. Or if they have
thought deeply about their threat model and they don't want a lot of
the anonymity properties that Tor aims to offer. But that user is very
far from the target audience for these magic anonymity boxes.

- The best design we've been able to come up with is one that forces you
to be using Tor on your side, and only allows your traffic through if it's
coming from Tor. Making it use a proxy, or maybe even better a Tor bridge,
that's running on the router seems a fine way to do this limiting. And we
could also imagine running a captive portal website on the router that
intercepts outgoing port 80 requests and teaches you what you need to
do to use this network connection safely. Perhaps it has a local copy
of Tor Browser for you (but how does the user know it's the real Tor
Browser?), or perhaps it lets you reach https://www.torproject.org/
so you can fetch it yourself.

- This approach sure isn't as usable as the magic anonymity box. What a
great research area! But be aware that people have been thinking about
this issue for several years now, and don't get fooled by solutions
that brush all the above details under the rug.

This may also be a good opportunity to point people at
https://www.usenix.org/conference/foci14/workshop-program/presentation/edmundson

--Roger

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

Re: [tor-relays] exit node experience: abuse over HTTP, stealrat infection

[Roger Dingledine]

On Sun, Oct 19, 2014 at 01:24:31PM +0200, Kees Goossens wrote:
> However, the only thing I do with my VPS is run tor.  I don???t run a web 
> site, and don???t have apache or whatever installed.
> I didn???t investigate much further, but my hypothesis is that when
>publishing the tor-exit notice on port 80 either tor internally uses a
>web server or enables a web server that???s present in the system. Either
>way, that webserver was hacked through a PHP hack.

It is much more likely that this was a false positive. That is, whoever
sent you the mail was using a wrong-in-your-case mechanism for detecting
whether you're infected with "stealrat". They probably just make a list
of all the computers that connect to them and send certain traffic. And
if your computer connected to them and sent that traffic, onto their
list you go.

The Internet is full of people telling other people that they're
infected and ought to clean up their computer. Sometimes they're right,
sometimes they're wrong. Usually, when it comes to Tor relays they're
wrong, because it never occurred to them that you might be proxying the
traffic from somebody else.

Hope that helps,
--Roger

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

Re: [tor-relays] My VPS relay has just been hacked

[Roger Dingledine]

On Sat, Oct 25, 2014 at 03:36:05PM +0100, Nick Sheppard wrote:
> This is typical of what I found.
> 
> 1root 20 0 10604  832  700 S ... 0:00.10 init
> 2root 20 0 000 S ... 0:00.00 kthreadd/3277
> 3root 20 0 000 S ... 0:00.00 khelper/3277
> 1370 root 20 0 36976  660  492 S ... 0:00.38 hxyqbutesc

I should note here that yes indeed, you do appear to have been
compromised.

We get some relay operators here who misinterpret an email from their ISP,
which tells them they've been compromised but really the only evidence
is that they sent out some traffic that the other side thought could
only have been sent if they're compromised. E.g.,
https://lists.torproject.org/pipermail/tor-relays/2014-October/005551.html

But this one does not look good. I sense a reinstall in your future. :)

> Eventually I'll have to reinstall everything from scratch,
> straightforward enough, but what can I do to make sure it doesn't
> happen again?  Would hardening my iptables work?  Has anyone else
> seen this?

The other advice I heard here was very good too -- mainly "be sure to
do all your updates", "don't allow ssh login by password", and "wonder
if perhaps your hosting provider has a problem that makes it impossible
for you to keep your host safe".

--Roger

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

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

[Roger Dingledine]

On Sun, Oct 26, 2014 at 12:49:10AM +0200, g...@kset.org wrote:
> I first updated from 0.2.4.24 to 0.2.5.9rc and then to 0.2.5.10 as the
> packages hit the repositories.
> 
> In both cases my notice log is now showing 0 NTor handshakes:
> 
> Tor 0.2.5.9-rc (git-067214faa586161d) opening new log file.
> ...
> Circuit handshake stats since last time: 427379/427386 TAP, 0/0 NTor.
> Circuit handshake stats since last time: 349975/349975 TAP, 0/0 NTor.
> ...
> 
> Tor 0.2.5.10 (git-8515d47dcb46b53d) opening new log file.
> ...
> Circuit handshake stats since last time: 298286/298286 TAP, 0/0 NTor.
> Circuit handshake stats since last time: 237567/237567 TAP, 0/0 NTor.
> 
> Is this expected behaviour?

No, this is unusual.

Which relay are you?

Which package exactly? I'm guessing you're using the deb? Which OS?
What CPU architecture?

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.

--Roger

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

Re: [tor-relays] upgrade tor bridge raspberry-pi

[Roger Dingledine]

On Thu, Oct 30, 2014 at 08:30:31PM +, jchase wrote:
>  On hearing the news that tor 0.2.5.10 was available, I upgraded my
> raspberry-pi tor (obfuscated bridge) to 0.2.4.something. The upgrade
> restarted the tor daemon automatically. I would have rather done it
> myself using a restart. When I used arm to look at my new traffic, I
> noticed that I had been magically turned into an exit relay (besides
> staying a bridge). My torrc was still intact and clearly stated:
> ExitPolicy reject *:*
> I restarted tor by hand and got the same result. I am not interested in
> having an exit relay. So I turned off the bridge and am waiting for
> advice from you.
> rasptorholland

Is it possible you are being bitten by this arm bug?

https://trac.torproject.org/projects/tor/ticket/12956
https://trac.torproject.org/projects/tor/ticket/6430

--Roger

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

Re: [tor-relays] Windows Tor Server Guide

[Roger Dingledine]

On Tue, Nov 04, 2014 at 05:25:28PM -0500, Nick Mathewson wrote:
> I'd suggest that you start by posting your process to this mailing
> list, so that other folks can add improvements for it.  (Though I hope
> that expert packages in some form will return soon.)

The expert packages have indeed returned, albeit in a slightly
different form. See https://dist.torproject.org/torbrowser/4.0.1/
and scroll down to tor-win32-tor-0.2.5.10.zip

But nobody has linked to them from the download page; and I think it
might require a bit of thought to make our links on the download page auto
update to the new location of this zip after future Tor Browser releases.

--Roger

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

Re: [tor-relays] Guard flag and some irregularities

[Roger Dingledine]

On Sat, Dec 06, 2014 at 03:40:41PM -0500, Rafael Rodriguez wrote:
> https://atlas.thecthulhu.com/#details/48ADFCC561402D7EBB1CDE233F206B01D8FA0765
> 
> 1- Is it ok for the Guard flag to come and go so often?

Yes, it can oscillate for some relays, if some directory authorities
think the relay deserves the Guard flag and others don't.

It's not great, and we should probably fix the design sometime, but
it's also not so bad.

> I do not see
> anything wrong with my relay and it is pushing up to 12MBs at times. 

Are you sure? What tool are you using to measure this? If it's arm, be
ware that arm by default tells you throughput in bits, and Tor measures
things by bytes.

> Most of the time, my relay pushes between 3-7MB/s constantly and that's
> fine. But there are occasions in which I see it spike and send out as
> much as 12MB/s when I have set a limit of @6MB/s. 

Based on the graphs above, you're using maybe .5MB/s each way on
average. That reinforces my guess about the bits/bytes confusion.

> 2- Is Tor not respecting the limits? If it doesn't respect the limits
> consistently it might as well overkill my budget which translates into
> me killing the relay. 

See also
https://www.torproject.org/docs/faq#BandwidthShaping

Thanks for running a relay!

--Roger

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

Re: [tor-relays] Out of memory message

[Roger Dingledine]

On Sun, Dec 07, 2014 at 09:52:47AM +0100, Logforme wrote:
> I run the relay Logforme (855BC2DABE24C861CD887DB9B2E950424B49FC3).
> Yesterday I saw new messages in the log file:
> Dec 06 09:28:13.000 [notice] We're low on memory.  Killing circuits with
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Dec 06 09:28:16.000 [notice] Removed 1040388096 bytes by killing 1
> circuits; 14631 circuits remain alive.
> 
> Do I read that correctly as one circuit using 1GB of memory?

Wow! Never thought I'd see that in practice.

>  The relay and the
> box is so far working fine, I just wonder if this is some kind of attack
> or if anything is wrong and if there is anything I should do about it.

Actually what you're seeing is a defense to an attack: Rob explains it
well at
https://blog.torproject.org/blog/new-tor-denial-service-attacks-and-defenses

Of course, it's also possible that this behavior occurred naturally
in some way.

Has anybody else here seen messages like this?

--Roger

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

Re: [tor-relays] Out of memory message

[Roger Dingledine]

On Sun, Dec 07, 2014 at 01:43:46PM +0100, Logforme wrote:
> To me it looks like an attacker that ramped up over a 6 hour period and
> then stopped building new circuits. Since the tor process still uses all
> available memory (more than 24 hours later) I guess the attacker still
> holds some circuits open.

Careful with your conclusion there -- because of memory fragmentation, the
process can still hold the memory even when Tor has freed the memory. That
happens because some part of the memory page is in use and some is freed,
but since not all of it is freed the allocator doesn't take it back.

Some quick searches point to
https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_native_memory_fragmentation_and_process_size_growth
as what looks like a nice summary of the issue.

--Roger

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

Re: [tor-relays] Relay is down

[Roger Dingledine]

On Wed, Dec 31, 2014 at 01:44:59PM -0500, Giovanny Andres Gongora Granada wrote:
> Well my relay continues being down. Will my relay up someday again? I
> think, doesn't have sense to have relay on my server configured if it will
> not be available because was blacklisted for some reason that I don't know,
> nobody contacts me explaining why was my relay down or a notice about it.

Hi Gio,

Sorry for the troubles.

The problem is that on Dec 30 the network got flooded by a pile of relays
all named Anonpoke, which came from several Internet address blocks.

One of those blocks was 104.130.0.0/16 -- we ended up blocking the whole
thing by address to get rid of them, and your relay was a casualty of
this broad block. This is very sad. There was a second casualty too
(a relay called "exotime").

It looks like the flood of relays has disappeared actually. I think that
means that soon we should remove the rule about those address blocks.

But as Sebastian says, please give us a few days to get some sleep after
31c3 and we'll sort it out.

Thanks for running a relay everybody!
--Roger

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

Re: [tor-relays] Consensus weight dropped

[Roger Dingledine]

On Tue, Jan 20, 2015 at 11:44:46AM +0100, Network Operations Center wrote:
> Thank you!
> 
> https://atlas.torproject.org/#details/3D7E274A87D9A89AF064C13D1EE4CA1F184F2600

The votes from the directory authorities for the last consensus period
are here:
http://freehaven.net/~arma/moria1-v3-status-votes

In this case it looks like schokomilch has these votes for the w line:

w Bandwidth=2525 Measured=1600  [moria1]
w Bandwidth=2525[dizum]
w Bandwidth=2525[Faravahar]
w Bandwidth=2525[gabelmoo]
w Bandwidth=2525[dannenberg]
w Bandwidth=2525[urras]
w Bandwidth=2525[longclaw]
w Bandwidth=2525 Measured=674   [tor26]
w Bandwidth=2525[maatuska]

So since only two directory authorities vote a Measured value for it,
and the design calls for three opinions, it ends up unmeasured, and thus
with a consensus weight of 20.

You can read about the reasoning for requiring Measured votes here:
https://trac.torproject.org/projects/tor/ticket/2286

In theory gabelmoo and longclaw are supposed to have opinions about
your relay too:
https://consensus-health.torproject.org/consensus-health.html#bwauthstatus

But they don't, so here we are.

The problem is likely that the bwauth (bandwidth
authority) scripts are old and buggy and unmaintained. See
https://trac.torproject.org/projects/tor/query?status=!closed&component=Torflow
especially the tickets towards the bottom.

We've already known about this in the context of "the bandwidth
authority scripts are very poorly tuned for the changes that have
happened in the Tor network since the scripts were written, so they
vote wildly varying numbers for relays". But I don't think that
we'd realized the "some relays don't get three votes at all, so they
basically get zeroed out" issue. Hm.

(Ultimately I am hoping for the bwauth scripts to get phased out, in
favor of one of the secure bandwidth measurement schemes that various
research groups have been working on lately. Those other designs also
will have the advantage that it's harder to game the system by lying
about your bandwidth. But it will be some months at least until we have
one of those designs to evaluate.)

--Roger

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

Re: [tor-relays] Minimizing service interruption when reloading torrc?

[Roger Dingledine]

On Mon, Feb 09, 2015 at 04:29:01AM +0100, Sebastian Urbach wrote:
> >I'd like to reload torrc; I think I can do this by either restarting tor or
> >by sending a SIGHUP to the tor process, but I'm not sure how much of a
> >service interruption each of these approaches will cause.
> >
> >What's the best way to reload torrc (i.e. how can I do this in a way that
> >minimizes the service interruption)?
> 
> If it is just reloading the torrc and nothing else then SIGHUP ie
> the best way to do that.

If you're using the deb, "service tor reload" is slightly better --
this init script will run Tor on your torrc with --verify-config first,
in case it notices anything that is going to make your Tor exit when it
parses the new torrc.

If the Tor run with --verify-config complains, then the init script will
opt not to send the hup signal, and instead give you a warning.

The goal is to reduce the number of situations where you hup your Tor
and then it quietly writes out a complaint about the new torrc file and
exits, but you don't notice that it's gone.

--Roger

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

Re: [tor-relays] Is Bridges supposed to get a gurard flag?.

[Roger Dingledine]

Thanks for running a bridge!

(But, please don't cross-post onto multiple Tor lists. Or for a different
perspective, the tor-dev list is for developing Tor, not for reaching
Tor's developers. :)

On Tue, Feb 10, 2015 at 09:03:10AM +, Sasikantha babu wrote:
> Hello All,
> 
>    I've been running a non-exit relay at home and a bridge on amazon cloud 
> since dec-2014.  And today 
>    I had noticed on atlas my bridge has got a guard flag and from the logs in 
> the last 18 hours it had sent 
>    4.73 GB and received 4.89 GB (finally I'm happy to see bandwidth being 
> used on bridge). I've the 
>    following questions
>    1. Is a bridge supposed to get a guard flag ?.   2. Is there a difference 
> between a guard flag of a relay and a guard flag of a bridge?.
> Thanks

This is totally normal. The bridge directory authority shares a lot
of code with the normal directory authorities -- it tracks uptime and,
reachability, assigns flags, and so on.

In some cases these flags for bridges are still useful. For example,
when the bridges.torproject.org service is giving out bridges, it has
a mode where it tries to include at least one bridge with the Stable
flag in its response set, to reduce situations where you get a pile of
bridges but then they all go down soon after.

I don't think we use the Guard flag for anything right now for bridges.
But hey, you can be happy knowing that your bridge is in the upper half
of bridges by both capacity and stability.

Thanks!
--Roger

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

Re: [tor-relays] "Very Safe" Exit Policy

[Roger Dingledine]

On Tue, Feb 17, 2015 at 11:02:45AM -0500, Chris Patti wrote:
> I tried running an exit for a bit and it lasted a few weeks before
> some brainless wonder hijacked someone's Gmail with my exit, so I had
> to pull it down and go relay only.

Even worse (or maybe better), this sort of thing happens when a Tor user
connects to her Gmail, and then Google warns her that there was a Tor
connection and omg it's time to freak out, and then she freaks out.

I mean, maybe it happened the way you describe, but also maybe it didn't.
The large services like Gmail and Facebook have been struggling over
the past few years to find the right balance between "if there's a
connection from Tor, tell the user to freak out" and "actually for some
users connecting over Tor is totally the smarter move, and we should
encourage that".

--Roger

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

Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)

[Roger Dingledine]

On Tue, Feb 17, 2015 at 11:00:02PM +0100, Moritz Bartl wrote:
> We still lack the "gamification" Relay Challenge website that Virgil was
> talking about. It would just sum up all relays of a family, and then it
> really does not matter any more.

If anybody (ok, it has to be the right people, not quite just anybody :)
wants to step up and mentor this, we could add it to the ideas list for
GSoC 2015, and see if we get any students who bite:
https://www.torproject.org/about/gsoc

--Roger

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

Re: [tor-relays] 0.2.5.10 / 0.2.6.x and ticket 9682

[Roger Dingledine]

On Sat, Mar 07, 2015 at 12:53:39PM +0100, Sebastian Urbach wrote:
> Hard to tell pretty much says it all :-( Not much of a change. Now
> the multithread feature becomes the last hope :-)
> 
> Thanks gor your reply, domehow i expected it zo be more of a boost
> after reading Nick's text:
> 
> https://blog.torproject.org/blog/coming-tor-026

The main reason I'm excited about
https://trac.torproject.org/projects/tor/ticket/9682
is because it should handle high circuit creation loads better.

When the botnet hit a few years ago, there were suddenly five million
new Tor clients all sending create cells pretty often:
https://trac.torproject.org/projects/tor/ticket/9657
It got to the point where many relays were at 100% cpu and still rejecting
many of the create cells they received. And they were waiting in the
queue and timing out, rather than being rejected preemptively. We added
some logic to count (for that particular relay) how long it takes us to
handle a create cell, and then when we had so many queued already that
we know we won't get to the new one in time, we rejected it early.

But that logic never actually worked -- cpuworkers spent a lot of time
idle, because we only measured "time to process the create cell", not
"time for the main thread to notice that the cpuworker can handle another
one, and then time to give it to the cpuworker, and then time to process
the create cell":
https://trac.torproject.org/projects/tor/ticket/9574#comment:29

This new patch in 0.2.6.3 greatly reduces the first two of these three
items.

So in summary, in times when create cell load becomes huge again, we
should be able to handle many more of them than before.

--Roger

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

Re: [tor-relays] IP Address change detected wrongly (Our IP Address has changed)

[Roger Dingledine]

On Tue, Mar 10, 2015 at 06:30:50AM +, Sasikantha babu wrote:
> Hi all,
>     Today on my relay I observed the below messages 2 hours back.  Tor 
> reported address change from IP_IN_INDIA 
>  to IP_IN_FRANCE from SRC_1. The next second SRC_2 reported address 
> change from IP_IN_FRANCE to 
>  IP_IN_INDIA . How could it be possible?. Is this a normal behavior?. 
> 
> Mar 10 08:06:52 NoNameForHost Tor[27279]: Our IP Address has changed from 
>  to  ; rebuilding descriptor (source: 
> SOURCE_IP_1__).
> Mar 10 08:06:53 NoNameForHost Tor[27279]: Our IP Address has changed from 
>  to ; rebuilding descriptor (source: 
> SOURCE_IP_2__).
> 
> PS: I'm not posting IP addresses but If you somebody wants the IP address too 
> I will post them.

Fun. We used to have some bugs around that, but we haven't had bugs
there in a long time.

So yes, if you could post all the details, including which relay is
yours, that would help us figure out what's up here.

Have you set anything in the "Address" line of your torrc?

If not, does your computer have a public IP address, or a hostname that
resolves locally to a public IP address?

--Roger

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

Re: [tor-relays] Many inbound and outbound connections but no circuits

[Roger Dingledine]

On Wed, Mar 04, 2015 at 04:30:58PM +0100, mattia wrote:
> Hello, I've been running a relay for some weeks.
> It has now earned the stable flag.
> Despite this I always have more than 500 inbound and outbound
> connections but no circuits at all. Is this normal? 

It depends what you're using to learn how many circuits you have.

For example, it is quite reasonable that you have a bunch of circuits
open for other people, but your relay has no "client" circuits because
your Tor hasn't received any client-side application requests lately so
it stopped building preemptive circuits.

--Roger

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

Re: [tor-relays] Tor-Tshirts

[Roger Dingledine]

On Sun, Mar 22, 2015 at 01:03:15AM -0400, Nchinda Nchinda wrote:
> Is there still someone at Tor Weather managing tshirt distribution?
> I've been running a two fairly large relays for a couple months, although I
> also wouldn't mind paying for an official tor shirt.
> 
> My email to Tor Weather went unanswered.
> 
> https://atlas.torproject.org/#details/C1CFB375BED9D7506569E07B01753BC67EE87AC2
> https://atlas.torproject.org/#details/CAB78BF9BD73536DCB55E5BC98D5F3AAB45CF9EA

We indeed have a stack of tshirt requests queued up. I've been
working on spinning up another volunteer to help answer all of them.
Soon I hope!

--Roger

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

Re: [tor-relays] Undiagnosable Crashes in Relays

[Roger Dingledine]

On Wed, Mar 25, 2015 at 08:26:20AM +, skyhighatrist wrote:
> I have no idea why they all fell over, the last thing in the logs was
> the usual "current status" output with some traffic measuring, seemingly
> immediately afterwards, the process killed itself for no reason.

You might also enjoy
https://www.torproject.org/docs/faq#TorCrash

My first guess is that the out-of-memory killer killed it.

--Roger

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

Re: [tor-relays] MY IP adress on blacklist and then in exit relay policy

[Roger Dingledine]

On Mon, Mar 30, 2015 at 12:23:21PM -0400, Zack Weinberg wrote:
> The only way your exit node's own IP address could be in the exit
> policy is if someone put it there.  Maybe you did that and you don't
> remember doing it?  If you didn't do it, then you might indeed have
> had your node broken into, and you should consider rebuilding it from
> scratch.
> 
> (I can make a case for forbidding exit-to-self, particularly if the
> exit node runs any other services.  But running other services on an
> exit node is a bad idea in the first place.)

No, this is fine and normal. Tor relays automatically add themselves to
their exit policy by default.

See the ExitPolicyRejectPrivate option in the man page.

https://lists.torproject.org/pipermail/tor-announce/2008-January/33.html

--Roger

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

Re: [tor-relays] help interpreting fault setting up exit

[Roger Dingledine]

On Sat, Apr 11, 2015 at 05:11:41PM -0800, I wrote:
> -bash: sudo: command not found

Looks like you might want to "apt-get install sudo".

That said, if you're running the command as root already,
you can just omit the 'sudo' word.

Once you have done the apt-get sudo, do a 'man sudo' and you can read
about what it is. It is one of the simple and pervasive unix commands
that all sysadmins tend to know about -- but it is a tiny bit tricky
here because Ubuntu basically forces you to know about it in order to
do anything, whereas Debian doesn't.

Hope that helps,
--Roger

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

Re: [tor-relays] T-shirts and Confirming Relay Control

[Roger Dingledine]

Matt: Thanks for leading us forward on the tshirt topic! I still, alas,
have a pile of tshirt requests from Jan-Mar that I should collate and
forward to you.

On Sun, May 03, 2015 at 10:26:52AM -0800, I wrote:
> Isn't the value of the t-shirt disproportionate to the trouble you're
>going to to give them out?
> If the weather message offering the t-shirt is answered by the same
>address isn't that proof enough?

I think I agree with this: if somebody has a copy of a Tor weather
mail, then they -- oh. You can sign up to watch somebody else's relay,
and then you get their tshirt notification?

I guess the obvious fix is to only have weather send tshirt notifications
when it has auto-parsed the contact info itself, rather than when a
human signs up to watch a given relay.

But the obvious fix involves changing Tor Weather. It's my understanding
that we have a rewrite already done by a GSoC student, but nobody has
attempted to deploy the rewrite because nobody wants to mess with the
current weather instance (and because Karsten, the original mentor,
is overloaded).

Tor Weather should really be a community thing, not a service that
Tor maintains, given how we're stretched thin as it is.

I met a nice fellow in Valencia who lives in Berlin and offered to pick
it up. But I haven't heard anything further from that conversation.

Really, Weather is messy because it tries to serve many too many purposes
at once -- two of the extremes are letting people sign up to get email
when their relay goes offline, and also tracking historical relay uptime
data in order to tell us (and the operator) when a given relay has passed
a given milestone.

Of course, making it a community thing could easily mean even more
inconsistency over time. "Hm" indeed.

--Roger

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

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

[Roger Dingledine]

On Thu, May 14, 2015 at 08:01:19PM +, nusenu wrote:
> Dear Tor BW Authories,
> 
> we'd like to bring the following issue to your attention.
> Since the last two weeks the amount of unmeasured relays is steadily
> rising [1].

Hello nusenu,

Thanks for the kick.

For other statistics, each hour I copy over the votes that moria1 sees:
http://freehaven.net/~arma/moria1-v3-status-votes

And there's also
https://consensus-health.torproject.org/#bwauthstatus

It is clear that the bwauth scripts are buggy and need a rewrite. And
not just buggy -- I think their design is probably flawed too.

I know of several research groups who have been working on better
bandwidth estimation schemes, with the main goal of making them more
robust to cheating, but with the secondary goal of still being adequately
accurate.

I had been hoping that one of those would be ready by now, but the
research group I've been paying the most attention to has quite a bit
of work left to do before they have a cheating-resistance estimation
scheme that doesn't open up too many other problems.

Another hope we have is Aaron Gibson's upcoming OTF fellowship, which
focuses on improving the bwauth system. I think we'll have to find the
right balance there between a redesign, which would take a while but
could be better for us in the long run, and bugfixes on the current
system, which would help things in the short term but take time away
from the redesign.

I'll call Aaron's attention to this thread too and see if he can provide
some insights.

--Roger

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

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

[Roger Dingledine]

On Mon, May 18, 2015 at 09:02:27PM +, nusenu wrote:
> now even DocTor starts to complain
> 
> https://lists.torproject.org/pipermail/tor-consensus-health/2015-May/005772.html

Yep. moria1's bwauth seems to be working fine, so I'm the only one
paying attention to the thread here, and also the only one who doesn't
have anything to fix. :(

I haven't heard back from Aaron Gibson yet.

In the mean time, I've asked some other developers to get one or two new
bwauths going, which will hopefully lessen the magnitude of the problem
in the short term, until somebody can fix the underlying bwauth flaws.

--Roger

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

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

[Roger Dingledine]

On Tue, May 19, 2015 at 12:27:12AM +0300, s7r wrote:
> 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.

I've even been pondering crazy hacks at this point like exporting moria1's
bwauth file to a second dir auth, so it gets to vote twice and we're more
likely to have the required minimum of three opinions for each relay.

(This is a terrible idea, but we're in the realm of terrible ideas at
this point.)

Another terrible idea, while we're at it, is to disable the active
measurements and go back to self-advertised weights by the relays.

--Roger

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