Re: [tor-relays] Bridge Authority closure

[Roger Dingledine]

On Thu, Jul 21, 2016 at 02:28:24PM +1000, Tim Wilson-Brown - teor wrote:
> Also, old Tor clients won't be able to get updated bridge descriptors from 
> the new authority, but as far as I know, bridge descriptor updates aren't 
> essential for clients to continue to use a bridge.

Yes, correct.

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

--Roger

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

Re: [tor-relays] Exit relay funding

[Roger Dingledine]

On Wed, Aug 03, 2016 at 03:29:01PM +0200, t...@as250.net wrote:
> Absolutely. Most of the infrastructure we provide on that basis and it
> is ok! The reason for running that exit node was that we believed it
> would contribute towards a positive impact in many peoples lives.

Thanks for contributing while you did!

I'm remembering way back when I would mail all the people running relays
to see if they needed anything. Then there was the phase where we got
some funding for Moritz to do relay operator advocacy and coordination:
https://blog.torproject.org/blog/turning-funding-more-exit-relays
and that push also led to some cool sites like
https://compass.torproject.org/

Among all the things that we need to do next, I think getting a relay
advocate / coordinator in place would sure be useful. I think there are
so many things that we need, though, that it's going to be a while yet
before we get such a person in place.

In the mean time, hang tight everybody, and let's continue to have a
community who helps each other, and thanks all for your contributions.

--Roger

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

Re: [tor-relays] 90% of exits vulnerable to TCP off-path attack

[Roger Dingledine]

On Fri, Aug 12, 2016 at 12:01:03PM -0400, Zack Weinberg wrote:
> Tor's use of TLS _should_ mean that the worst an attacker can do here
> is denial-of-service.  The Register article suggests that they might
> also be able to force the use of specific exit relays (by disrupting
> connections that don't go through those relays) but weaponizing that
> against specific users (rather than everyone trying to use an exit the
> attacker doesn't like) strikes me as nontrivial.

Agreed. I attended the talk at Usenix Security this week, and the
presenter seemed to think that if a TCP connection between two relays
gets cut, then the first relay will redirect all those circuits to some
other relay. If that were true, then you could do the "keep cutting the
connection until your target circuit goes the way you want it to" attack.

But Tor clients are the ones that choose their paths, and when a circuit
fails, they throw it out and choose a new path, without memory of what
links inside the Tor network did or didn't work in the past. So clients
will effectively fail closed, meaning they will keep trying a circuit of
their choice and you will keep trying to find it and tear it down, but
you won't be able to "direct" their path in the way the authors thought.

That said, this kind of TCP level attack is indeed neat, and people
should keep thinking about ways to apply it, or something like it, to Tor.

For an earlier paper in the same area, see also
http://freehaven.net/anonbib/#tcp-tor-pets12

> Right now I think one should not panic and should wait for the kernel
> people to do a proper fix.

Yes, this makes sense.

Another option is to encourage people to remember that operating system
diversity is important. :)
https://torbsd.github.io/

--Roger

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

Re: [tor-relays] HALP!

[Roger Dingledine]

On Tue, Aug 23, 2016 at 10:00:57PM +0200, Markus Koch wrote:
> I just deleted my best running exit node to move to another vps.
> 
> I copied /etc/tor and /var/lib/tor + keys dir and moved it to the new
> vps. I double-checked the files/keys are the same but i still get a
> new fingerprint. Wtf is wrong with me?

Here's the FAQ entry:
https://www.torproject.org/docs/faq#UpgradeOrMove

It sounds like you did that though.

Sounds like it's time to debug and question your assumptions. :)

For example, were they both Debian systems, using the Tor deb? I am
wondering in particular if the new Tor thinks it should be using that
DataDirectory.

Do the log files give you any hints?

I'm guessing this is the 'niftyguineapig' relay?

--Roger

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

Re: [tor-relays] HALP!

[Roger Dingledine]

On Tue, Aug 23, 2016 at 10:53:04PM +0200, Markus Koch wrote:
> > Do the log files give you any hints?
> 
> I copied all the stuff, checked it and deleted the old vps. So I only see the 
> new logfiles and they are fine, tor finds everything but with a different 
> fingerprint. If the config would be in a different dir on the old vps, how 
> comes that there are config files in both dirs?

Well, a different fingerprint means a different identity key. Maybe
you didn't copy the identity key over correctly?

I notice your old one was Tor version 0.2.7.6 and your new one is Tor
0.2.8.6. So maybe it is a newer Debian, or maybe the timing is just
coincidence.

I also notice that your new Tor relay didn't start out with any
past estimated bandwidth. That makes me think your state file didn't
get transferred either. (These are all the BWHistory* lines.)

So I think your torrc did transfer correctly, but not your datadirectory.

--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 package for Ubuntu 16.04+

[Roger Dingledine]

On Wed, Aug 24, 2016 at 09:47:56AM -0400, Chad MILLER wrote:
> I made a tor-middle-relay package, so the TVs, Wifi Routers,
> Toasters, Self-driving Cars, Phones... of the world that are running
> that new kind of Ubuntu (or other OS that implements this package
> system!) can also help the Tor network.
>[...]
> Once you have it installed, try
> $ sudo /snap/bin/tor-middle-relay.configure
> to bump up your bandwidth limit over the conservative defaults.

Nice idea!

Other people here have very valid points about the security and
maintability side of things, but I'll add another point: It looks like the
conservative defaults you mention are a BandwidthRate and BandwithBurst
of 75 KBytes.

That tiny level of rate limiting basically ensures that none of these
relays will ever get the Fast flag, so they will never be used by
actual users.

The current recommendation on
https://www.torproject.org/docs/tor-relay-debian is to allow at least
250 KBytes/s each way. And even those will be tiny and rarely used
compared to the bigger relays.

I wonder if your project would be better at producing bridges?
https://www.torproject.org/docs/faq#RelayOrBridge
Especially since you could include obfs4 (or even more!) support as part
of the bundle.

--Roger

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

Re: [tor-relays] Caching new entry debian-tor...

[Roger Dingledine]

On Tue, Sep 20, 2016 at 07:20:03PM +0200, shraptor wrote:
> What's up with these messages I get in tor-arm and log?
> 
> Caching new entry debian-tor for debian-tor [62 duplicates hidden]
> 
> What is tor doing??
> 
> Sep 20 19:10:21.000 [notice] Caching new entry debian-tor for debian-tor

It looks like this notice-level entry was changed to an info-level entry
starting in Tor 0.2.7.1-alpha:

$ git show 251f6cfc
commit 251f6cfcd829d3f7b8ac7bce8477a6e14ad47a1e
Author: Nick Mathewson 
Date:   Thu Feb 19 12:30:34 2015 -0500

Quiet "caching debian-tor for debian-tor" notice

diff --git a/src/common/compat.c b/src/common/compat.c
index fde65d9..1788e32 100644
--- a/src/common/compat.c
+++ b/src/common/compat.c
@@ -1793,8 +1793,8 @@ tor_getpwnam(const char *username)
   if ((pw = getpwnam(username))) {
 tor_passwd_free(passwd_cached);
 passwd_cached = tor_passwd_dup(pw);
-log_notice(LD_GENERAL, "Caching new entry %s for %s",
-   passwd_cached->pw_name, username);
+log_info(LD_GENERAL, "Caching new entry %s for %s",
+ passwd_cached->pw_name, username);
 return pw;
   }

So it looks like you are running an old version of Tor? You should
upgrade and the line should go away. In any case it should be harmless.

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] help #3

[Roger Dingledine]

On Fri, Sep 30, 2016 at 02:48:38PM -0700, teor wrote:
> > Installed with apt-get and started simply as a demon aka service tor start
> > Thank you for helping
> 
> Have you tried:
> 
> >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Sn"
> >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Hn"

I think these commands won't help you and might be a distraction --
if you're using the Tor deb, it will set your ulimits for you as part
of the initscript:
https://gitweb.torproject.org/debian/tor.git/tree/debian/tor.init#n40
So even if debian-tor's ulimits are set low (or heck, set high), the
init script will still set them itself when you launch Tor.

That said, the number your Tor said makes me suspicious:
"Failing because we have 4063 connections already."

Tor 0.2.7.x and 0.2.8.x keep 32 sockets in reserve:
https://gitweb.torproject.org/tor.git/tree/src/common/compat.c?h=release-0.2.8#n1658

So it really looks like your ulimit -n is set to 4096.

But 4096 isn't one of the numbers that the Debian init script picks!

Nice mystery you have here.

The thread you quoted earlier has some good hints:
http://archives.seul.org/tor/relays/Feb-2016/msg00060.html

So do a "pidof tor" and it will tell you the processID number(s) of
your Tor process(es), and then look in /proc/PID/limits where PID is
the processID number.

I'm guessing you will see a line like

Max open files6553665536  files

But it will say 4096 instead?

And then my question for you would be "are you super sure that you're
really starting the Tor service using the debian initscript?" You're
starting it as root (or with sudo), yes?

--Roger

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

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Roger Dingledine]

On Tue, Oct 04, 2016 at 10:21:14AM -0500, BlinkTor wrote:
> The technical problem is that implementing IPS in Tor would be massively 
> non-trivial.[...]
> 
> The political problem is, what gets blocked by TIPS and what doesn???t? Who 
> gets to decide? What if some of those brute-force SSH or DOS attacks are 
> ???good guys??? trying to crack the ???bad guy??? servers? Is that legitimate 
> Tor traffic? Who gets to decide who are the good/bad guys? Could we agree on 
> a base level of protection, perhaps by relay operator consensus? Etc.

Another challenge here is that many lawyers have told us that you change
your legal situation if you start choosing which traffic to allow
through. Specifically, if you just pass bytes back and forth, you're
essentially in the common carrier situation, like backbone telcos and
backbone Internet providers. But if you make a list of topics or messages
or patterns to block, then it becomes your responsibility to make that
list perfect, and your fault if you leave something out of your list.

So it would seem that using an IPS is fundamentally dangerous for relay
operators.

I've heard that this logic applies both in the US and in Europe. But
it's been a while since we've had an actual lawyer look at the topic.
Maybe this is a great question for each of the torservers.net umbrella
orgs to ask their friendly nearby lawyers who are wanting to help them?

There is also the separate but related question of wiretapping: blocking
some traffic based on patterns in the request content implies looking at
the traffic, which relay operators typically do not have permission to
do. While ISPs typically make their customers sign an agreement that they
will be surveilled (and I guess they ignore the concept of jurisdictions
that require consent from both sides), Tor relay operators do not have
that agreement -- and they can't really get it, because their 'users'
are all the Tor users.

In summary, I totally get why hosting providers would want to ask relay
operators to monitor their traffic and block certain activities by
examining connection payloads, and that's to make their lives easier,
not for any legal requirement. But it would appear there are some legal
reasons why Tor relay operators might (should?) hesitate to deploy
an IPS on their traffic, and those legal reasons are probably not as
well-understood as they could be.

Do any of the torservers umbrella orgs want to pick this one up and do
something with it? I remember hearing Pepijn cite a specific EU law that
says European relay operators aren't liable for their traffic so long
as they don't mess with it.

One of the goals would be for relay operators to better understand the
tradeoff they should consider when deciding whether to do the thing
that their ISP asks for. Another goal would be for the ISP to better
understand what they're asking from the relay operators.

--Roger

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

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Roger Dingledine]

On Tue, Oct 04, 2016 at 09:55:01PM +0200, Markus Koch wrote:
> Everyone is running a reduced exit policy ... I only allow HTTP +
> HTTPS and I know nobody who allows port 25  at the end of the day
> we all shape our exit traffic.

Choosing what to do with your traffic based on headers is fundamentally
different, legally, than choosing what to do with it based on payload.

In the US, it's the difference between the "pen register" category and
the "wiretap" category. I imagine there are similar terms in many other
countries.

In the telephone metaphor (which is what many of these laws are
fundamentally based on), it's the difference between "I won't let you
call Germany" and "when you call Germany, I'll cut the connection if
you start talking about surveillance".

You'll notice that all of the Tor mechanisms for limiting abuse work
on the header level, not the payload level.

--Roger

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

Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata

[Roger Dingledine]

On Tue, Oct 04, 2016 at 10:08:25PM +0200, Markus Koch wrote:
> Thank you very much, interesting. So I could block URLs but not on
> deep packet inspection?

That's where it starts to get murky: where do headers end and contents
begin? It depends what protocol layer you're looking at. Law-makers
spend a lot of time debating exactly that question.

In Tor's world, since Tor transports TCP streams, we think the headers
are what the TCP layer thinks of as headers, e.g. destination IP and
destination port. And the URL is way down in the payload. (After all,
what business is it of Tor's whether that stream you send over port 80
is http or is something else?)

--Roger

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

Re: [tor-relays] 'No space left on device' glitch causing log failure

[Roger Dingledine]

On Mon, Oct 10, 2016 at 03:15:46PM +0100, Geoff Down wrote:
> Hi all,
>  these are the last entries in my log, but my bridge is still listed on
>  Atlas and client functionality is fine. Latest stable version on
>  OSX10.4.
> Needless to say, the disk is not full and 'tor' can write to that
> directory just fine now.

Yes, once Tor has failed to write to its log file, that file descriptor
is essentially broken until you instruct Tor to try again. If you send
Tor a HUP signal, it will reset a bunch of things, including its logs.

I would assume that it really did run out of space, if only for that
moment.

That said, OSX10.4 is Tiger, right? The one that became unsupported
over seven years ago? (But let's not make this thread about whether it's
morally appropriate to run obsolete OSes -- except to acknowledge that
maybe it has bugs in it.)

--Roger

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

Re: [tor-relays] I think I my relay is broken

[Roger Dingledine]

On Mon, Oct 17, 2016 at 12:31:06AM -0400, Tamara West wrote:
>  x 23:13:17 [WARN] Your server (207.172.253.216:80) has not managed to confirm
>  x   that its DirPort is reachable. Relays do not publish descriptors until
>  x   their ORPort and DirPort are reachable. Please check your firewalls,
>  x   ports, address, /etc/hosts file, etc.

This part looks the important part. When I try to reach
207.172.253.216:80, it looks like it's firewalled.

Is this the right IP address? Is your ORPort reachable? Is your
DirPort the one you wanted it to be?

If you think you set up a hole in the firewall correctly, but port
80 still isn't getting through, try picking a higher port -- ISPs
like Comcast and RCN have a habit of firewalling incoming ports for
all of their customers, "for their own security" or "to keep them from
running services" or whatever their reasoning is this time.

--Roger

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

Re: [tor-relays] Guard before Stable flag?

[Roger Dingledine]

On Wed, Nov 02, 2016 at 12:42:18PM +, John Ricketts wrote:
> When looking at my list on Atlas (21 entries) I'm seeing that some of my 
> relays are getting the Guard flag before they become stable.
> 
> https://atlas.torproject.org/#search/quintex
> 
> I'm going to make the assumption this is normal behavior but I still find it 
> odd.

I agree that this particular behavior is odd. In fact, we put in a
fix to prevent it from happening:

https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.2.9.4-alpha#n614
https://trac.torproject.org/projects/tor/ticket/18624

But that fix is only in 0.2.9.1-alpha, and 7 of the 8 directory
authorities are still on 0.2.8.x. So they'll get it when they upgrade
(which will be a ways after 0.2.9.x goes stable probably).

As for why the Stable flag is confusingly assigned, teor's answer is
a good one.

--Roger

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

Re: [tor-relays] Questions regarding arm on Debian

[Roger Dingledine]

On Fri, Nov 11, 2016 at 02:14:01PM +0100, Dennis Christ wrote:
> I think the problem with CookieAuthentication was that the cookie
> file control_auth_cookie gets written
> to /var/lib/tor. This directory is only readable by user debian-tor
> and not even group readable. I have
> put CookieAuthFileGroupReadable 1 into the config file. But with my
> standard user which is in the debian-tor group i cannot
> access this file inside /var/lib/tor because the permissions of this
> directory are set up by tor on startup to 700.

Right, this is not the way you should be doing it.

My /usr/share/tor/tor-service-defaults-torrc file has these lines in it:

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

So you shouldn't be needing to add any lines to your /etc/tor/torrc
file.

> Maybe i should have add that i do not use the debian init.d script
> to start up tor but a native systemd service file.
> I think its a shame that debian switched to systemd but still relays
> on init.d scripts for so many services. So /etc/default/tor does not
> get used.

This sounds bad too. In fact, it sounds like one of those "you broke
the package, and now you get to keep both pieces" situations. :)

I believe that the Tor deb, including the one intended for jessie,
should work with systemd well:
https://gitweb.torproject.org/debian/tor.git/tree/debian/changelog?id=debian-tor-0.2.8.9-1
Am I mistaken?

That said, be sure you're using a recent Tor deb:
https://www.torproject.org/docs/debian
and not the ancient Tor 0.2.5.x in vanilla jessie.

--Roger

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

Re: [tor-relays] is it possible to relay using ipv6?

[Roger Dingledine]

On Tue, Nov 22, 2016 at 04:07:56AM +0100, diffusae wrote:
> Is it safe to use 0.2.9 alpha on relays or will it be better to test the
> IPv6 client support by running Tor alpha client in a desktop environment?

In general, more testing of 0.2.9 would be great. Just make sure you stay
up to date as new releases come out, and that you pay some attention to
it so you have a chance to notice bugs (and then report them).

If all the relays stay away from 0.2.9 until we call it stable, then it
will definitely not be stable for relays. :)

--Roger

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

Re: [tor-relays] Assigning new IP adrees to current relay

[Roger Dingledine]

On Mon, Nov 28, 2016 at 08:31:39PM +, Sec INT wrote:
> - this did seem to work and tor detectedthe new address and started to use it 
> but then I got a number of warnings like
> 'Remote server sent bogus reason code'
> 
> The relay does seem to be working but with these errors im not sure

Those warnings are scary-sounding but not dangerous:
https://trac.torproject.org/projects/tor/ticket/20307

> - is the method above how you should assign a particular IP address to a Tor 
> relay?

It depends what you're trying to do. If your server has one primary IP
address but you want to be running your Tor relay on a different one,
then you probably want to set both Address and OutboundBindAddress. You
may also wish to specify an IP address in your ORPort line, to bind your
listeners to one or some but not all of your IP addresses -- but if you
don't care there's no need to do that.

--Roger

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

Re: [tor-relays] Assigning new IP adrees to current relay

[Roger Dingledine]

On Mon, Nov 28, 2016 at 11:25:29PM +, Sec INT wrote:
> Hi Thanks for the reply - exit node is all up and running along with 6 relays 
> so all happy here - I decided just to keep the main IP

Thanks for running relays!

> One thing I did have was the DirFrontpage parameter in the torrc file
>was badly formed so I commented it out but was wondering if anyone else
>had that issue? It looks fine to me from what i can see in the sample file

Can you clarify what you mean by badly formed?

Basically that option takes a file and serves it out of the DirPort
when people ask for the root ("/").

So if the file that gets served is badly formed in your browser, then
consider fixing the file. Whereas if it can't find the file, then
consider pointing it at a file that really exists. :)

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] Dir port not showing

[Roger Dingledine]

On Sun, Dec 04, 2016 at 06:06:40PM +, Sec INT wrote:
> On all my relays and Exits I set Dirport as 80 but when I look at Atlas or 
> https://torstatus.blutmagie.de all of them bar one are showing 'none' as 
> Dirport

Most likely your relay opted not to advertise its DirPort, for
example because you have AccountingMax set.

Look for a "notice" level log line on startup that says something like
"Not advertising DirPort (Reason: ...)"

If so, this is fine and normal -- your relay is saving its bandwidth
for the more important uses.

--Roger

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

[tor-relays] Please be considerate and concise on the list! [was Re: Unwarranted discrimination of relays with dynamic IP]

[Roger Dingledine]

On Sun, Dec 04, 2016 at 09:42:34PM +0200, Rana wrote:
> I hope Tor developers or whoever runs the Tor project are reading this.

Only barely. :/ I bet most of them are unable to keep up with the madness
that this thread has become.

Please, I beg all of you, consider that there are 1700 busy people
on this mailing list. Imagine people reading your post and thinking
about it and sending a reasoned useful response if they have one,
and waiting for other people to do so if they don't. Heuristics like
"one useful post per topic per day" might be helpful.

And if the topic has totally changed, please change the Subject line to
what the new topic is (like I've done here) -- otherwise people see a wall
of 80 mails and it looks like a flamewar or something and they skip it.

Thanks for your help in keeping this a manageable list,
--Roger

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

Re: [tor-relays] Connections from UNKNOWN relays

[Roger Dingledine]

On Sat, Dec 10, 2016 at 03:39:20PM +0200, Rana wrote:
> Assuming most of these are bridges, this could be a vulnerability as
>this allows rogue middle relays to enumerate bridges.

Plenty more open research problems where that one came from:
https://blog.torproject.org/blog/research-problems-ten-ways-discover-tor-bridges

(I think the one you listed is #2 of the 10.)

--Roger

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

Re: [tor-relays] Multiple Tor Instances

[Roger Dingledine]

On Sat, Dec 24, 2016 at 02:02:55PM -0700, Dakota Hourie wrote:
> Thanks nesenu, just what I was looking for. And never used ansible before,
> but that looks like it could make managing my soon to be 4 relay servers a
> breeze, will definitely check it out.

Thanks for wanting to run relays!

For 4 relays, you'll want at least 2 IP addresses, since we try to
not make it easy for somebody to spin up too many relays on too few
IP addresses.

Now you know, so it won't come as a surprise later. :)

--Roger

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

Re: [tor-relays] Minimum requirements for becoming a guard

[Roger Dingledine]

On Sun, Dec 25, 2016 at 09:47:02AM +0200, Rana wrote:
> What are the absolute minimum requirements for becoming a guard? 
>  
> [I am not asking about being trustworthy which I am obviously not, only
> about bandwidth etc. :)]

The requirements are relative to the other relays in the network:

https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2289

In short, there are three requirements:

A) You need to be up for most of the time, compared to the other
relays. Right now that's 98% weighted-fractional-uptime.

B) You need to get in the top 25% of the relays by speed. "Speed" in
this case refers to consensus weights for recent enough authorities, or
the number advertised in your relay descriptor for older authorities.
Right now that varies by authority but it's in the 4 million to 7
million range.

C) You need to have been around at least 8 days.

You can see the thresholds per authority in their votes:
https://www.freehaven.net/~arma/moria1-v3-status-votes

And I've just opened a ticket for consensus-health to display them
in a more friendly way:
https://consensus-health.torproject.org/
https://trac.torproject.org/projects/tor/ticket/21079

Hey, can somebody look through tor.stackexchange.com and see if this
question has already been asked, and if so, if this answer here is the
best answer we've got, and add them both? :) Thanks!

--Roger

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

Re: [tor-relays] Raspberry Pi + Raspbian GNU/Linux 8.0 (jessie) + bind errors

[Roger Dingledine]

On Thu, Jan 05, 2017 at 06:38:23PM -0800, Kurt Besig wrote:
> I just installed tor on a Raspberry Pi 3 Model B and can't get a relay
> to start unless I sudo. When I attempt to start tor as a non-privileged
> user I get a permissions error: Opening Jan 05 18:33:35.929 [notice]
> Opening OR listener on 0.0.0.0:443
> Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:443: Permission denied
> Jan 05 18:33:35.930 [notice] Opening Directory listener on 0.0.0.0:80
> Jan 05 18:33:35.930 [warn] Could not bind to 0.0.0.0:80: Permission denied
>  Ideas on best method to bind these ports to tor on startup as non-root?

If you're using the deb, it's actually intended to be started as root
("service tor start"), and it drops privileges once it binds to the ports.

Using the deb init script is also smart because it does things like fixing
"ulimit -n" for you so it doesn't default to 1024 (which is way too low
for a useful relay).

If you want to use iptables rules to do forwarding instead, check out
https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#HowcanImakemyrelayaccessibletopeoplestuckbehindrestrictivefirewalls

(We haven't moved that faq entry to the main faq because the deb just
handles it for you.)

(All of this might be a lie for Raspbian. I hope not though.)

--Roger

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

Re: [tor-relays] Entry relay still the same after months?weeks/

[Roger Dingledine]

On Sun, Jan 15, 2017 at 08:14:52AM +, je suis wrote:
> And my apologies if this turns out to be a simple, obvious answer, but
> ever since two(?) upgrades back, my entry relay never changed. I
> manually deleted Browser/TorBrowser/Data/Tor/state and only then it
> changed. As of the last delete, it never changed, not with "New
> identity" or with "New Tor circuit for this site". Is this an intended
> behaviour?

Yes it is.

See
https://www.torproject.org/docs/faq#EntryGuards
for the short version, and then if you want the longer version, see
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters

--Roger

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

Re: [tor-relays] Proposing an Exit Node

[Roger Dingledine]

On Mon, Jan 16, 2017 at 11:49:46PM -0700, Mirimir wrote:
> Or you need adequate anonymity, and be willing to lose sunk cost.

I think trying to run exit relays with anonymity, and with plans to
discard them as needed, is a poor plan long-term. In the struggle for
what the Internet can become, we need to be public and clear about who
we are and why privacy is important for everybody.

(Yes, that looks like a contradiction, but I claim it isn't: privacy
is about giving people choices, and to win this conflict we need some
people who will make the choice to step up and be public and build
relationships.)

This "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, 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...

The Internet is smaller and more centralized than we think, and we need
the people who run it to see us as a worthwhile positive and contributing
community.

For previous versions of this thread, see
https://lists.torproject.org/pipermail/tor-relays/2013-November/003240.html
https://lists.torproject.org/pipermail/tor-talk/2015-May/037991.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] SIGHUP causing obfs warning/disabling

[Roger Dingledine]

On Thu, Jan 19, 2017 at 01:55:10PM +1100, teor wrote:
> Occasionally, the tor process fails to shut down a pluggable transport
> process when tor exits. I believe this is an unavoidable consequence of
> unexpected or unclean tor shutdowns or crashes.

Right. This is why we changed the design in 0.2.7.1-alpha to make it
easier for pluggable transports to realize that they need to die:

- When launching managed pluggable transports, setup a valid open
  stdin in the child process that can be used to detect if tor has
  terminated. The "TOR_PT_EXIT_ON_STDIN_CLOSE" environment variable
  can be used by implementations to detect this new behavior.
  Resolves ticket 15435.

> If the pluggable transport is written to die when this happens, it is a
> bug in the pluggable transport. (Does obfsproxy have an option to die
> when the controlling process dies?)
> 
> If not, it's a missing feature in the pluggable transport.

I think the python obfsproxy has never gotten any updates to adapt
to the new Tor feature.

So, one option is to use the go obfsproxy implementation. Another
option is for somebody to patch the python obfsproxy. And who knows,
maybe there's a third good option too. :)

--Roger

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

Re: [tor-relays] Reminder: If you are on 0.2.9.x, make sure you are running 0.2.9.9

[Roger Dingledine]

On Thu, Feb 09, 2017 at 01:04:30PM -0500, Nick Mathewson wrote:
> If you are on some earlier version of 0.2.9.x, it would be really
> great if you could update your relay some time soon

And, if you're one of the many relays still on 0.2.9.8, and the reason
is something other than "oops, you're right I should upgrade", please
let us know! We're wondering in particular if there are major distros
out there that are still stuck on 0.2.9.8.

Thanks,
--Roger

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

Re: [tor-relays] Reminder: If you are on 0.2.9.x, make sure you are running 0.2.9.9

[Roger Dingledine]

On Thu, Feb 09, 2017 at 07:48:10PM +, mick wrote:
> I am. (Debian Jessie 8.7 - using the tor repos).
> 
> Attempting an upgrade from 0.2.9.8 I get nothing.

Weasel suggests that you run "apt-cache policy tor" and remember
what it says, then "apt-get update", then "apt-cache policy tor"
again and see what it says.

As far as I can tell there aren't any distros on deb.tp.o for which
0.2.9.8 is still a thing.

--Roger

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

Re: [tor-relays] Reminder: If you are on 0.2.9.x, make sure you are running 0.2.9.9

[Roger Dingledine]

On Thu, Feb 09, 2017 at 09:51:14PM +0100, Maarten A. wrote:
> My log indicates Tor 0.2.5.12 (git-6350e21f2de7272f)
[...]
> I think I read somewhere debian does security backport, hence the old
> version numbers. You probably know this already.
> 
> I'm running Debian GNU/Linux 8.7 (jessie)

Yep, that is a fine and reasonable version to run. It's old, sure,
but it should still be safe and useful. Our fine deb maintainer keeps
it patched with the more important security updates.

--Roger

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

Re: [tor-relays] Reaching out to webiron

[Roger Dingledine]

On Fri, Feb 10, 2017 at 02:36:30AM -0600, Andrew Deason wrote:
> No no, that was just me thinking about how they could/should go about
> it. I just meant, some form of downloading the entire list, instead of
> checking one-by-one via TorDNSEL.
> 
> If the consensus doc shouldn't be used for this, what should? Just
> ? I assumed lists like
> these were gathered from network-status-consensus or something.

You want the bulk exit list script:

https://check.torproject.org/cgi-bin/TorBulkExitList.py

For example,

https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=128.31.0.39&port=80

--Roger

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

Re: [tor-relays] Connectivity issues; disabling my relay

[Roger Dingledine]

On Wed, Feb 15, 2017 at 06:32:56PM +, Steven Chamberlain wrote:
> So I'm bringing my Tor relay back online

Great!

>  Short bursts of packet loss like this, if someone
> was doing that deliberately with a set pattern, would have been an ideal
> way to watermark streams going in and out of the Tor network, to do some
> timing correlations.  But I'm satisfied that's not what happened here.

Actually, there's a really interesting research subfield on *undetectable*
watermarks -- that is, injecting a signal that is essentially noise
unless you know the key that generated it, and then detecting that signal
elsewhere in the network.

For papers in this area, check out

https://www.freehaven.net/anonbib/#ndss09-rainbow
https://www.freehaven.net/anonbib/#ndss11-swirl
https://www.freehaven.net/anonbib/#pets13-flow-fingerprints

--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.9.10 dir port warning

[Roger Dingledine]

On Mon, Mar 13, 2017 at 02:06:06PM +, Logforme wrote:
> Just upgraded my relay 855BC2DABE24C861CD887DB9B2E950424B49FC34 to
> 0.2.9.10 and now I get a new warning in the log file:
> 
> Mar 13 12:02:22.000 [notice] Bootstrapped 100%: Done
> Mar 13 12:03:20.000 [warn] Cannot make an outgoing connection
> without a DirPort.
> Mar 13 12:03:21.000 [notice] Self-testing indicates your DirPort is
> reachable from the outside. Excellent. Publishing server descriptor.
> 
> Everything is working fine, just curious about the warning. Is it an
> actual problem with my setup or a quirk of 0.2.9.10?

It is a quirk of 0.2.9.10:
https://trac.torproject.org/projects/tor/ticket/20711

It's fixed in the 0.3.0 branch, which will hopefully become stable
in not too long.

For those in this situation in the future, try googling for your
strange warning text. :)

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

[Roger Dingledine]

On Sat, Mar 18, 2017 at 08:26:35PM -0500, Andrew Deason wrote:
> Ideally I'd submit a bug for this

Turns out there is one already:
https://trac.torproject.org/projects/tor/ticket/21769

Patches (to the webwml git repo) appreciated!

--Roger

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

Re: [tor-relays] Relay has Low Consensus and No Exit Flag Following Upgrade

[Roger Dingledine]

On Sun, May 07, 2017 at 02:20:42PM +0100, Chris wrote:
> However, it no longer has the exit node flag and the consensus is very
> low (20). It also is not listed as a directory.
> 
> I suspect something else during the upgrade has broken it as I had some
> SELinux issues binding to the ports before - which I resolved.
> 
> There are no errors in ARM although the log is non existent? -
> permissions error?

My first thought is that you somehow changed your identity key during
the upgrade, meaning you're now a new relay (waiting to be measured).

--Roger

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

Re: [tor-relays] GeoIP file

[Roger Dingledine]

On Sun, May 07, 2017 at 08:20:39PM -0700, Ian Zimmerman wrote:
> How does the tor daemon read the GeoIP database file?  Does it read the
> whole file once when starting up, or every time it needs to resolve an
> IP, or something in between (say, it builds an index in memory on
> startup and then seeks to locations in the file when looking up)?

It reads it once on startup, and keeps it in memory after that.

> I am asking because I want to know if I need to restart, SIGHUP or in
> some other way kick the daemon after I install a new GeoIP file into
> place.

It looks like you need to restart -- a hup won't do it.

I just filed https://bugs.torproject.org/22203 for maybe making a hup
do what you wanted, but it turns out to be complicated, so don't hold
your breath. :)

What are you doing, that needs changes to the geoip file of a running
Tor daemon?

--Roger

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

Re: [tor-relays] WannaCry fallout FYI

[Roger Dingledine]

On Sun, May 14, 2017 at 09:54:55PM +0200, niftybunny wrote:
> >Known TOR exit nodes are listed within the Security Intelligence feed of ASA 
> >Firepower devices. Enabling this to be blacklisted will prevent outbound 
> >communications to TOR networks.
> 
> Wait, what?

To help you be less surprised next time, the template to look for is:

"Additionally, organizations should strongly consider [buying our
fancy proprietary "threat intelligence" tools]. Enabling this to be
blacklisted will prevent [thing that we're trying to scare you about
without explaining, or even understanding ourselves]."

--Roger

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

Re: [tor-relays] WannaCry fallout FYI

[Roger Dingledine]

On Mon, May 15, 2017 at 09:17:33AM +0200, Cristian Consonni wrote:
> > | https://dist.torproject.org/torbrowser/6.5.1/tor-win32-0.2.9.10.zip
>
> Was the increased number of downloads from the malware visibile from the
> logs?

I looked, and there were a few hundred downloads per day. It didn't
look like a huge number. Maybe people misread the code, or maybe there
aren't actually that many infections and all the "threat intelligence"
companies want to keep talking about it anyway, or who knows.

But the low number of downloads, plus the fact that folks said they'd
disabled the ransomware component (by registering the domain it checked),
plus the fact that I hadn't investigated the worm code to figure out if
it did anything surprising when the URL is disabled, made me decide to
leave it alone.

--Roger

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

Re: [tor-relays] WannaCry fallout FYI

[Roger Dingledine]

On Mon, May 15, 2017 at 09:58:26AM +0200, Cristian Consonni wrote:
> Interesting. In fact, I though that downloading the whole browser seemed
> to be not so smart, surely there are better ways to connect
> programmatically to the tor network.

It is not the whole browser -- it is the "windows expert bundle":
https://www.torproject.org/download/download
So it is indeed stupid to treat its libraries like the cloud, but
not so stupid that it's fetching the whole tor browser.

> To my untrained eye, this malware seems to be both clever
> (self-replication) and dumb (kill switch, downloading the browser) at
> the same time.

Also ask yourself whether it checks the signature of the tor win32 thing
that it downloads before running it. :( Good thing we're not evil.

--Roger

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

Re: [tor-relays] Strange behaviour Tor 0.2.9.10

[Roger Dingledine]

On Tue, Mar 28, 2017 at 02:22:17PM +0100, Geoff Down wrote:
>  72 hours now on 2.9.9 with no clock jumps. Still occasional timeouts as
>  per above.

Hi Geoff,

Any news on your strange clock jumps? Have you tried Tor 0.3.0.x
for your bridge or relay also?

I ask because
https://trac.torproject.org/projects/tor/ticket/20423
remains open but nobody has any new news.

Thanks,
--Roger

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

Re: [tor-relays] Kitten1 and kitten2 compromised (guard/hs/fallback directory)

[Roger Dingledine]

On Mon, May 15, 2017 at 12:21:36PM +0200, aeris wrote:
> Currently, my server hosting kitten1 and kitten2 (tor guard and fallback 
> directory) is under seizure since 14/05 11h.
> Private key are under encrypted volume and may be protected, but please 
> revoke 
> immediatly kitten1 & kitten2 tor node.
> Those nodes are also fallback directory.

Thanks Aeris.

I've already revoked those two fingerprints on moria1, after we talked
in irc. The other directory authorities will revoke them when they update
and/or notice.

--Roger

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

[tor-relays] (FWD) [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for relays

[Roger Dingledine]

For those of you who are not on tor-announce... now would be a good
time to remember to subscribe to tor-announce. :)

--Roger

- Forwarded message from Nick Mathewson  -

Date: Mon, 15 May 2017 18:57:59 -0400
From: Nick Mathewson 
To: tor-annou...@lists.torproject.org
Subject: [tor-announce] Tor 0.3.0.7 is released, with a medium security fix for 
relays

Hi, all!

There's a new Tor release (0.3.0.7) available on the website.  It
fixes a bug affecting relays running earlier versions of 0.3.0.x that
could allow attackers to trigger an assertion failure on those relays.
Clients are not affected; neither are relays running versions before
0.3.0.x.

If you're running a relay with one of the affected versions, you
should upgrade.  Source is available on the website now; packages
should be available over the next several days.

===

Changes in version 0.3.0.7 - 2017-05-15
  Tor 0.3.0.7 fixes a medium-severity security bug in earlier versions
  of Tor 0.3.0.x, where an attacker could cause a Tor relay process
  to exit. Relays running earlier versions of Tor 0.3.0.x should upgrade;
  clients are not affected.

  o Major bugfixes (hidden service directory, security):
- Fix an assertion failure in the hidden service directory code, which
  could be used by an attacker to remotely cause a Tor relay process to
  exit. Relays running earlier versions of Tor 0.3.0.x should upgrade.
  should upgrade. This security issue is tracked as TROVE-2017-002.
  Fixes bug 22246; bugfix on 0.3.0.1-alpha.

  o Minor features:
- Update geoip and geoip6 to the May 2 2017 Maxmind GeoLite2
  Country database.

  o Minor features (future-proofing):
- Tor no longer refuses to download microdescriptors or descriptors
  if they are listed as "published in the future". This change will
  eventually allow us to stop listing meaningful "published" dates
  in microdescriptor consensuses, and thereby allow us to reduce the
  resources required to download consensus diffs by over 50%.
  Implements part of ticket 21642; implements part of proposal 275.

  o Minor bugfixes (Linux seccomp2 sandbox):
- The getpid() system call is now permitted under the Linux seccomp2
  sandbox, to avoid crashing with versions of OpenSSL (and other
  libraries) that attempt to learn the process's PID by using the
  syscall rather than the VDSO code. Fixes bug 21943; bugfix
  on 0.2.5.1-alpha.
___
tor-announce mailing list
tor-annou...@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

- End forwarded message -

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

Re: [tor-relays] Tor version on Debian Wheezy (oldstable)

[Roger Dingledine]

On Wed, May 17, 2017 at 05:04:29PM +0200, Cristian Consonni wrote:
> I run a couple of relays with Debian 7 Wheezy, which is the old stable
> version.

Thanks for running relays!

> AS you can see from the Debian package page[1] the latest available
> version of Tor packaged for Wheezy is 0.2.4.27-3, which to me looks
> quite behind either 0.2.5.12-4 available in Jessie (stable) or the
> 0.2.9.X series available through backports or testing.
> 
> What's the best to do in this cases?
> * Should I start updating tor manually?

Definitely don't build Tor yourself. If you want to switch to the
deb.torproject.org repo as suggested in this thread, that is a fine
option.

> * Should I update Debian on the server? (which could well me start with
> a fresh install?

Tor 0.2.4.x is still supported until Aug 1, 2017:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

But it's my understanding that Debian wheezy becomes oldoldstable once
Squeeze is declared stable? Meaning now would be a good time for you to
consider upgrading anyway? :)

> * Is it ok like it is now, provided that the system is updated?

It is ok like it is now, for the next 2.5 months, and then it will
become a bad idea.

(Who knows, maybe the nice people who step in to offer long-term-stable
support to Wheezy, if anybody does, will be convinceable to update it
to Tor 0.2.5. But running a partially supported oldoldstable is less
good than upgrading your Debian.)

--Roger

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

Re: [tor-relays] Tor version on Debian Wheezy (oldstable)

[Roger Dingledine]

On Wed, May 17, 2017 at 06:13:55PM -0400, Roger Dingledine wrote:
> But it's my understanding that Debian wheezy becomes oldoldstable once
> Squeeze is declared stable? Meaning now would be a good time for you to
> consider upgrading anyway? :)

Whoops, I meant Stretch, not Squeeze. Sorry for the spam.

--Roger

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

Re: [tor-relays] Tor version on Debian Wheezy (oldstable)

[Roger Dingledine]

On Wed, May 17, 2017 at 08:45:26PM +0500, Roman Mamedov wrote:
> > https://www.torproject.org/docs/debian.html.en
> > 
> > You'd probably tell it you use old stable and want Tor version stable. 
> > After a couple of apt commands, I predict you will end up with Tor 0.3.0.7
> 
> No he will not, as nobody cares to update the Tor stable repository for
> 0.3.0.7, all you get on stable is 0.2.9.10.

My guess is that our fine debian maintainer is leaving it at 0.2.9.10
while Stretch finishes its freeze and goes stable:
https://wiki.debian.org/DebianStretch

Tor 0.2.9.x is our most recent long-term-stable release:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Listofreleases

So it is wiser to have 0.2.9 in the next Debian stable, rather than
using 0.3.0 and then having Tor want to abandon 0.3.0 well before
Stretch's expected lifetime.

More context: with the quicker release period for the Tor program, we
realized we can't actually support every single stable release version
for years, or we'll go mad. So we adopted the "long term stable" idea
that's been going around lately, and we coordinated with Debian to make
sure their stable and our LTS lined up:
https://blog.torproject.org/blog/updates-old-tor-stable-release-series-02428-02513-02611-0277-02813

I don't think we did any coordination with Ubuntu though, since there
is nobody there to coordinate with. :(

--Roger

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

Re: [tor-relays] seized relays reported for blacklisting?

[Roger Dingledine]

On Sat, May 20, 2017 at 04:01:04AM +0200, Tobias Sachs wrote:
> any idea how to avoid the guard flag at this time?
> My only idea is to trottle down the speed but this is a bad solution imho.

I don't think there's an easy way.

If you set "DirCache 0" in your torrc file, then you will still get
the Guard flag, but you'll lose the V2Dir flag, which will make clients
running 0.3.0.x and later decide that you're not usable as a Guard.

But the stable Tor Browser releases still ship Tor 0.2.9.x, which
is willing to use Guards that don't have the V2Dir flag.

One answer that is still crummy but is less crummy than throttling
is to give the relay some downtime every so often, so its
weighted-fractional-uptime doesn't look attractive, so the authorities
won't give it the Guard flag. You could compensate for the downtime by
running two relays, and swapping between them.

But that's a lot of work. What is your goal here? If the goal is to avoid
running a thing on the Internet that scared incompetent cops might try
to mess with, then I would be tempted to argue that you'll have better
success (albeit maybe still not much) fixing the cops.

(Or empowering and educating the ISPs, and/or choosing hosting at an
ISP that is already empowered and educated. Maybe the people at OVH
would have some statement like "I could do nothing, they were cops",
but there are plenty of things they could have chosen to do to help
everybody understand what's going on, then and in the future. Or maybe
they did these things? It's hard to know from the outside.)

In this particular case, it looks like a bunch of people who don't
understand the Internet went berserk in response to Wannacry, and it also
looks like they're done going berserk in this particular case. It's hard
to know how to extrapolate from this one data point, but I would hope it
will be a good long while until some other situation like this, and also
there's nothing to say it will necessarily happen at OVH again next time.

Oh, and while I have your attention: if anybody wants to do some
historical Tor directory data mining, so we can make it less scary when
bad guys steal your relay identity key, check out
https://trac.torproject.org/projects/tor/ticket/22308
"Consider resetting wfu/mtbf/tk values for relays when they switch IP
addresses"

--Roger

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

Re: [tor-relays] Kitten1 and kitten2 compromised (guard/hs/fallback directory)

[Roger Dingledine]

On Sun, May 21, 2017 at 09:12:39AM +0200, Petrusko wrote:
> What will they find ?
> A Debian who ask a password to unlock the system, or it will stop booting ?
> Yeah, if police can read the system entirely, it looks like impossible
> to find something about the guyz behind the wannacry software ?

Correct. Not only that, but remember that they took the relay because
a *victim* contacted it, not because they think the "guyz behind the
software" did.

> Tor is not logging anything else than informations about uptimes/nb
> connections... what can be interesting for police by unpluging those
> guards relays ?

Typically that's why cops choose not to bother Tor relays -- because
they know there will be nothing useful. But every so often there's a
new cop that doesn't understand the Internet and just wants to collect
all the computers at the IP addresses on his list. Hard to teach them all.

> @aeris, do they ask you to uncrypt the volume ? (good luck to you...)
> What can be the best ? Uncrypt the relay to help police when asking,
> when this relay is only a relay and storing nothing else ?

That's actually why the torservers.net people suggest *not* using disk
encryption. Having no barriers makes it much easier for the police to
realize that there's nothing useful to them. See also point two of
https://blog.torproject.org/blog/trip-report-tor-trainings-dutch-and-belgian-police

--Roger

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

Re: [tor-relays] Memory Problems with tor releay

[Roger Dingledine]

On Mon, May 22, 2017 at 10:48:31PM +0200, niftybunny wrote:
> Same with 0.3.0.5. Upgrading to 0.3.0.7 helped on most relays. 

We didn't change anything between 0.3.0.5 and 0.3.0.7 that would
have helped.

If somebody with a really really fast CPU wants to run their relay under
valgrind --leak-check for a while, that would be grand.

https://gitweb.torproject.org/tor.git/tree/doc/HACKING/HelpfulTools.md

The question to try to get some answers on is what sort of bloat problem
we have:

A) Maybe it's a memory leak?

B) Maybe it's an inefficiency of the memory allocator, e.g. fragmentation
where nothing is technically leaked yet there's a whole lot of wasted
space?

C) Maybe it is some behavior by clients that causes the relay to use a
lot of memory, e.g. by having a bunch of stuff in buffers? The behavior
could be accidental / normal, or it could be intentional / malicious.

My first guess is "C, accidental". But it could easily be 'B', and it
would be great if it's 'A' because then we can just fix it.

--Roger

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

Re: [tor-relays] Memory Problems with tor releay

[Roger Dingledine]

On Tue, May 23, 2017 at 03:01:10AM +, John Ricketts wrote:
> Roger,
> 
> I have whatever resources you need for testing.  Let me know if you would 
> like them.

1)
git clone https://git.torproject.org/git/tor
cd tor.git
./autogen.sh && ./configure && make

2) edit /etc/security/limits.conf to have "tord hard nofile 65536" and
"tord soft nofile 65536" lines, where tord is your user who will run it.

3)
valgrind --leak-check=yes --error-limit=no --undef-value-errors=no src/or/tor 
orport 9001 dirport 9030 nickname sorryitsslow geoipfile src/config/geoip

(You might also want to set datadirectory, etc if you prefer, or point
it to a torrc file if you prefer. Once you've got it working, you might
run it with a datadirectory that has keys for an established relay.)

Then watch the output for interesting valgrind complaints (I don't
expect any, but if you find some, great!), and when you've let it
run for a while, ^C it, let it close down, and see if Valgrind tells
you about any "definite" memory leaks.

Be aware that unless the CPU is super amazing, it will be totally cpu
saturated and constantly failing to keep up with the requests it receives.
So it is a fine thing to do for active bug hunting, but somewhat rude to
do on real relays. :)

--Roger

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

Re: [tor-relays] Problem starting 0.3.0.7 on Ubuntu?

[Roger Dingledine]

On Tue, May 23, 2017 at 01:43:37PM +1000, teor wrote:
> > HiddenServiceDir /var/lib/tor/SERVICE_NAME/
> 
> What are the permissions on each of the enclosing directories?
> (Tor checks permissions recursively in some cases.)
> 
> In 0.3.0.7, we made a number of hidden service checks stricter.
> Perhaps one of the checks is too strict.

Earlier in this thread, Alexander said:
| The permissions on /var/lib/tor/SERVICE_NAME/ are "rwx--S---" and it's
| owned by debian-tor, which worked for 0.2.9.10."

I asked weasel about this question, and he pointed me to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862993
which looks exactly like Alexander's issue.

It doesn't affect Debian by default, because Debian doesn't have
apparmor enabled by default.

So, the short term workaround for Alexander would be to add the line that
intrigeri suggests to the apparmor profile. The better fix imo will be
for Tor to stop doing behavior that the apparmor profile wants to prevent,
such as trying to read directories before it has switched uids. I'll
open a ticket about that once I understand it more.

--Roger

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

Re: [tor-relays] Problem starting 0.3.0.7 on Ubuntu?

[Roger Dingledine]

On Tue, May 23, 2017 at 03:32:49AM -0400, Roger Dingledine wrote:
>  The better fix imo will be
> for Tor to stop doing behavior that the apparmor profile wants to prevent,
> such as trying to read directories before it has switched uids. I'll
> open a ticket about that once I understand it more.

https://bugs.torproject.org/22331

--Roger

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

Re: [tor-relays] Memory Problems with tor releay

[Roger Dingledine]

On Wed, May 24, 2017 at 08:49:38PM +0200, tor-relay.d...@o.banes.ch wrote:
> Hello Roger,
> 
> I updated the ticket. You will find the output of the valgrind there as
> well:
> https://trac.torproject.org/projects/tor/attachment/ticket/22255/valgrind.txt

Well, you are a winner, in that you found a new Tor bug (in
0.3.1.1-alpha):
https://bugs.torproject.org/22368

Once we resolve that one, I'll ask for another valgrind run. :)

--Roger

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

Re: [tor-relays] Memory Problems with tor releay

[Roger Dingledine]

On Wed, May 24, 2017 at 07:51:50PM -0400, Roger Dingledine wrote:
> Well, you are a winner, in that you found a new Tor bug (in
> 0.3.1.1-alpha):
> https://bugs.torproject.org/22368
> 
> Once we resolve that one, I'll ask for another valgrind run. :)

Ok, we merged the fix for bug 22368.

If anybody wants to resume running valgrind on git master to hunt
for memory issues, we're eagerly awaiting more reports. :)

--Roger

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

Re: [tor-relays] exit relay consensus weight

[Roger Dingledine]

On Thu, May 25, 2017 at 08:20:16PM -0700, Arisbe wrote:
> I just made an interesting observation that I thought I would share.
> Yesterday I started a VPS exit relay at a well known hosting company
> in Moldova [0]. Within 24 hours I saw the consensus weight exceed
> 1.  The relay is bandwidth limited to 10 MiB/s.  Not that I'm
> complaining!

Thanks for running an exit relay!

(Using data files from
https://collector.torproject.org/recent/relay-descriptors/consensuses/)

$ grep -A4 "^r TorExitMoldova" 2017-05*|grep "w "
2017-05-24-20-00-00-consensus-w Bandwidth=0 Unmeasured=1
2017-05-24-21-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-24-22-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-24-23-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-00-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-01-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-02-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-03-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-04-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-05-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-06-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-07-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-08-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-09-00-00-consensus-w Bandwidth=20 Unmeasured=1
2017-05-25-10-00-00-consensus-w Bandwidth=8460
2017-05-25-11-00-00-consensus-w Bandwidth=8460
2017-05-25-12-00-00-consensus-w Bandwidth=8180
2017-05-25-13-00-00-consensus-w Bandwidth=8180
2017-05-25-14-00-00-consensus-w Bandwidth=8180
2017-05-25-15-00-00-consensus-w Bandwidth=8180
2017-05-25-16-00-00-consensus-w Bandwidth=8180
2017-05-25-17-00-00-consensus-w Bandwidth=8180
2017-05-25-18-00-00-consensus-w Bandwidth=8180
2017-05-25-19-00-00-consensus-w Bandwidth=9670
2017-05-25-20-00-00-consensus-w Bandwidth=9670
2017-05-25-21-00-00-consensus-w Bandwidth=9670
2017-05-25-22-00-00-consensus-w Bandwidth=9670
2017-05-25-23-00-00-consensus-w Bandwidth=9670
2017-05-26-00-00-00-consensus-w Bandwidth=9670
2017-05-26-01-00-00-consensus-w Bandwidth=9670
2017-05-26-02-00-00-consensus-w Bandwidth=9670
2017-05-26-03-00-00-consensus-w Bandwidth=9670

Here's what I think happened:

A) You started up your exit relay the evening of May 24 UTC, and it
published a descriptor with a tiny amount of bandwidth in it (from
self-testing).

B) Somehow, it attracted a traffic flow that was very high volume.
Its consensus weight was tiny, but there are millions of Tor clients,
so maybe one of them chose it anyway. Or maybe the bandwidth authorities
themselves added this load. I'm not sure how step 'B' happened, but
however it did, your relay handled a lot of traffic, so it learned that
it *could* handle a lot of traffic, so it published new relay descriptors
saying that it's quite fast.

It has published three descriptors so far. The third number on the
bandwidth line is its self-reported capacity:

published 2017-05-24 19:50:38
bandwidth 10485760 12582912 145408

published 2017-05-24 23:34:24
bandwidth 10485760 12582912 6487186

published 2017-05-25 15:39:43
bandwidth 10485760 12582912 11526593

C) By the time the bandwidth authorities got around to measuring it,
it was already proudly self-reporting a big capacity. The way the
bandwidth authorities work is that they decide a modification to the
self-reported number, depending on how you perform compared to your peers
who self-report a similar number. You perform about average compared
to your peers, so they gave you a consensus weight that is around the
number you were self-reporting.

> So it begs the question:  Is there not enough exit relays on the Tor
> network?

Well, exit relays attract traffic in a very different pattern than
guard relays. The blog post that we always point people to:
https://blog.torproject.org/blog/lifecycle-of-a-new-relay
has to do with how a fast non-exit relay will grow over time.

So it is much more normal for your consensus weight to grow quickly for
an exit relay. (Well, expected. It's hard to say what is normal with
the weird broken design that is the bandwidth authority subsystem these
days. :)

As for whether there are not enough exit relays... always! :) We actually
have about a third of the capacity of the network in Exits right now,
so from a load balancing perspective, it's not a disaster, since clients
avoid using the exit relays for any other positions in their circuits,
and it works out ok. But from the perspective of resistance against
correlation attacks, which is largely a function of diversity of entry
points and exit points, then having only 1/3 of the network as a possible
exit point means things aren't as good as they could be.

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] published descriptor missing from consensus

[Roger Dingledine]

On Sun, Jun 04, 2017 at 12:30:20AM -0500, Scott Bennett wrote:
>  Late Wednesday afternoon, I restarted my relay (MYCROFTsOtherChild),
> which changed it from 0.3.0.6 to 0.3.0.7.  That was the only change I made.
> It went through a normal startup and published its descriptor.  After a few
> hours, tor noticed that its descriptor was still not in the latest consensus

Interesting mystery! You always have the most exciting mysteries. :)

I just instrumented moria1 to be more detailed on why it doesn't find
each relay reachable, and here's what I found:

Jun 04 18:12:44.147 [info] dirserv_single_reachability_test(): Testing 
reachability of MYCROFTsOtherChild at 73.246.41.113:32323.
Jun 04 18:13:47.147 [info] connection_handle_write_impl(): in-progress connect 
to 73.246.41.113:32323 failed. Removing. (Connection timed out)

Jun 04 18:34:04.205 [info] dirserv_single_reachability_test(): Testing 
reachability of MYCROFTsOtherChild at 73.246.41.113:32323.
Jun 04 18:35:07.205 [info] connection_handle_write_impl(): in-progress connect 
to 73.246.41.113:32323 failed. Removing. (Connection timed out)

So it would appear that it's trying to make a TCP connection, and
after 63 seconds, it decides it's not going to work.

It would seem that 6 of the 8 directory authorities are not voting the
Running flag, so I guess they are seeing something similar (or would be
if they hacked their logs up to display it).

This is weird, because when I telnet to your IP:port, it connects
easily. And when I set your IP:port as my bridge address, my Tor client
bootstraps fine.

So I am left wondering if there's something different about how Tor
requests that the system launch a TCP connection, or if Comcast or
your system is somehow filtering (or not being able to handle) certain
connection attempts.

--Roger

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

Re: [tor-relays] published descriptor missing from consensus

[Roger Dingledine]

On Sun, Jun 04, 2017 at 07:14:06PM -0500, Scott Bennett wrote:
>  Which versions are the Running votes coming from versus the non-Running?

You can see the votes at
https://www.seul.org/~arma/moria1-v3-status-votes

>  I have a few commands in a crontab entry that extract relay IP addresses
> from the most recently received consensus, sort them, and load them into a
> table in pf.  They run every 15 minutes.  Anything coming from the addresses
> in the table is immediately passed.  Anything not passed gets checked against
> a much larger table of probers, attempted intruders, etc. and is blocked if it
> matches a table entry.

Well heck. Sounds like we have a winner here.

Turn off your weird censorship infrastructure, confirm that things
start working after a while, and now you have something to debug. :)

--Roger

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

Re: [tor-relays] 2017-06-07 15:37: 65 new tor exits in 30 minutes

[Roger Dingledine]

On Wed, Jun 07, 2017 at 03:50:54PM -0400, David Goulet wrote:
> On 07 Jun (19:41:00), nusenu wrote:
> > DocTor [1] made me look into this.
> > 
> > _All_ 65 relays in the following table have the following characteristics:
> > (not shown in the table to safe some space)
> 
> Yah, we got a report on bad-relays@ as well... We are looking into this but
> seems there is a distinctive pattern for most of them.

Update: we set things in motion this afternoon to cut the relays out of
the network. Also, we have a plausible guess about where they came from,
and we contacted the company that we think controls the IP addresses, so
they can figure it out / clean up as needed.

Thanks!
--Roger

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

[tor-relays] How to detect Tor exit IP addresses (was Re: [SOLVED] published descriptor missing from consensus)

[Roger Dingledine]

On Thu, Jun 08, 2017 at 05:30:37PM -0500, Scott Bennett wrote:
>  Consider another case.  Users have often complained that running a tor
> relay results in their IP addresses being blocked by all manner of services
> around the Internet.  The providers of those services say they have suffered
> attacks originating from tor relays.  The project's response was to create
> an automatically, frequently updated list of IP addresses of exit relays and
> make that list available for download by anyone wishing to block traffic from
> tor exits, while allowing traffic from all other relays.  That list of
> addresses suffers the same problem of not including alternative IP addresses
> for those relays.  Even worse, troublesome connections from those alternative
> addresses *can* be traced back, in some cases, to the exit relay.  Once those
> services have identified the offending traffic as coming from a machine they
> had been promised by the tor project would be in the downloadable list of
> exit relay addresses, they may decide that they had been deceived by the tor
> project, which could lead to many bad things in the future.

I think we might have to agree to disagree about a lot of these topics,
but I wanted to correct this one.

The bulk exit list:
https://check.torproject.org/cgi-bin/TorBulkExitList.py
along with TorDNSEL is designed to handle exactly this situation, and
it does it pretty well.

--Roger

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

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Roger Dingledine]

On Fri, Jun 09, 2017 at 01:05:43AM -0500, Scott Bennett wrote:
> > I think you will find this is not an uncommon configuration among
> > high-bandwidth relays.
> 
>  I will check further into the procedure for which Roger posted a URL
> to see whether it will indeed give me a list of such addresses that I can
> use.  If so, I will certainly begin running it, scraping the addresses,
> and merging them with the addresses already going into table creation.

It will not do what you want. It is only for exit addresses.

--Roger

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

Re: [tor-relays] keypair does not match its older value

[Roger Dingledine]

On Tue, Jun 20, 2017 at 11:04:31PM +0100, Alexander Nasonov wrote:
> I tried moving a tor relay with offline master key to a new host but
> something went wrong and it printed several warnings:
> 
> http status 400 ("Looks like your keypair does not match its older value.") 
> response from dirserver

This complaint happens when in the past you ran the relay with a given
RSA identity key and ED identity key, and now one of them has changed.

> What did I screw up and how to fix this problem if it happends again?

Either move back to both of the original identity keys, or discard both
identity keys and start fresh.

> I suspect it will happen again because I generate a new signing key more
> frequently than necessary. I create '15 days' key every week and upload
> it (over onion ssh connection). This scheme should be resistant to
> occasional upload failures but it's not clear which of the last three
> signing keys to use on restart. If passing the wrong key can bring down
> the relay I need to switch to a different scheme.

In theory (i.e. assuming no surprising bugs), updating your signing key
should not be relevant here.

(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] Exit / Bad Gateway

[Roger Dingledine]

On Tue, Jun 27, 2017 at 03:52:31PM +0200, Sebastian Urbach wrote:
> Well Faravahar is finally back but im still wondering why my System (located
> in France) is measured by exactly 1 System a few thousand miles away.

Actually, it's measured by three bwauths. You can look it up on
https://www.freehaven.net/~arma/moria1-v3-status-votes
(Careful, it is a very large file.)

In ParEpistemenTaksis's case, it has bwauth measurements from moria1,
longclaw, and Faravahar.

It looks like teor's thought that at least one bwauth is sufficient to
get moved off of consensus weight 20 wasn't right. You need three:
https://gitweb.torproject.org/tor.git/tree/src/or/dirvote.c?id=tor-0.3.0.8#n1990

Which on further thought makes sense -- if only rogue dir auth could
by itself declare that all its friends in the unmeasured relays set
are actually consensus weight 1e9, that wouldn't be cool.

So then your question would be "ok, there are four bwauths, how come
gabelmoo hasn't measured me?"
https://consensus-health.torproject.org/#bwauthstatus
And that is a fine question, but I fear the answer is the same as all
the other "why is the torflow stuff broken" questions. Tom Ritter has
been looking lately at making it better, at least.

(Thanks for running an exit relay! :)

--Roger

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

Re: [tor-relays] GeoIP file

[Roger Dingledine]

On Thu, Jun 29, 2017 at 11:49:58AM +1000, teor wrote:
> > There is fresh geoip data posted on maxmind.com monthly.  Doesn't it
> > make sense to have the daemon use it?
> 
> No, we process the file, and update it when we do a release.
> And at that point, the tor daemon is restarted anyway.
> 
> GeoIP is not that accurate anyway, particularly for servers.
> So there's no need to have it updated every month rather than every
> release.

Also, having relays and clients not splintering the anonymity sets could
be smart. If everybody has a slightly different geoip file, especially
if only a few people have some of the differences, that could be bad
news. For an example, say there's a country that had no entries last
month, but now has a few entries, and only a few relays switch to the
new geoip file, and there's a user who connects from that address block.

We already have things splintered by Tor releases, but at least there
aren't that many of them, and most relays are on one of a handful of
versions.

> Also, if tor retrieved the file from maxmind.com directly, that could
> cause all sorts of load, privacy, and security issues.

That design (well, retrieving from the directory authorities, not from
maxmind) was actually one that we considered:

https://gitweb.torproject.org/torspec.git/tree/proposals/126-geoip-reporting.txt#n186

--Roger


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

Re: [tor-relays] [warn] channelpadding_ and [warn] assign_

[Roger Dingledine]

On Mon, Jul 03, 2017 at 09:58:02PM +0200, Felix wrote:
> [warn] channelpadding_compute_time_until_pad_for_netflow: Bug: Channel
> padding timeout scheduled 212ms in the past. Did the monotonic clock just
> jump? (on Tor 0.3.1.3-alpha dc47d936d47ffc25)

https://bugs.torproject.org/22212

> and
> 
> [warn] assign_to_cpuworker failed. Ignoring.

https://bugs.torproject.org/22356

> Seems without impact to performance. I just wonder.
> Switching to 3.1.4a might fix it ?

The 0.3.1.4-alpha changelog lists both of these tickets. So, let us know
if they continue once you've updated!

--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 operators at DEF CON

[Roger Dingledine]

On Thu, Jul 27, 2017 at 03:01:48PM -0700, Joel Cretan wrote:
> If anyone at DEF CON is interested in meeting up, perhaps we could set up a
> meeting time, maybe in/around the Crypto and Privacy Village. Of course
> we're all interested in anonymity, so no pressure to speak up. But if
> enough people tell me they're interested, I'll try to organize something.

Sounds great! I have a talk in track 4 tomorrow at 13:00 (describing the
problems with the old onion service design and what we've done to fix
those problems), and I bet there will be a bunch of relay operators there
too, so you could use the "everybody mobs Roger with questions in the
hallway after the talk" opportunity to get critical mass for a meet-up. :)

--Roger

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

Re: [tor-relays] 100K circuit request per minute for hours killed my relay

[Roger Dingledine]

On Thu, Jul 27, 2017 at 08:48:35PM +0300, Vort wrote:
> >  This sort of thing has been going on for many years.  I used to refer
> > to it as "mobbing".  As nearly as I was ever able to determine, the behavior
> > is an unintended consequence of hidden services.
> 
> Same thing started to happen today and I have noticed that 100% CPU
>   usage spikes happens every hour and lasts for several minutes.
> During this spikes, all cores of CPU are used and stack trace points
>   somewhere at worker_thread_main() function.
> Also today relay have more connections than usually (5500 vs 2000-3000).
> Is this pattern matches the characteristics of hidden services work?

Yes. Your relay is getting way more circuit create attempts than it
usually does, and all your signs point to the "HSDir hotspot"
phenomenon.

Each onion service has six relays each day that serve as the place for
fetching its onion descriptor, and some onion services are super popular
(for example, back in the day, the August 2013 botnet used an onion
service for coordinating its millions of bots).

Tor isn't great at parallelizing all of its crypto, but it is good at
parallelizing the circuit handshakes, which would be why all of your
cores are being used.

And clients building paths to your relay will use a variety of middle
hops, meaning more relays than usual will have made a direct connection
to your relay lately.

If there's one super popular onion service, then 6/3719 = ~0.16% of the
relays will feel the pain on any given day. More than one super popular
onion service would make that number go up.

One fix would be to raise the bar for getting the HSDir flag, so relays
with the flag are better able to handle the phenomenon. But shrinking the
total number of HSDir relays can make other attacks easier. Another fix
would be to spread the load for each onion service, or maybe for popular
onion services, over more than six relays. But that would open up more
surface area for attacks to e.g. measure popularity of an onion service.
I think there is not an easy fix.

--Roger

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

Re: [tor-relays] Go home GeoIP, you're drunk.

[Roger Dingledine]

On Thu, Aug 03, 2017 at 11:52:00PM +0200, Ralph Seichter wrote:
> I moved a Tor relay to new hardware, keeping the keys. Both old and new
> server are located in Germany and provided by the same hosting company.
> After the latest Atlas update, I was surprised to see that the IPv4
> address is listed as belonging to an AS in Ukraine. A little more
> digging returned Guangzhou, China, as the supposed location based on the
> server's IPv6 address.

Yeah, that pattern happens a lot with IPv4 addresses in Germany and
Netherlands in particular, because they "lend" them out to more remote
countries like Nigeria, and then take them back a few years later,
and the whois databases are always a bit behind.

> Is there anything I can/should do about this (I doubt it)? Will this
> affect my Tor node consensus weight? As it is not an exit node, I am
> hoping it won't matter much.

It should not affect your consensus weight -- that number is made by
several vantage points actually making Tor circuits through relays
including yours, and those vantage points don't care what the geoip
database says about your 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] Tor 0.3.0.10 not listed as a recommended version

[Roger Dingledine]

On Sat, Aug 05, 2017 at 12:34:35PM +0200, Ralph Seichter wrote:
> Hello,
> 
> after updating to Tor 0.3.0.10, I see the following warning on my nodes:
> 
>   This version of Tor (0.3.0.10) is newer than any recommended version
>   in its series, according to the directory authorities.
> 
> Could one of the devs please update the relevant data? Thanks.

Yep -- moria1 is the only one of the three dir auths recommending
0.3.0.10:
https://consensus-health.torproject.org/#recommendedversions

I just moved things forward a bit to get gabelmoo and tor26 recommending
it too.

Also, I opened two tickets, one for making this particular situation
less likely to happen again, and another for fixing the whole treadmill
where people have to edit text files before a new version should come out:
https://bugs.torproject.org/23118
https://bugs.torproject.org/23119

Thanks,
--Roger

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

Re: [tor-relays] Tor exit nodes attacking SSH?

[Roger Dingledine]

On Wed, Aug 09, 2017 at 10:58:01AM +0500, Roman Mamedov wrote:
> > No, dropbear is an SSH server that 8.8.8.8 seems to be running.
> 
> Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public
> SSH server at all (obviously).
> 
> The point was to demonstrate that the exit node intercepts port 22 connections
> to any IP, and redirects them to the same particular instance of dropbear.

Right -- it seems clear that there is some exit relay out there that is
handling requests for 8.8.8.8:22 (and probably *:22) poorly. If somebody
can tell us which one it is, we'll get rid of it.

(Several groups who run scanners for this sort of thing will hopefully
pick this thread up in the next day or so and we can resolve it then.)

--Roger

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

Re: [tor-relays] Tor exit nodes attacking SSH?

[Roger Dingledine]

On Wed, Aug 09, 2017 at 02:41:34AM -0400, Roger Dingledine wrote:
> Right -- it seems clear that there is some exit relay out there that is
> handling requests for 8.8.8.8:22 (and probably *:22) poorly. If somebody
> can tell us which one it is, we'll get rid of it.

Ok, we have identified the relay and begun the process of kicking it
out of the network. It's some jerk on digital ocean.

Thanks,
--Roger

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

[tor-relays] Two research groups studying onion services and running relays

[Roger Dingledine]

Hi relay operators!

I want to let you know about two upcoming research projects by academic
research groups. The tl;dr is that they're running relays to do certain
measurements, and so far as we can tell the proposed methodology is
safe enough and worthwhile enough, but we invite you (and everybody)
to evaluate it too.

If you didn't already know about the Tor Research Safety Board, now
you do:
https://research.torproject.org/safetyboard.html
https://blog.torproject.org/blog/tor-heart-pets-and-privacy-research-community
The board's goal is to help researchers do better and safer research,
that is, to *minimize privacy risks while fostering a better understanding
of the Tor network and its users*.

The board has been low-profile so far because it's just starting up,
but now that we've handled six cases, I've put the details of some of
these cases up on the safety board page:
https://research.torproject.org/safetyboard.html#examples
(Some of the cases are still anonymized because their paper is not yet
finished or submitted or accepted.)

In particular, check out cases 2017-02 and 2017-03. They have each
put up a web page explaining their research project and why it's safe,
and listing which relays are associated with the research.
http://tor.ccs.neu.edu/
https://onionpop.github.io/

Let us know if you have any questions.
--Roger

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

Re: [tor-relays] 60 new neu.edu relays in 16 minutes

[Roger Dingledine]

On Wed, Aug 09, 2017 at 05:03:00PM +, nusenu wrote:
> Note: There is nothing wrong with adding 60 tor relays, especially with
> proper MyFamily configuration as you did.

Hi Nusenu,

You beat me by a day -- I had drafted my earlier mail about the two
research groups running relays, but decided to save it until I'd
gotten some sleep. :)

In this case, you can read more about their research plans here:
http://tor.ccs.neu.edu/

And I bet some of the researchers are on this list, if you want to ask
them more detailed questions.

Thanks,
--Roger

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

Re: [tor-relays] Two research groups studying onion services and running relays

[Roger Dingledine]

On Thu, Aug 10, 2017 at 12:15:00AM +, nusenu wrote:
> Isn't that more relevant to HS operators than relay operators?

No, not really. The relay operator community is the one with standards and
consensuses about what counts as a well-behaving relay, and what kinds of
"groups of relays that might look like a Sybil attack" are acceptable,
and (related to the Sybils) how much of the network any one entity
should control.

> > I want to let you know about two upcoming research projects by academic
> > research groups. The tl;dr is that they're running relays to do certain
> > measurements, and so far as we can tell the proposed methodology is
> > safe enough and worthwhile enough, but we invite you (and everybody)
> > to evaluate it too.
> 
> Do you review the design and implementation or design only?

Design only. There's an argument to be made for looking at the code
too, but if I wanted to do that correctly, I would want to observe the
deployment as well, and go check out the configuration of the machines,
and interview the grad students who will be handling the data sets,
and etc etc. I'm not sure where to draw the line, but assessing what
they plan to do seems like a reasonable choice.

> > In particular, check out cases 2017-02 and 2017-03. They have each
> > put up a web page explaining their research project and why it's safe,
> > and listing which relays are associated with the research.
> > http://tor.ccs.neu.edu/
> 
> Trying to access this page via https times out.
> https would be appreciated.

I noticed that too, but I guess not everybody is on the Let's Encrypt
bandwagon yet. :)

> http://tor.ccs.neu.edu/safety-board.pdf wrote:
> > An adversary compromising  $n-1$   HSDir servers   
> > cannot infer anything about counters or onion addresses.
> 
> If you design a system with these properties
> shouldn't the ISP also be part of your threat model?
> (especially with what we observed lately in FR)

I think that's why they have three different locations (operated by
three different research groups) for the relays.

But oh hey, you're right, it looks like their implementation was simply
to have three different research groups all run relays at the same ISP. :(

Especially when they're all on VMs, it becomes a more straightforward
exercise than I think they realize for the ISP to just go suck out all
the memory of these systems.

> Does the stated geo-diversity relate to the entities operating the
> measurement nodes or the location of the measurement nodes themselves?
> (I guess it is the former)
> 
> If the list of fingerprints at http://tor.ccs.neu.edu/
> is in fact complete and Maxmind has proper IP-to-AS data for these IPs
> than _all_ participating measurement servers are hosted using a
> _single_ hoster.

Yes, it sure looks like this is the case.

--Roger

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

Re: [tor-relays] 60 new neu.edu relays in 16 minutes

[Roger Dingledine]

On Thu, Aug 10, 2017 at 07:53:03PM -0400, priv...@ccs.neu.edu wrote:
>  We are using Online S.a.s because it it is cheap (I guess it's the same 
> reason why others use it). We will check in the next couple of days if there 
> is an alternative low cost provider.

If I understand the threat model for your "every relay encrypts its
share, and then you do threshold decryption of the aggregate total"
design, having even a few relays at some other ISP would make it a lot
harder for the one ISP to attack all of the shares, right?

Maybe you can spin up one relay at each research institution, for
some diversity? :)

That said, I'm not too worried here. The information you're protecting in
this case isn't by itself that dangerous to publish, so the complicated
privcount scheme is a great layer to add on top but the world doesn't
end if it fails.

So if you wanted to add some more relays to make the "distributed trust"
angle more distributed, great, and if you don't, we can treat it as a
good lesson to learn for next time.

> We have also limited our bandwidth but can increase it if more people express 
> interest and it can help (we didn???t want to look like we are trying to 
> attract/intercept traffic).

Interesting question! I can see pros and cons.

The two big topics are:

1) If you raise the bandwidth on each of them by enough, then they'll end
up getting the Guard flag, so you'll attract clients directly, and your
relays will be in a better position to attack them.

2) If you raise the bandwidth, then the total fraction of the Tor network
that your relays handles go up.

I'm tempted to say "as long as you stay at 2-3% of the total network
you'll be fine", but the fact that they're all at an already overpopulated
ISP makes me pause.

--Roger

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

Re: [tor-relays] New Here

[Roger Dingledine]

On Sun, Aug 13, 2017 at 08:51:05PM +0200, Dirk wrote:
> I observed the same thing on our new exit. atlas says its down - but
> actually it is working. Did you test if you could exit through your
> relay at this time ?

Another thing to check is whether your relay is listed in the consensus
documents for those hours.

https://collector.torproject.org/recent/relay-descriptors/consensuses/

That will help you narrow down whether it's an atlas (or onionoo) issue,
or if you're actually missing from the consensus documents.

Note that the consensus file names use UTC for their time zone.

And if your relay *is* missing from the consensus, you can look at
the votes for it at
https://collector.torproject.org/recent/relay-descriptors/votes/
and try to figure out which authorities found it Running and which
didn't.

--Roger

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

Re: [tor-relays] blocking >1 connections per ip address onto Tor DirPort

[Roger Dingledine]

On Tue, Aug 15, 2017 at 11:52:31PM +0200, Toralf Förster wrote:
> Does a particular Tor server/client will open more than 1 connection
>at a time from to the DirPort ?

I think we definitely want to support that in the protocol.

I'm not sure whether it happens right now, but it might.

But preventing it from happening is likely bad.

Note that most clients use the ORPort for fetching directory stuff,
and that's heading towards "all clients" as people upgrade and stop
using weird configurations. So the DirPort is mainly used on authorities
(by relays that fetch dir stuff or upload relay descriptors), and by
auxiliary tools like stem and the various metrics project scripts.

If you're worried about denial of service issues on the DirPort, maybe
the simple answer is to turn off the DirPort? I think the only real
impact might have something to do with whether old clients believe that
you're a usable guard.

--Roger

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

Re: [tor-relays] Shirts

[Roger Dingledine]

On Thu, Aug 17, 2017 at 09:53:12AM +0200, Sebastian Urbach wrote:
> I was asked recently by friends & family if i could get the traditional Tor
> shirt for them. I showed them the new Tor shirt and well let's say they
> really want the traditional shirt.

Which one is new and which one is traditional? There have been like
eight Tor shirt designs by now. :)

I would suggest contacting tshirt@tp.o among the other steps you take.

--Roger

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

Re: [tor-relays] Fallback directory mirror DFRI7 is dead

[Roger Dingledine]

On Fri, Aug 25, 2017 at 11:43:10AM +1000, teor wrote:
> > A new DFRI7 will appear on the same address and port within a couple of
> > days. Should I simply update fallback_dirs.inc?
> 
> No need to do anything right away!

Will it be bad to have a new relay (with a new key), on the same IP:port
as what many clients think is an existing fallback relay?

I can imagine clients getting warnings in their logs, about how they're
getting an unexpected fingerprint while attempting to connect.

--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 making normal internet unusable

[Roger Dingledine]

On Wed, Aug 30, 2017 at 09:33:26AM +0930, W Howard wrote:
> I have some spare bandwidth and want to run an exit relay

Is this at your home? Careful running exit relays at your home -- there
is always some new cop who just started his job, doesn't understand the
Internet, has never heard of Tor, and wants to prove how great he is at
being a cop.

See also the "Should I run an exit relay from my home?" question on
https://www.torproject.org/eff/tor-legal-faq

You might want to run a non-exit relay in that situation instead.

> buy when I
>do the normal internet is so slow

The simple option is to turn on rate limiting so it uses a little bit
less than your full Internet connection.

The more complex option is:
https://gitweb.torproject.org/tor.git/tree/contrib/operator-tools/linux-tor-prio.sh
was once a script that some people used to set the priority lower
on their Tor traffic compared to the other traffic. You need to either
run it on the router, or run it on the computer that generates both the
Tor traffic and the other traffic.

> and I have to fill out so many captcha
>that it makes it unusable!
> 
> Any ideas why? I think google etc block by default tor exit nodes. 

Yes, correct. :( That's why many people who run exit relays use a separate
IP address for them.

See also
https://blog.torproject.org/blog/call-arms-helping-internet-services-accept-anonymous-users

> I was thinking about spinning up a vm and running tor on that.

Plausible!

> When I run as a bridge I don't see much traffic. Any ideas?

Many bridges don't see much traffic, especially compared to fast
relays. See also
https://www.torproject.org/docs/faq#RelayOrBridge

Thanks!
--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 making normal internet unusable

[Roger Dingledine]

On Wed, Aug 30, 2017 at 12:53:39PM +0930, W Howard wrote:
> Thanks for the information. I wanted to run a relay from home to
>support the project but I may instead contribute financially.

You could do both! :) That is, run a non-exit relay from home, and
also donate.

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

Non-exit relays are still quite useful, and with luck their bandwidth
will become even more needed in the next year or two once we figure out
what sort of cover traffic policies we want to deploy.

> One of the up sides of a tor exit relay is the false traffic
>generated. Our meta data is now collected and I like the idea of filling
>it with junk traffic.

I think this idea doesn't work as well as some people (including,
originally, me) hope it would.

For further reading, see also bullet point 2 on
https://blog.torproject.org/blog/trip-report-tor-trainings-dutch-and-belgian-police

Along these lines, I've also always liked the "As one commentator put
it" section on
https://www.schneier.com/blog/archives/2006/08/trackmenot_1.html

--Roger

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

Re: [tor-relays] DIR Port

[Roger Dingledine]

On Wed, Aug 30, 2017 at 01:39:34PM +0100, Dr Gerard Bulger wrote:
> DIR port on my relay and mini exit as being there on Atlas.
> 
> The DIR port is open, indeed the DirPortFrontPage can be seen.  
> 
> Bandwidth is ???fast???
> 
> The exit is very limited in scope to avoid abuse claims, so few ports 
> forwarded such as 443, but not 80. Is that the reason not showing?

Check out your logs as the relay starts. Look for a log message like

  log_notice(LD_DIR, "Not advertising Dir%s (Reason: %s)",
 dir_port ? "Port" : "ectory Service support", reason);

Common reasons include "AccountingMax enabled" and
"BandwidthRate under 50KB".

In general, it's fine for Tor to decide not to advertise your DirPort.
Everything else is still working fine. 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] ControlPort Authentication Options

[Roger Dingledine]

On Sun, Sep 03, 2017 at 01:17:14AM +0200, Ralph Seichter wrote:
> I also tried using a control socket instead of a control port, alas, the
> parameter RelaxDirModeCheck is rejected by Tor 0.3.0.10:
> 
>   [warn] Failed to parse/validate config: Unknown option
>   'RelaxDirModeCheck'. Failing.
>   [err] Reading config failed--see warnings above.
> 
> It is documented in https://www.torproject.org/docs/tor-manual.html.en

In the man page, it's listed as a flag to ControlPort. So I guess you
say something like "ControlPort unix:/path/to/socket RelaxDirModeCheck"

It looks like this feature went into Tor 0.2.8.2-alpha.

--Roger

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

Re: [tor-relays] Rate setting in tor

[Roger Dingledine]

On Fri, Sep 08, 2017 at 07:14:58AM +0200, Andreas Krey wrote:
> On Thu, 07 Sep 2017 22:56:17 +, r1610091651 wrote:
> > RelayBandwidthRate 2048 KBytes
> > RelayBandwidthBurst 2048 KBytes
> > 
> > But using arm, I'm seeing that tor is not honoring these settings, with
> > bursts frequently exceeding the value.
> 
> That's the point of the Burst - there is a bucket that is
> filled up with unused bandwidth, up to the Burst value,
> and before the relay throttles down to RB-Rate it also
> lets as many byte pass as the bucket currently has.
> 
> Means that with your setting your relay can pass up to
> 4 MByte in any given second (but not in every second).

No, with these values the relay will push up to 2MBytes in each direction
each second. When the Burst is the same as the Rate, it's essentially
just like you're using the Rate. It doesn't add them.

My guess is that the original poster is confused because they wrote
"KBytes" in their torrc, but arm defaults to bits.

--Roger

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

Re: [tor-relays] Fwd: Your TOR [sic] node

[Roger Dingledine]

On Fri, Sep 08, 2017 at 09:52:09PM -0400, Matt Traudt wrote:
> His intentions are now very suspicious to me too. I will definitely not
> be pointing anything at his servers.
> https://lists.torproject.org/pipermail/tor-relays/2017-August/012735.html

Yes, I agree.

I wonder if there's a way to scan the exit relays to find out if any of
them got suckered by this social engineering attack. Maybe based on the
DNS discovery infrastructure that Philipp Winter et al used?

--Roger

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

Re: [tor-relays] Would you also like to have family-level atlas pages?

[Roger Dingledine]

On Mon, Sep 11, 2017 at 10:10:00PM +, nusenu wrote:
> I suggested family-level pages where an operator of more than one relay
> can see all the relays of his family including aggregated (stacked)
> graphs for the graphs that are already available on a per-relay level.

Good idea.

The Nos Oignons folks had some scripts you can hack together to measure
and visualize your group of relays, but I spent a while hunting and I
couldn't find it now.

While we're doing feature requests, once the "per family" view exists,
I would want to use the same view on other groups of relays, like "per
country" and "per AS". I can fake some of that with Compass:
https://compass.torproject.org/
but it would be great to have it in a site that's maintained. :)

Thanks!
--Roger

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

Re: [tor-relays] Some Dir Authorities blocked

[Roger Dingledine]

On Sat, Sep 16, 2017 at 11:44:41PM +, dawuud wrote:
> > Your only option would be to ask your ISP to uncensor the internet,
> > unfortunately. Tor requires that all relays are able to contact all
> > other relays, and those which cannot participate in the network.
> 
> I think you meant to say:
> "Tor requires that all relays are able to contact all directory authorities"

Actually, no, we want it to be the case that all relays can reach all
relays. The less true that becomes -- that is, the less clique-like
the network topology becomes -- the more complicated the anonymity
measurements become, and that is potentially quite bad.

> Tor certainly does NOT require all relays can contact all relays.  In
> fact, the network is *very* partitioned... but as of the past few
> months I haven't put any energy into proving this; although I do have
> some mostly finished twisted python code to make all two hop tor
> circuits and records circuit build failures and circuit build timeouts.

This is a great research area that it would be good to see some
attention for.

In particular, if there are specific relays that are doing especially
poorly for connectivity, we should work with them to try to get them to
fix it, and if it's unfixable, downgrade their weights and/or boot them
from the network.

See also
https://trac.torproject.org/projects/tor/ticket/12131
("Measure connectivity patterns between relays")
and
https://trac.torproject.org/projects/tor/ticket/19068
("Write and run a clique reachability test")

--Roger

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

Re: [tor-relays] bad exit flag reason

[Roger Dingledine]

On Sat, Sep 23, 2017 at 10:32:00PM +, nusenu wrote:
> Hi,
> 
> [1] is not maintained since a long time.
> I'm curious what the reason for assigning the badexit flag to [2]
> was. If you know anything about it and can share something, that would
> be great.
> 
> [2] https://atlas.torproject.org/#search/flag:badexit
> 
> 37.221.171.234 75FCEA0BE7A2A472669352A1F0F2E59F99C6A3AA
> 37.221.171.237 128814837EC27F20D76EBDDB2CB3AB70258F0BA8

It was badexited in October 2015, with the reason "rewrite HTTP requests
to port 8123".

That's the polipo port, so I wonder if they were running some sort of
polipo + broken iptables setup.

There were a pile of exit relays around that address, all messing with
exit traffic on that port, and most of them have disappeared since then.

--Roger

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

Re: [tor-relays] Individual Operator Exit Probability Threshold

[Roger Dingledine]

On Fri, Sep 22, 2017 at 01:04:28PM +, John Ricketts wrote:
> I am about to fire up more Exit Relays  and if I do so I will jump from my 
> roughly 3% of Exit Probability to what technically could easily reach 6-8%.
> 
> I would like to know everyone???s opinion on having an individual operator 
> have that much exit share.  In my case, all the traffic would be coming from 
> the same AS as well, but distributed over four different cities with 
> different upstream carriers.

Hi John,

I think 5% exit share is fine, and 10% is probably a bit too high.

That means as you grow past 5%, you should work with the other big exit
relay operator groups -- torservers, Nos Oignons, DFRI, Frënn vun der
Ënn, Hart Voor Internetvrijheid, NoiseTor, and the many more out there --
to get them to pick up the pace on their side. :)

--Roger

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

Re: [tor-relays] MaxMemInQueues defends against 375000 circuits in 9 secs - not

[Roger Dingledine]

On Thu, Sep 28, 2017 at 11:12:05PM +0200, Felix wrote:
> Sep 26 18:59:37.000 [err]
> tor_assertion_failed_: Bug: src/common/buffers.c:651:
>   buf_flush_to_socket: Assertion *buf_flushlen <= buf->datalen failed;
>   aborting.

Neat! Can you open a ticket on https://bugs.torproject.org/ ?

With as many details as you can.

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 'alnsn' died

[Roger Dingledine]

On Fri, Oct 20, 2017 at 12:29:29AM +0100, Alexander Nasonov wrote:
> B9A41AD7AE8B2A4E6DE96EE77E3C8C04BADA8AC0 is currently down because
> harware died this morning. I will either reinstall it or move to
> a different AS. In any case, it won't happen tomorrow. I hope to
> have it up and running on the weekend.
> 
> Master key is safe because it's on a different machine.

Thanks for running one of the fast BSD relays!

And good luck getting it back up and running. :)

--Roger

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

Re: [tor-relays] "Removed 1565259696 bytes by killing 1 circuits"

[Roger Dingledine]

On Fri, Oct 20, 2017 at 07:27:22PM -0400, tor wrote:
> In a relay's logs:
> 
> Oct 20 10:31:47 X Tor[]: We're low on memory.  Killing circuits with 
> over-long queues. (This behavior is controlled by MaxMemInQueues.)
> Oct 20 10:32:11 X Tor[]: Removed 1565259696 bytes by killing 1 
> circuits; 40008 circuits remain alive. Also killed 0 non-linked directory 
> connections.
> 
> Tor removed ~ 1565 MB by killing 1 circuit? Seems like that can't be right?

Intriguing!

I would believe that it could be right.

This situation can happen if something (a client or relay or website or
etc) requests a whole lot of bytes, and then stops reading on that socket.

The earlier version of that attack, where in the original version it
could take down the relay rather than give you this strange log message,
is written about here:
https://www.freehaven.net/anonbib/#sniper14
and Rob kindly wrote a more readable explanation here:
https://blog.torproject.org/new-tor-denial-service-attacks-and-defenses

Rob and I have an in-progress draft proposal for "authenticated sendme
cells" which would make it harder to queue up so many bytes -- but it
would only make the attack more complicated, which is not the same as
impossible, so I haven't managed to get excited about deploying it.

--Roger

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

Re: [tor-relays] Tor t-shirts

[Roger Dingledine]

On Sat, Oct 21, 2017 at 12:28:34AM +0100, Dylan Issa wrote:
> To add on this, if my Tor relay was restarted for a reason (resets downtime) 
> but previously had ~50 days uptime, if I get the remaining 10 days am I 
> eligible? Or must it be at least 60 days of continuous uptime?
> Because I had 50 days, so if I need to wait another 2 months that???ll be 
> depressing

When I originally wrote the qualifying text, I definitely did not mean
to require an uptime of 60 days. I think my thought process was more
that if you have downtime in the 60 days, then your relay's throughput
needs to be proportionally higher to account for the time where your
speed is effectively 0. And I guess there is some unspecified threshold
where you have so much downtime in the 60 days that you can't really
argue that you were "running the relay for the past two months".

That said, the folks handling tshirt requests are the real arbiters
of how they are interpreting my sentences, so I will defer to them. :)

--Roger

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

Re: [tor-relays] Testing Golang relay implementation

[Roger Dingledine]

On Tue, Oct 24, 2017 at 10:54:38AM -0700, Michael McLoughlin wrote:
> Yes I am very aware of Tom van der Woerdt's previous work, and I am
> attempting to avoid some of the problems he faced. This implementation is
> pure Go, so I will not have cgo-based issues at least.

Great! Yes, I think the memory bloat was the main issue that stopped Tom.

Also, you should take a look at Alex's talk about his erlang Tor relay
implementation experiences, including lessons learned and why he became
less enthusiastic about maintaining a separate Tor relay implementation:
https://media.ccc.de/v/SHA2017-304-introducing_talla_an_erlang_implementation_of_tor

--Roger

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

Re: [tor-relays] Testing Golang relay implementation

[Roger Dingledine]

On Thu, Oct 26, 2017 at 02:56:03PM -0700, Michael McLoughlin wrote:
> After another look at the spec, I still believe the descriptor I'm
> publishing conforms, as was my intention. Sorry to have caused all these
> problems :(

No, don't apologize! It's great that there are people implementing
from our specs, and it's great when they find bugs with tools that
made bad assumptions and expectations. :)

--Roger

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

Re: [tor-relays] Exit probability

[Roger Dingledine]

On Sun, Oct 29, 2017 at 03:20:47PM +0100, Sebastian Urbach wrote:
> "Exit" -- A router is called an 'Exit' iff it allows exits to at least one
> /8 address space on each of ports 80 and 443. (Up until Tor version 0.3.2,
> the flag was assigned if relays exit to at least two of the ports 80, 443,
> and 6667.)

Right. And see also my future plans to make it just "80 and 443":
https://bugs.torproject.org/23637

> The Exit probability is 0 without the Exit flag. 200 Exit connections
> without the Exit flag ? Seems ylto be weird...

I don't think it's that weird. You can read more about the goals of the
Exit flag here:
https://trac.torproject.org/projects/tor/ticket/22820#comment:3

but the simple summary here is that the Exit flag, and thus the exit
probability, is about *load balancing*, so other clients can choose
their paths in a way that produces globally useful choices.

That is, think of an exit probability of 0% as saying "Other people
should assume that I am not using any of my bandwidth for exit streams,
so I am fully available for use in other circuit positions", not "there
is no chance that you can exit from my relay".

--Roger

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

Re: [tor-relays] "Fast" flag definition

[Roger Dingledine]

On Sun, Oct 29, 2017 at 04:21:10PM -0700, Igor Mitrofanov wrote:
> It looks like 94.7% of all Running relays have the "Fast" flag now. If
> that percentage becomes 100%, the flag will become meaningless.
> What were the reasons behind the current definition of "Fast", and are
> those still valid? If not, should "Fast" become self-adjusting
> ("faster than 2 Mbps or 70% of all Guard relays, whichever is
> greater")?

The goal of the Fast flag is to have some minimum threshold for whether
a relay is useful at all.

It actually is self-adjusting, in that it gets assigned to the top 7/8ths
of the relays. But *also* it gets assigned to any relay that meets some
minimum bandwidth threshold:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2408

The "give it to them anyway if they're above the threshold" is a security
defense, else some jerk could sign up a whole lot of crummy relays,
driving other legitimate relays out of the network, thus making Sybil
attacks more effective.

And the threshold is currently quite low -- 100KBytes/s.

(It's actually more complicated than that, because some directory
authorities assign it based on their own measurements ("I must be voting
a consensus weight of at least 100 for this relay"), and others assign
it based on the relay's self-reported number ("The relay must be claiming
at least 100KBytes/s of capacity").)

So think of Fast more as "worth using at all", where if you don't have
the flag, you don't have a chance of being chosen, and if you do, then
the consensus weights kick in to shift traffic towards bigger relays.

--Roger

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

Re: [tor-relays] UbuntuCore

[Roger Dingledine]

On Mon, Oct 30, 2017 at 03:23:07AM +, Paul Templeton wrote:
> These nodes are popping up everywhere - is this some sort of malware being 
> deployed on systems around the globe?

It is an Ubuntu snap package. See this thread:
https://lists.torproject.org/pipermail/tor-relays/2016-August/010046.html

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

[Roger Dingledine]

On Sun, Nov 05, 2017 at 03:16:42PM -0500, Kijani wrote:
> Does anyone have a script for periodically updating strick exit nodes lists 
> after running an inspection as per 
> https://tc.gtisc.gatech.edu/bss/2014/r/spoiled-onions-slides.pdf or similar? 
> Looking to help protect against crypto transaction sender redirect attacks.

Trying to maintain a list like this on your own is counterproductive
and potentially dangerous:

(A) If you have a private set of relays that you try to avoid, then
the resulting difference in path selection can act as a tracking cookie.
The more different you are from normal clients, the easier it is to
recognize you.

(B) If you discover relays that are modifying traffic, then you should
tell the bad-relays list, so they can kick them out of the network to
keep everybody safer:
https://blog.torproject.org/how-report-bad-relays
https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays

--Roger

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

Re: [tor-relays] do the 800+ UbuntuCore relays constitute a Sybil attack?

[Roger Dingledine]

On Tue, Nov 28, 2017 at 08:06:11PM -0500, starlight.201...@binnacle.cx wrote:
> The population of these has been climbing for more than a week and no-one has 
> commented, which seems odd.  No contact provided.
> 
> https://atlas.torproject.org/#search/UbuntuCore

See this thread:
https://lists.torproject.org/pipermail/tor-relays/2016-August/010046.html

So they are not a single unified operator.

What fraction of consensus weights are they? I'm under the impression
they're running on refrigerators or whatever so most of them have crappy
connectivity.

--Roger

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

Re: [tor-relays] Recent wave of abuse on Tor guards

[Roger Dingledine]

On Thu, Dec 21, 2017 at 10:11:47PM +0100, Felix wrote:
> It's currently good to be restrictive. May-be a *per ip* limit of 20
> (slow DoS) and a *per ip* rate of 1 per sec (fast DoS) is good.

I'm getting up to speed on this issue (been absent for some days).

My current thought is that these are actually Tor clients, not intentional
denial-of-service attacks, but there are millions of them so they are
producing surprises and damage. (Also, maybe there is not a human behind
each of the Tor clients, so maybe we shouldn't value them as much as we
would value more Tor Browser users.)

> I am on Freebsd

The Freebsd relays running Tor 0.3.2 will especially benefit from
today's 0.3.2.8-rc release, because bug 24671 only affects non-Linux or
ancient-Linux relays:

  o Minor bugfixes (scheduler, KIST):
- Use a sane write limit for KISTLite when writing onto a connection
  buffer instead of using INT_MAX and shoving as much as it can.
  Because the OOM handler cleans up circuit queues, we are better
  off at keeping them in that queue instead of the connection's
  buffer. Fixes bug 24671; bugfix on 0.3.2.1-alpha.

> > (Connection refused; CONNECTREFUSED; count 18; recommendation warn;
> > host DAC825BBF05D678ABDEA1C3086E8D99CF0BBF112 at 185.73.220.8:443)
> > 
> > So - I get loads of CONNECTREFUSED whilst coming up (presumably because
> > of the attack) and then come fully back online. 

> IMO your tor searches for guards and they are under load, gone or lost
> their guard flag. Finally you found a guard :)

Yes, I agree. (Though if they were gone or lost their guard flag, you
would not have tried them and gotten a CONNECTREFUSED. So I think they
are all suffering from the "under load" case. Gosh.)

--Roger

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

Re: [tor-relays] Recent wave of abuse on Tor guards

[Roger Dingledine]

> On Thu, Dec 21, 2017 at 10:11:47PM +0100, Felix wrote:
> My current thought is that these are actually Tor clients, not intentional
> denial-of-service attacks, but there are millions of them so they are
> producing surprises and damage. (Also, maybe there is not a human behind
> each of the Tor clients, so maybe we shouldn't value them as much as we
> would value more Tor Browser users.)

I've started the process of cranking down the extra circuits that new
clients make:
https://trac.torproject.org/24716

With luck, over the next day or so things will get better. We'll learn
something about the issue either way.

Keep an eye on your "Circuit handshake stats since last time"
notice-level log lines over the next day or two.

(This won't resolve the "way too many connections" issue though. One
step at a time. :)

--Roger

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