Re: [tor-relays] Bridge not being used

[tor]

Here's a recent thread with a good answer: 
https://www.mail-archive.com/tor-relays@lists.torproject.org/msg10829.html

The consensus seems to be, since bridges are allocated to users randomly, they 
may not see much traffic in some cases.

There's some guidance here: 
https://www.torproject.org/docs/faq.html.en#RelayOrBridge. I think this 
question is raised fairly often, and it might be good to add some additional 
info to the FAQ.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Bridge not being used

[Joel Cretan]

Hi relay operators,

I've run a number of relays, so I'm familiar with how this usually works
for non-bridges.

I'm working on a project that might want to connect through a bridge, so I
thought I'd fire one of those up to offset the demands I'd be placing on
the network.

I've been operating this bridge for about 30 days with RelayBandwidthRate
set at 5000 KBytes, which I thought might be attractive to some clients,
since most bridges are so small. But checking my logs for the last few
days, I don't seem to have had any clients at all recently. Is this
expected for a bridge, as clients don't rotate their bridge very often, or
is something possibly wrong? As far as I can tell, everything is working
OK, because I can connect through it with my own Tor client. The server
descriptor is published.

I'll avoid pasting the whole torrc since it's a bridge, but I can do that
with some parts removed if that would help.

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

Re: [tor-relays] Upgrading a relay and changing IP address

[teor]

> On 18 May 2017, at 21:15, Cristian Consonni  wrote:
> 
> One thing that will change with a fresh install is the IP address of the
> nodes. So, I was wondering, in general is a good thing to keep the same
> IP or changing it? Because in any case, I could try and do a
> dist-upgrade[2] so that I keep the old IP. I have also discovered now
> that DigitalOcean, one of the providers I use, provides a
> kernel-management interface[3] that could make the process easier.
> 
> So, which is preferable between the two processes where one has the
> advantage of keeping the same IP (dist-upgrade) and the other not (fresh
> install)?

It doesn't matter: if your IP address changes, the directory
authorities will take an hour or so to check your relay's reachability,
and then it will get back its flags and weight over the next week or
so.

If your relay is a fallback directory mirror[0], please keep the same key,
IP address, and ports. You can check that here[1] or here[2] (large page).


[0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
[1]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc
[2]: https://consensus-health.torproject.org/consensus-health.html

T
--
Tim Wilson-Brown (teor)

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




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

Re: [tor-relays] DirCache 0

[teor]

> On 18 May 2017, at 21:45, Paul  wrote:
> 
> Running a relay on small RAM I putted "DirCache 0" to save memory.
> 
> As one can read here https://www.torproject.org/docs/tor-manual.html.en 
> "Setting either DirPort or BridgeRelay and setting DirCache to 0 is not 
> supported. (Default: 1) " I cant set a DirPort as well, which means I cant 
> publish a DirPortFrontPage Exit-notice.
> 
> Any idea how to circumvent this problem.

Serve the web page using a minimal http server instead?

If there is no DirPort, there is no way for Tor to serve anything
over HTTP.

If there is a DirPort (or DirCache), you will have Tor clients
contacting you for directory documents, which (based on your tor-bsd
mails) you don't want on a tor relay with constrained RAM.

T
--
Tim Wilson-Brown (teor)

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




signature.asc
Description: Message signed with OpenPGP
___
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 - off topic

[Ian Zimmerman]

On 2017-05-18 20:56, Felix wrote:

> Indeed it's not broken, it's *Usenet Signature Convention*
> https://tools.ietf.org/rfc/rfc3676.txt (chapter 4.3.)
> 
> That's old school - how we saved bandwidth in ancient times :)

Not only that, it helps when you _want_ part of your article to be
invisible until explicit reader action.  Examples include story
"spoilers" (books, movies, plays, sports games), puzzles, learning
exercises etc.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html
___
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)

[nusenu]

>> I don't know any context or background but if you fear this could happen
>> to you again, I recommend to use tor's OfflineMasterKey feature (without
>> copying the master key to the server) with a short keylifetime (i.e. 7
>> days), especially if it is a fallback dir
>> (which requires a tor source code change to remove it).
> 
> Thanks for this feature, I don't know it !

If you want to use it you likely want to automate that especially with a
keylifetime of < 30days
because copying around files manually every week is no fun.
ansible-relayor does that out of the box for you ;)
https://github.com/nusenu/ansible-relayor

>> Could you also confirm the relay fingerprints (in addition to the
>> nicknames)?
> 
> kitten1 86E78DD3720C78DA8673182EF96C54B162CD660C
> kitten2 2EBD117806EE43C3CC885A8F1E4DC60F207E7D3E

thanks for the fingerprints.

Did you shutdown kitten3/4 (yoda.imirhil.fr)
3F5D8A879C58961BB45A3D26AC41B543B40236D6
6FB38EB22E57EF7ED5EF00238F6A48E553735D88

yourself? (last seen Monday 2017-05-15 11:00) or did Online SAS cancel
this second VPS after the first one got seized?

thanks,
nusenu

-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



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

[tor-relays] Strange behaviour Tor 0.2.9.10 - off topic

[Felix]

Hi everybody

I walked through the March postings and found:

> (Please don't put -- in your emails. Some people use broken
> mail readers that hide everything below a -- .)

Indeed it's not broken, it's *Usenet Signature Convention*
https://tools.ietf.org/rfc/rfc3676.txt (chapter 4.3.)

That's old school - how we saved bandwidth in ancient times :)

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

[tor-relays] TROVE-2017-002: deb.torproject.org 0.3.0.x repos no longer updated? - help yourself

[Felix]

Hi

If you suffer from:
(and https://www.freshports.org/security/tor/ is still on 3.0.6)

> To help the 1.3% cw-fraction / 87 FreeBSD relays I filed
> a ticket here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219364

and you are on FreeBSD source you upgrade to 3.0.6 and then put a small 
hack in place:


Go to ports security/tor and edit the 3.0.6 distinfo to:
SHA256 (tor-0.3.0.7.tar.gz) = 
9640c4448ef3cad7237c68ed6984e705db8fb2b9d6bb74c8815d01bb06527d02

SIZE (tor-0.3.0.7.tar.gz) = 5779422

Change the 3.0.6 Makefile to:
PORTVERSION=0.3.0.7

Copy tor-0.3.0.7.tar.gz from https://dist.torproject.org/ to 
/var/ports/distfiles/


# cd /usr/ports/security/tor && make deinstall clean
# cd /usr/ports/security/tor && make install

And voila 3.0.7 shows up. Works as well for jails 
(/usr/jails/myjail/var/ports/distfiles/).


If you come from some older versions please check ports/UPDATING, 
libevent is 2.1.8 now.


--
Cheers, Felix
___
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

[Geoff Down]

On Mon, May 15, 2017, at 10:20 AM, Roger Dingledine wrote:
> 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
First run client only: some old bad relays and all GB exits are
excluded.
May 18 09:50:56.000 [notice] Tor 0.3.0.7 (git-cfd9c1bdc0582656) opening
new log file.
May 18 09:50:56.507 [warn] You have asked to exclude certain relays from
all positions in your circuits. Expect hidden services and other Tor
features to be broken in unpredictable ways.
...
May 18 10:11:16.000 [notice] Tor has successfully opened a circuit.
Looks like client functionality is working.
May 18 10:11:16.000 [notice] Bootstrapped 100%: Done
May 18 15:45:50.000 [notice] Your system clock just jumped 19950 seconds
forward; assuming established circuits no longer work.
May 18 15:46:15.000 [notice] Tor has successfully opened a circuit.
Looks like client functionality is working.

-- 
http://www.fastmail.com - Access your email from home and the web

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

Re: [tor-relays] Upgrading a relay and changing IP address

[Ian Zimmerman]

On 2017-05-18 14:09, Sebastian Niehaus wrote:

> It should be possible to upgrade to Jessie from the template. At least
> that is what I did on my maschine hosted as a VPS.

Yes.  Running on a shared Linode, I am free to do practically anything
to the Debian OS installed, except updating the kernel.

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Upgrading a relay and changing IP address

[Sebastian Niehaus]

2017-05-18 13:15 GMT+02:00 Cristian Consonni :
>
> I am running the relays on VPS providers so, I can choose (only) among
> the versions of Debian that are provided by the services as templates.
>
>
It should be possible to upgrade to Jessie from the template. At least that
is what I did on my maschine hosted as a VPS.



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

[tor-relays] Upgrading a relay and changing IP address

[Cristian Consonni]

Hi,

On 18/05/2017 01:56, Gunnar Wolf wrote:
> Cristian Consonni dijo [Wed, May 17, 2017 at 05:04:29PM +0200]:
>> 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?
>> * Should I update Debian on the server? (which could well me start with
>> a fresh install?
>> * Is it ok like it is now, provided that the system is updated?
>
> While Debian Wheezy (7, our "oldstable" release) still has security
> support via LTS¹, it is not recommended to run a Tor relay with such
> old packages. In fact, not even the version available in Jessie (8,
> our "stable" release - 0.2.5.12-4) is recommended nowadays.
>
> I suggest you to update to _at least_ Jessie and use the version in
> backports (depends on your sysadmining, but if your machine's only use
> is to run a Tor node, I'd suggest installing Stretch, 9, which has
> 0.2.9.9-1).

I am running the relays on VPS providers so, I can choose (only) among
the versions of Debian that are provided by the services as templates.
When Stretch is release I will see if they make it available, in a
reasonable time.

I am settled anyhow to upgrade the nodes as soon as the new Debian
version is released and I have a question. I have read that I can move
the node keys when upgrading[1] and I will do that.

One thing that will change with a fresh install is the IP address of the
nodes. So, I was wondering, in general is a good thing to keep the same
IP or changing it? Because in any case, I could try and do a
dist-upgrade[2] so that I keep the old IP. I have also discovered now
that DigitalOcean, one of the providers I use, provides a
kernel-management interface[3] that could make the process easier.

So, which is preferable between the two processes where one has the
advantage of keeping the same IP (dist-upgrade) and the other not (fresh
install)?

Of course, I am assuming that I will be able to complete any of the two
processes successfully.

Cristian

[1]: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove
[2]: https://www.debian.org/releases/stable/amd64/release-notes/
[3]:
https://www.digitalocean.com/community/tutorials/how-to-update-a-digitalocean-server-s-kernel
___
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)

[Aeris]

> I don't know any context or background but if you fear this could happen
> to you again, I recommend to use tor's OfflineMasterKey feature (without
> copying the master key to the server) with a short keylifetime (i.e. 7
> days), especially if it is a fallback dir
> (which requires a tor source code change to remove it).

Thanks for this feature, I don't know it !

> Could you also confirm the relay fingerprints (in addition to the
> nicknames)?

kitten1 86E78DD3720C78DA8673182EF96C54B162CD660C
kitten2 2EBD117806EE43C3CC885A8F1E4DC60F207E7D3E

Regards,
-- 
Aeris
Individual crypto-terrorist group self-radicalized on the digital Internet
https://imirhil.fr/

Protect your privacy, encrypt your communications
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

signature.asc
Description: This is a digitally signed message part.
___
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)

[nusenu]

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

I don't know any context or background but if you fear this could happen
to you again, I recommend to use tor's OfflineMasterKey feature (without
copying the master key to the server) with a short keylifetime (i.e. 7
days), especially if it is a fallback dir
(which requires a tor source code change to remove it).

Could you also confirm the relay fingerprints (in addition to the
nicknames)?

thanks,
nusenu

-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



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

[tor-relays] TROVE-2017-002: deb.torproject.org 0.3.0.x repos no longer updated?

[nusenu]

Roger Dingledine:
> 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.  

As of 2017-05-18 6:00 UTC, about ~14% of the tor network (cw fraction)
runs a vulnerable tor version [1].

~12.3% (cw fraction) of them run Linux (~5% likely use the outdated
repos from deb.torproject.org).
I guess the most efficient method to help tor
relay operators (and the tor network as a whole), is to update the
packages in the affected deb.torproject.org repositories [2].

Is there a particular reason why the tor 0.3.0.x packages at
deb.torproject.org [2] have not been updated since v0.3.0.5-rc?
(they used to get updates within days after a release)

I hope they are not forced to switch to tor-nightly-0.3.0.x-* repos [3]
if they want to get that security fix.
Or is it: "Don't use the experimental repos if you want security updates"?

> packages
> should be available over the next several days.

Is this actually the case or is this just the usual wording from the
default release email and not actually happening in the case? (due to
long term support release 0.2.9.x?)

To help the 1.3% cw-fraction / 87 FreeBSD relays I filed a ticket here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219364
(tickets filed at trac.tpo about deb.tpo get closed as invalid, so I
stopped doing that [4])

thanks,
nusenu

[1]
https://nusenu.github.io/OrNetStats/#tor-version-distribution-relays
https://nusenu.github.io/OrNetStats/torversions

[2]
https://deb.torproject.org/torproject.org/dists/
[DIR] tor-experimental-0.3.0.x-jessie/  2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-precise/ 2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-sid/ 2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-stretch/ 2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-trusty/  2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-wheezy/  2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-xenial/  2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-yakkety/ 2017-05-12 11:28-
[DIR] tor-experimental-0.3.0.x-zesty/   2017-05-12 11:28-

[3]
[DIR] tor-nightly-0.3.0.x-stretch/  2017-05-16 13:43-
[DIR] tor-nightly-0.3.0.x-trusty/   2017-05-16 13:43-
[DIR] tor-nightly-0.3.0.x-wheezy/   2017-05-16 13:43-
[DIR] tor-nightly-0.3.0.x-xenial/   2017-05-16 13:43-
[DIR] tor-nightly-0.3.0.x-yakkety/  2017-05-16 13:43-
[DIR] tor-nightly-0.3.0.x-zesty/2017-05-16 13:43-

[4]
https://trac.torproject.org/projects/tor/ticket/22113

-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_




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