Re: [tor-relays] Testers needed for Nyx beta release

[Lucas Werkmeister]

Hi! I just tried it out on a fairly plain Debian Stretch server, no
problems.

One comment: shouldn’t the description of the DEBUG log level (in the
“event types” dialog) point out the privacy implications of logging at
that level? I only ask because usually when I see that log level
mentioned (e. g. in the context of a bug report where the developers ask
the relay operator for more information), it’s accompanied by a
disclaimer that you should not log at DEBUG level by default because the
output might include sensitive information.


On 30.10.2017 20:35, Damian Johnson wrote:
> Hi all! After five years Nyx (previously known as arm) is getting
> a far belated update. Under the covers the whole codebase has been
> rewritten from scratch, but for users things look much the same.
> One of those cases where...
>
>   "When you do things right, people won't be sure you've done
>   anything at all." -Futurama
>
> Main changes are...
>
>   * Python 3.x support.
>
>   * New website: https://nyx.torproject.org/
>
>   * Bandwidth graph now prepopulates when you start up, so you
> have a graph right away.
>
>   * Connections are now available without togging
> DisableDebuggerAttachment in your torrc.
>
>   * Support for showing IPv6 connections.
>
>   * Dialog for picking tor events to log, rather than an arcane
> letter flag input.
>
>   * Improved efficiency of log deduplication by multiple orders
> of magnitude. As such verbose logs no longer peg your CPU.
>
>   * Richer control interpreter, including a python prompt like
> IDLE.
>
>   * Removed features that frequently confused users such as the
> relay setup wizard and torrc validation.
>
>   * Modernized dependencies. Nyx now uses Stem rather than TorCtl
> (which was deprecated in 2011).
>
> Our ducks should finally be in a row for release, but this being
> a full rewrite I'd like to start with an open beta to work out
> anything I might have missed.
>
> Would relay operators mind giving Nyx a whirl? To give it a try
> simply ensure you have a control port available in your torrc...
>
>   ControlPort 9051
>   CookieAuthentication 1
>
> ... and run the following...
>
>   % git clone https://git.torproject.org/stem.git
>   % git clone https://git.torproject.org/nyx.git
>   % cd nyx/
>   % ln -s ../stem/stem stem
>   % ./run_nyx
>
> Thanks! -Damian
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



smime.p7s
Description: S/MIME Cryptographic Signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Revert back to a stable build of Tor from an alpha

[Lucas Werkmeister]

On 12.10.2017 11:57, nusenu wrote:
>
> nusenu:
>> Jacki M:
>>> How do I revert back to a stable build of Tor from an alpha? Im running Tor 
>>> 0.3.2.2-alpha and need to revert back to Tor 0.3.1.7.
>>> Im running Ubuntu 16.04.3 LTS.
>> this should be easy:
>>
>> apt remove tor
>> adjust sources.list to point to the stable repository (remove the
>> experimental repo)
> +
> apt update
>> apt install tor

You probably want to back up your torrc too, I’m not sure if that’s kept
when the package is removed.


___
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

[Lucas Werkmeister]

On 06.08.2017 00:33, Ralph Seichter wrote:
> On 06.08.17 00:08, Chad MILLER wrote:
>
>> Careful. 0.3.0.1 > 0.2.9.14orsomething, but the former is probably
>> too buggy.
> I fail to see how that relates to my earlier message. When a new Tor
> production version is released, it is by definition recommended, or it
> would not be a production release in the first place. If later it turns
> out that a particular Tor version is buggy, in can be manually removed
> from the list of recommended versions.
>
> -Ralph
I’m not sure if “production version/release” is a term formally defined
for Tor releases, but 0.3.0.1 was at least not a “stable” release: the
announcement of Tor 0.3.0.6 [1] declares it “the first stable release of
the Tor 0.3.0 series”. And indeed, on the consensus health page [2], I
can see that several directory authorities don’t recommend any Tor
versions between 0.2.9.* and 0.3.0.7 (0.3.0.6 had a “medium-severity
security bug” [3], I assume that’s why it’s not recommended either).

Cheers,
Lucas

[1]:
https://lists.torproject.org/pipermail/tor-announce/2017-April/000128.html
[2]: https://consensus-health.torproject.org/
[3]:
https://lists.torproject.org/pipermail/tor-announce/2017-May/000129.html


smime.p7s
Description: S/MIME Cryptographic Signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Recommendation for DUMB COMPUTING devices for Tor Relays

[Lucas Werkmeister]

Regardless of whether the Pi’s firmware can actually be updated or not –
it’s probably not good for diversity to run the whole Tor network on a
single kind of device: we don’t want every relay in the network to be
compromised when a single flaw on the Pi is found. Performance might
also suffer, though I hear it’s gotten better with the Pi 3.

For stateless x86 hardware, this paper is very interesting: Joanna
Rutkowska, State considered harmful – A proposal for a stateless laptop.
http://blog.invisiblethings.org/papers/2015/state_harmful.pdf


On 21.10.2016 14:24, Petrusko wrote:
> I can confirm "rpi-update" usually works fine to update firmware.
>
> But don't forget to run this command sometimes by hand, no auto-update
> during the system /apt-get upgrade/
>
>> firmware of RPi can be changed: https://github.com/Hexxeh/rpi-update /
>> https://github.com/Hexxeh/rpi-firmware
>>
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



smime.p7s
Description: S/MIME Cryptographic Signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] HALP!

[Lucas Werkmeister]

This seems to be only the content of the keys/ subdirectory… my relay
also has some other files in /var/lib/tor/, most significantly (it would
seem) a fingerprint file. Did you copy these other files as well, and
they’re just not included in the screenshot?


On 24.08.2016 00:48, Markus Koch wrote:
> Okay, I should have said that this is my backup server ... so ...
>
> old tor exit -> backup server -> new VPS
>
> its running on the new VPS with the right permissions :)
>
>
> 2016-08-24 0:44 GMT+02:00 Michael Armbruster :
>> On 2016-08-24 at 00:41, Markus Koch wrote:
>>> Okay :(
>>>
>>> http://i.imgur.com/r1ZxAAH.png Is there anything important missing?
>> Well, it looks like wrong permissions to me. The files and the directory
>> is owned by your current user "bunny". Is this also the tor user, or is
>> tor using the user "tor" (which should be the default)?
>>
>> Currently, no other user but "bunny" can read from or write to those
>> files and it's the only user that can look into the current directory.
>>
>> Best,
>> Michael
>>
>>
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




smime.p7s
Description: S/MIME Cryptographic Signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Web server and TOR bridge at same IP:port

[Lucas Werkmeister]

Something like this exists: sslh[1], a "protocol demultiplexer".
However, it doesn't explicitly support Tor, and I'm not sure if it's
possible to distinguish between Tor packets and other TLS traffic using
the options it offers[2].

[1]: http://www.rutschle.net/tech/sslh.shtml
[2]: https://github.com/yrutschle/sslh/blob/v1.18/example.cfg#L37-L47


On 16.08.2016 19:50, Green Dream wrote:
> I don't think you will be able to bind two daemons to the same TCP
> port (443). 
>
> Maybe you could have something else listening on TCP port 443 and
> passing the requests onto both places?
>
> You might be able to put a single reverse proxy in front on that port,
> and have that proxy send the requests to the correct daemon on the
> backend, but I have no idea how to actually set that up. Most common
> reverse proxy software (like nginx) isn't designed to understand or
> handle Tor or pluggable transports like obfs4.
>
> There may be some application aware ("layer 4") firewalls that could
> do something like this too, but I don't think it would be
> straightforward. Also I'm not sure inspecting Tor packets (in order to
> determine they're Tor packets) is a good idea... or if that could even
> work since the packets will be obfuscated.
>
> Just thinking out loud... but this seems like a difficult to implement
> idea.
>
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



smime.p7s
Description: S/MIME Cryptographic Signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Relay isn't getting HSDir flags

[Lucas Werkmeister]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi all!

For some reason, my relay[1] isn't getting the HSDir and V2Dir flags.
This is the full config, sans comments (sed '/^#\|^$/d' /etc/tor/torrc):

SocksPort 0
DataDirectory /var/lib/tor
ORPort 9001
Address 78.46.139.153
Nickname BotIfMuvasfo
AccountingMax 7900 GB
AccountingStart month 15 00:00
ContactInfo Lucas Werkmeister "6B89 5B8B 11A4 75B1 EC93  1698 FC46 2872
72AE 323F" <m...@lucaswerkmeister.de>
DirPort 9030 # what port to advertise for directory connections
ExitPolicy reject *:* # no exits allowed

I reloaded the config several times since I uncommented the DirPort
line, and even restarted the relay earlier today just in case enabling
DirPort wasn't supported without restart. No luck - both Globe[1] and
Atlas[2] don't show the HSDir or V2Dir flags.

A few months ago, I had the relay running on a different server. I had
enabled the DirPort there for a while, but eventually was forced to
disable it since the server couldn't handle the load. But back then, the
relay got the flags without any problem. Since I moved to a new server
(copying over the torrc and data directories), this doesn't seem to be
working anymore. (I am now on Debian 8, tor version 0.2.5.12; the old
server was on Debian 7, tor version 0.2.4.27.)

Any ideas on what the problem here could be?

Thanks a lot,
Lucas

[1]:
https://globe.torproject.org/#/relay/C527AD7D47E9DEC163537A444F4F790433CD67F7
[2]:
https://atlas.torproject.org/#details/C527AD7D47E9DEC163537A444F4F790433CD67F7
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWbfIFAAoJEPxGKHJyrjI/B3AP/18uMBavSAQeHyYDr5D89bBQ
JlTmDwWdolNc7SwNeaUTB8w+KYEatyVXJh7uAF4jrjKIS9eplMMU+1rcLS6C2tO4
4hvu9cYGwXepkuh742ikPIXivj7X08BqP+c38GYyXIC/mxdUJ44AZwGa3z4guWEl
6Qb9FtdxJ2NBMdtHjvmyFTUN2qYK0k6qYzoHygCyrf/OyoHjynkMRPKwaoHEgZhG
yBIcf8AlOnKUf5+cVwkUZeurZ0l0KPl0hawUNDELciOMkGchMDyb6ui6u7LbCDVL
gRiBToU6RJIiPo6vKw7UbAZeNeodNeXalmLMTL7vuKzhJjYgDae1bTJEQvMWdz6i
nNxssOLHhBkTwdJosj1Kaw4a+opcqA8bPJY0KeAaZUnvAGro/lOwb0Tc7oDkbg2b
Xb5IuQfWpZzpOuGldfisdqXRL1rySsnCaGSsFT9ulrkXaz42UDQE8pyxy8ErqL4j
byhGiQF0F04sWldQPy3AjfZEImtBROx9PetESMLLyD6UYWffEGr6JLtIoolPEA0x
OjMOGuyq91gJEZ2xIdlN+kJaylmnu/8kGKD6vAJwBxX8wVHWIyD5KbQOyL2RjCT8
gtiSFdIj8mZmvKUR5svWrgxfGoVGc5a76CUyLF+7Jd+d3DPPOlGXX+dJ/WErjgjH
JbmjWbI1OIBai6gKvlSE
=BmwK
-END PGP SIGNATURE-


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