- tor-relays - lists.torproject.org

2017-06-07 15:37: 65 new tor exits in 30 minutes
by nusenu 08 Jun '17

08 Jun '17

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) - OS: Linux - run two instances per IP address (the number of relays is only odd because in one case they created 3 keys per IP) - ORPort: random - DirPort: disabled - Tor Version: 0.2.9.10 - ContactInfo: None - MyFamily: None - Joined the Tor network between 2017-06-07 15:37:32 and 2017-06-07 16:08:54 (UTC) - Exit Policy summary: {u'reject': [u'25', u'119', u'135-139', u'445', u'563', u'1214', u'4661-4666', u'6346-6429', u'6699', u'6881-6999']} - table is sorted by colmns 3,1,2 (in that order) - Group diversity: - 20 distinct autonomous systems - 18 distinct countries https://gist.githubusercontent.com/nusenu/81337aed747ea5c7dec57899b0e27e94/… Relay fingerprints are at the bottom of this file. This list of relays is NOT identical to the one from DocTor (even though the number is identical (65)): [1] https://lists.torproject.org/pipermail/tor-consensus-health/2017-June/00796… https://twitter.com/nusenu_/status/872536564647198720 -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 5

Mail delivery failed : returning message to sender
by 6465ec09＠opayq.com 08 Jun '17

08 Jun '17

This message was created automatically by mail delivery software at Junk Email Filter. The message from "lists.torproject.org [Masked]" <FWD-737QLY3MGNAYQYGGAHICDII6EY4CAKZCFW6DEJZFHAADYYFABL5ABZTBS4AFSQCOACGAA6IMFJSMAAZAJZAAAIA=(a)opayq.com> is being returned by server opayq-outbound.junkemailfilter.com on Wed, 07 Jun 2017 21:17:32 -0700 A message that you sent could not be delivered to all of its recipients. NOTE: And this is important - Junk Email Filter is a front end spam filtering service. We accept email for our customers, filter it, and pass the good email on. Sometimes when we forward email as good the server we forward to rejects it. Generally if you are getting this message it is because the server we forwarded to * NOT JUNK EMAIL FILTER * has rejected the message. If you see below the phrase "error from remote mail server" then it is the server who we are forwarding to, NOT US who is rejecting the email. Read the reason carefully and see if you can correct the cause of the rejection. The following address(es) failed: m.terlinde(a)gmx.de host mx01.emig.gmx.net [212.227.17.5] SMTP error from remote mail server after HELO opayq-out-00.junkemailfilter.com opayq-outbound.ctyme.com: 500 Syntax error, command unrecognized

1 0

libzstd and/or liblzma
by Felix 07 Jun '17

07 Jun '17

>> Can somebody please help me understand the change log for >> 3.1.x: "Support for these algorithms requires that tor is >> built with the libzstd and/or >> liblzma libraries available." Is it AND or OR or something whatever >> different ? > > > Hi! Let me try to clear it up: > > If Tor is built with liblzma available, it will use liblzma when > appropriate. The lzma format is expensive to calculate, but it > provides very good compression, so we only use it for cases when we > can compress something once and server it many many times -- like > consensus documents, or consensus diffs. > > If Tor is built with libzstd available, it will use libzstd when > appropriate. The zstd format is cheap to calculate, but appears to > provide better compression than zlib on our data. > > If Tor is built with both libraries available, it will use either one > when appropriate. > > Of course, we can only use these compression formats when both sides > support them. Thanks. Clear to me. So 'Liblzma N/A' should not be an issue. -- Cheers Felix

1 0

libzstd and/or liblzma
by Felix 07 Jun '17

07 Jun '17

Hi everybody Can somebody please help me understand the change log for 3.1.x: "Support for these algorithms requires that tor is built with the libzstd and/or liblzma libraries available." Is it AND or OR or something whatever different ? Might ports archivers/zstd only do the job (OR-type): Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 -- (And why says the notice message "OpenSSL LibreSSL" ?) Cheers, Felix

3 2

Ahiker shutting down
by Ian Zimmerman 05 Jun '17

05 Jun '17

Hello, sadly I have to terminate my relay because it seems to interfere with the quotidian use of my server. I'll look for a way to help the community in other ways. -- 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

2 1

Only 3 bw auths available
by Felix 03 Jun '17

03 Jun '17

Uhh. Wasn't there a transition to use self reported bw below some threshold number ? -- Cheers, Felix

2 1

Who is running the two biggest Exits in the network?
by Paul 01 Jun '17

01 Jun '17

Since about mid April there are just two similar Exits making up now about 4.5% exit probability together. Located in Panama, run in the okservers.net network, AS395978 ,they don’t give up any further information about themselves. Personally I would feel better at least having a contact or even better, knowing who is giving that much effort. Probably a MyFamily configuration should be placed as well? https://atlas.torproject.org/#details/29C92C854E0F6652A77F3A8B231D693299396… https://atlas.torproject.org/#details/2CA4B2F36C2DDECFCB0B5A0D3300ED30E68E2… Paul

6 10

Questions about OfflineMasterKey
by Cristian Consonni 01 Jun '17

01 Jun '17

Hi, On 18/05/2017 10:45, nusenu wrote:>> Currently, my server hosting kitten1 and kitten2 (tor guard and fallback >> directory) is under seizure since 14/05 11h. butplease 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 end 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). This feature is interesting and I did not know about it. However, I have been reading the documentation page[1] and I have the impression that the more I read the less I understand how it works. If I look inside the DataDir of one of my relays - a standard Debian install - see this: ``` ed25519_master_id_public_key ed25519_master_id_secret_key ed25519_signing_cert ed25519_signing_secret_key secret_id_key secret_onion_key secret_onion_key_ntor secret_onion_key_ntor.old secret_onion_key.old ``` So, here some of the things I think I have understood: * Tor uses a ed25519 key to generate the other keys need to decrypt incoming traffic and route it to its next destination on the network. I don't know how this works in practice, but probably it is too much detail at the moment. * In the standard install the master key is the `ed25519_master_id_secret_key` above, which has no passphrase. * If in `torrc` we declare `OfflineMasterKey 1` then the `ed25519_master_id_secret_key` will not reside anymore on the relay but on a separate machine. * In the process of generating the master key (with the command `tor --keygen`, all the files above will be generated. * To run the node with `OfflineMasterKey 1` you need to copy all the files generated in the previous step *with the exception of the master key*. I had also a few questions: * is the above correct? * if I use the offline master key protected with a passphrase will I need to input the passphrase every time I restart Tor (I have in mind what Apache does when you restart it and have certificates protected with a passphrase)? * Assuming that I am going to use a separate machine to generate the master key I need to make sure that the version of Tor on the machine that I use to generate the key and the relay? Thanks for your help. Cristian [1]: https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity/OfflineK…

3 5

Encrypting the DataDir
by Cristian Consonni 31 May '17

31 May '17

On 15/05/2017 12:21, aeris wrote: > Private key are under encrypted volume and may be protected On 21/05/2017 10:02, Roger Dingledine wrote: > On Sun, May 21, 2017 at 09:12:39AM +0200, Petrusko wrote: >> @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-belgia… >From the Tor Exit Guidelines: «Disk encryption might be useful to protect your node keys, but on the other hand unencrypted machines are easier to "audit" if required. We feel it's best to be able to easily show that you do Tor exiting, and nothing else (on that IP or server).» https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines I was wondering if the argument about not encrypting the disk applies just to the full-disk encryption or if it is applicable also to the caso of encrypting just the DataDir on a fairly small file-based volume (say 100MB). In the second case, how big can the DataDir get? Cristian

5 6

reminder: tor 0.3.1.1-alpha is _not_ recommended (known bug)
by nusenu 31 May '17

31 May '17

Since there were only 8 relays running 0.3.1.1-alpha I didn't bother to state this here, but since the number is rising since yesterday I just wanted to remind you that tor 0.3.1.1-alpha contains a bug that makes this not a good version to use. In the worst case (unlikely) you would publish a limited amount of memory via your relay descriptor https://trac.torproject.org/projects/tor/ticket/22368#comment:7 https://trac.torproject.org/projects/tor/ticket/22378 Relays currently using tor 0.3.1.1-alpha (excluding Roger's): +------------------+------------------------------------------+ | nickname | contact | +------------------+------------------------------------------+ | Quincy | NULL | | ss666 | NULL | | sorryitsslow | NULL | | artiX | NULL | | ELECTRICSHEEP | NULL | | dahool | NULL | | BabylonNetwork01 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork03 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork00 | Babylon Network | noc <AT> babylon <DOT> | | BabylonNetwork02 | Babylon Network | noc <AT> babylon <DOT> | | Gentoo | gentoo.intel(a)gmail.com | | 0x000000000 | https://ban.ai | | HeirloomReaper | James Taylor <tor AT fornoreason dot net | | ireadconf | torrelay(a)fh-biergarten.de - 1QCHdyhPHLrK | +------------------+------------------------------------------+ If you are eager to run alpha level tor versions to uncover and report bugs early that is great but you might want to wait for tor 0.3.1.2-alpha or run master builds after https://gitweb.torproject.org/tor.git/commit/?id=ab9976b7245f05a97e0285265c… https://deb.torproject.org/torproject.org/dists/tor-nightly-master-stretch stay safe, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 3