- tor-relays - lists.torproject.org

*.old files in ./keys are too new
by Toralf Förster 19 Jul '17

19 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do wonder, why the *.old files are newer than their counterparts: - -rw------- 1 tor tor 887 Jul 15 21:51 secret_onion_key - -rw------- 1 tor tor 96 Jul 15 21:51 secret_onion_key_ntor - -rw------- 1 tor tor 96 Jun 17 21:30 secret_onion_key_ntor.old - -rw------- 1 tor tor 887 Jun 17 21:30 secret_onion_key.old - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWW+pNRccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTsBLAP91Hst68PmoK3y6e5v3xBrKqNjD CW0a9Qn6vDj7O0EsFQD8DmPvK2xgIO6N4G2vsR+Beb5Py+CZoX93PtPBz/xVxNM= =nECn -----END PGP SIGNATURE-----

4 3

Strange log in a middle relay "Gateway Time-out"
by Petrusko 18 Jul '17

18 Jul '17

Hey! Got a strange log from outer space, on a middle relay... :s [log] Jul 17 04:31:24.000 [warn] Received http status code 504 ("Gateway Time-out") from server '154.35.175.225:80' while fetching "/tor/server/d/679188844BFECBF0491F10692096A90C13C1EDD8+6A5F00758269A51C369C46480B82FD43F70A438+6D27FA6BC18185DFAFBABF72161BC9B5B851AE8F+6E4E9C532DF6B0B0A90A7259E77E963B4241F2D3+6E91C50C8222867DEE1638656CFC463A6A3B8A37+6E9421537D55BD56CC2A268B8478CBD1415ADE6+6F4D319593BFB0C06B14EB61478AF5BFCD8B442E+70B0CF367CF467C9562FC3A0C83EA3DA84659CDB+70ED5E2B880DB1A7C7F234AC28A1A78A9E40EA10+7133723103B5A9F9D77241A5F803C294A4B67185+71652BA723790D0C5000FEFC845D52A26C9BADC+7260088E17EA292064FBAD874BC0423C8AB925FB+74A5A26A2B41A347DE302DB9EF62AD018D6787FA+74C48EFF7EC8E9D49CB3C38F14B5BD96EAFD51B4+75075F3519ACB31171C02A3E70451878A0C01730+75269D293DB040608C694109B0A8B729FA94D12+75E63DB58F643AEFAF6E17CA38A77494FC45DF5D+75E95EAA24B11F59B8F06837F0B38743C7ED58A3+76F12392DA75F704E1759C8A9FA76007C4F2D82C+77B8B0538AD339DCB296E6C2A4DDA048E24F346+77BF48E4B80803041FD1357B7BB836B6394F55A4+78634FB9C7A08DCEFB3C5423C23A5F962FEB9B4A+7CE7931B070AAC9687696CEDD3CFDF822A8279D4+7D00BFC08346E223B58E3774BED6B1C9D118F5E0+7D886BE5360A86BE3AF6D6BDE95C64CD640E522+7F09C91D218339A6E07328D64429E7E30747EB6A+7FFDFBFFE767FC758A6D29ADAA84D11D908F344B+80B4E3A317A16EC89C1525D6838E7A619DBD9C47+80D1078EC53308F507AF3B1515A45E14680DFAFC+0FCEF96681C73FEA65D847349B7CBF9A46ED8E6+817ADF44836E6E71C365FEB8DB810CC5403F04F3+8183F0D8D76CF92F35899EA98F8135EB9B0E80C8+81DD41F46EB457337248B2D0B208B70F2A06997B+8208BAFED03EF6E98038345679CBE655135F792+833ADEF6A5CD4D1DA1F4B8B6060345368F5B8506+8401703254E2DFD862F3E1015FECB4B940CDDF5D+852DE73E5E8465D607CBE4685A3158AD5225F337+85384EF426E57B5BD704097037C207F140CE9ED5+8675D6AA701696F81C0419C7E48333C075EE33A+86DA06023C3F9E0E90CD32F85D754DA0A4696215+8726B3154869E52DA197DDD8E0EFFC0BC637CE89+874219A59E1B32EBB04639021F8A4E3742158CBD+87E70980F89893DC460E897CF41361288D98D90+887E253B86B280DA94F3B119B697393EF8AA41C8+8892EC4E9281593A7C784B10D3CB118B2FC1A931+8897E68DCED81942FEB35C680823633DB22F5449+889EA5B82AB92C885ECEB5E6E3D6312F0A4BB1DF+88AFD9C84761F8E23F11F59E6666381F45F62A6+88C40F3241ECAE83B21E64BB00349A09F9A2FDF9+890D7E99A9C7CAF2B0B41574CA54BA84D7942931+89AE45BD219EC98D3837F66A333FADF28C068A9A+89D6572C12D61CEAA4547476113294BB4DA79137+89DF50ADA4DF1A29EF3D4F64D3C47512FC58403+89FDBE308984AA76D82E8FA79A92153146A4841C+8A1FE8125FEC072CAB5A81339A96E3E25DC40EFA+8A37D046D5E696B40F9D367DE9B5E1AD3FB63C12+8A5AB94CF9AA25AA48ED74383274B110650E746+8A707B992533D269732BEE35BF2C90BE19FA82C8+8AADD8DDFA47017646C4ECB391404290F7B0A362+8BE5E002216A58895ABE9D8680FC6CD74FCE8C06+8BFB1A26D1E4571FB90DCEBB4DFD41A98BE3A5A6+8C4FB846801A2FD8875A95ACAC98548D8A6147D+8CA99E741D24C9634D3BE10E8FD4164D63364437+8DF6E3E5C81D3CD2E79B8374062C087FE39B3F57+8E83CAE9800E2688F5D29E975EB4CB8A5D1206FD+8EB5C1D8DB0009D66F352BF32BC6A544C0D9A074+8F0EA0D63677F6871F677791AA0C9EEBBC9AE61+903F76994232D010CCBBC0F5CF2364E315462DA6+91A967BC205C7E7C0C77903DA69F4A485D6C7E1F+926FBD5073A857E47D8C6BF675B1E4764B3FDCC2+92813AD1FAA843598116179E07CD9F0FD598D3F+92FDBB6EEB79A22056CD4901399F147DA229353B+935BCBC0217AC51B41C57F8B5425E33001D5B097+938B66249BC029CEAC9881E24170B13E254E1EE9+93DF9F56C7D6BEDF721D2BFADEBCB4EE9D6121BB+93E1455D3F70CCBC232A53E6CD15ACA1B62A5B1+94839EE51D100CAC68B8E35DA652F94452B3CAC4+94848881AD8E126C42FABE52CC48A07545E86B3F+9506914B6F1C4F3269C5CA3260FD818C5268524F+961C6983A289A9ADBD197F131B264CA167AFDDBC96B32736A5CBABE8200737F24D1BDE81385D143A+9AC9EE96BA7415A48070D644433C408D97C72558+9B5B8BB8DD31A59B4B9A984CCFD863869661D223+9C017143B8AB6AD270149CE57785B800471BA3AE+9D1997FE73A82F06C9C145F10761D0E38ADFE35+9DE4B468008939459D2EED84D20910872D540698+9EC80438962FA35924EBAE5E279FC0B86FE73373+9F1AE19C5B64B03AD74D7B4B32E548D86031F804+A1010955558F757D341D18067BD0EB58A5FBEE57+A19371D6CFEC58EB274F610F72265533919E999+A252FF1CE50F7593CCC7BF2F295098CEEBEA8E21+A25882A9ED76FEF99A8440FEE54CF6EC36AB6CFC+A32D12BC63C5DB7210BC635264ACD89150BB3B8C+A4614B75E3BE47FA8605D46709B0F466C7F3162+A5973769C6D1542163C030861A3283320831B274+A5F948DDD7E571F3A9B03FEFE9979DEBCB02453C.z". I'll try again soon. [/log] Tor version 0.3.0.9 (git-100816d92ab5664d) on a Debian 8 Jessie. I don't remember seeing this before ! If it can help... -- Petrusko C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

2 2

Tor relay dying in FreeBSD
by Farid Joubbi 14 Jul '17

14 Jul '17

Hello, I just installed a new relay in a fresh FreeBSD installation. The relay starts fine, except for a warning that I don't understand. Then it dies all of a sudden. The time before it dies is different every time. I have googled for the warnings but could not find anything. Does anyone here know what is going on? Tor 0.3.1.4-alpha (git-fab91a290ded3e74) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A. Jul 12 23:44:24.672 [warn] You appear to lack permissions to change memory limits. Are you root? Jul 12 23:44:24.672 [warn] Unable to raise RLIMIT_MEMLOCK: Operation not permitted .... Jul 12 23:44:29.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Jul 12 23:44:30.000 [err] Out of memory on realloc(). Dying. It's the tor-devel version installed from ports. Thanks in advance.

3 3

Tor on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.
by neel＠neelc.org 14 Jul '17

14 Jul '17

Hi, I recently got a dedicated server from Joe's Datacenter running FreeBSD (it's for a Tor exit node) and when I try to start Tor, I get this error: Failed to find node for hop 0 of our path. Discarding this circuit. Other FreeBSD installations I have with Tor, on both VPS providers as well as personal machines I own do not have this issue. Do you know what could be causing this? -Neel Chauhan

2 1

no abuse complaints?
by Erik Winter 13 Jul '17

13 Jul '17

This might be a bit of a weird question, but I keep wondering about it, so I'll try it anyway. Since April I run an exit node, this one to be precise: 84FAA41C7A7E83EC18964683E1DBA4B6C9E63492 According to Atlas, it works as it should. I have an exit page and a whois, both with valid email adresses. There is some spam filtering, but I also check that folder. In those months, I have received no complaints at all. Not one mail was sent about the exit. Now, this is of course a good thing. We don't want complaints. But it is not what I expected and what I prepared for, so I keep wondering whether I'm doing something wrong. I live in The Netherlands and the level of education about Tor is supposed be high. That might keep authoroties from complaining, but I also heard about bots that send copyright violation notices. So far, they haven't been able to find me Any ideas? Erik Winter

2 2

keys.gnupg.net broken; can't add Debian Tor repo
by tor 12 Jul '17

12 Jul '17

I'm trying to follow the instructions here to install Tor from the official package repository: https://www.torproject.org/docs/debian.html.en On the steps to add the gpg signing key, it doesn't work. It seems something has changed with the keyserver at keys.gnupg.net: 1) http://keys.gnupg.net/pks/lookup returns a 404. 2) Trying to manually visit the root of the domain [http://keys.gnupg.net](http://keys.gnupg.net/pks/lookup) in a browser results in a redirect to https://keys.gnupg.net/wiki/. Here SSL is broken due to a cert mismatch. The cert is for "uz.sns.it". I'm not sure what's going on. Is [keys.gnupg.net](http://keys.gnupg.net/pks/lookup) hacked, or something more mundane? Anyone know how to work around this? Is the signing key available from any other trusted keyservers?

2 2

Re: [tor-relays] keys.gnupg.net broken; can't add Debian Tor repo
by paul＠paulfurley.com 11 Jul '17

11 Jul '17

On the SSL issue: keys.gnupg.net is an alias to the SKS keyserver pool, which is a number of public volunteer run servers: https://sks-keyservers.net/status/ My guess is you hit a misconfigured one that redirected you to TLS without checking what host you requested. For example I redirect http://keyserver.paulfurley.com to https://keyserver.paulfurley.com *only* if the requested host is keyserver.paulfurley.com. Otherwise I would serve a certificate with a mismatching domain. I'd recommend posting your finding to the sks-devel mailing list since it's probably something the pool should look out for and warn servers they're misconfigured. (I'll post it in the morning if you like.) Paul > > On Jul 10, 2017 at 10:58 pm, <tor (mailto:tor@anondroid.com)> wrote: > > > > Actually, the directions on https://www.torproject.org/docs/debian.html.en work okay. I was trying to automate things with Ansible, but the format changed at some point, from something like: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 url=http://keys.gnupg.net/pks/lookup?op=get&search=A3C4F0F979CAA22CDBA8F512… > > > > to: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 keyserver=keys.gnupg.net > > > > The URL at /pks/lookup no longer exists, so I saw a 404. Using the newer format with just the hostname of the keyserver it works okay. > > > > Regarding http://keys.gnupg.net I still don't know why there is a SSL mismatch in the browser, or why you can no longer access the web UI, but it's not as broken as it looked. > > >

2 1

Windows relay performance: svchost process
by Vort 10 Jul '17

10 Jul '17

Hello. Since connection count for my Windows 7 relay began to grow, I have started to notice unusual CPU load pattern. That's a periodical spikes every ~8 seconds. First I was thought that this spikes are generated only by tor.exe process, but then I have found that svchost.exe process have identical spikes (I guess they belong to NlaSvc system service). Do anyone know why this can happen? Here is the screenshot: https://s8.hostingkartinok.com/uploads/images/2017/07/6fe01ab8601548f95ba47… -- Vort

1 0

increasing per IP tor instance limit (2 instances per one IPv4)
by nusenu 10 Jul '17

10 Jul '17

Roman Mamedov: > Another idea that I proposed some time ago is raising the > relay-per-IP limit is there a trac ticket for this already? AFAIR that limit primarily exists mainly to increase the price for Sybil attacks, but since they would be trivially detected (i.e. by OrNetRadar), I do not see why increasing that limit would hurt (much) on the other side: Is there an actual demand for increasing that per IP limit? If you have been impacted by that '2 instances per public IPv4'-limit and would benefit from an increase please speak up -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 2

Load balancing (with IPVS) multiple Tor daemons
by Clodo 08 Jul '17

08 Jul '17

The objective it's making a single Tor Relay and using on the machine many daemons on a multicore server. I hope someone can give me a feedback if this kind of configuration can be problematic for Tor network before test in a real environment. Many Tor daemon, with X from 0..n, binded on different port, all advertise the same ORPort/DirPort. An IPVS load balancing at kernel level. Tor Config: SocksPort 0 Nickname superrelay Address superrelay.net ORPort 443 NoListen ORPort 127.0.0.1:100X NoAdvertise DirPort 80 NoListen DirPort 127.0.0.1:200X NoAdvertise DataDirectory /var/lib/tor/childX All daemon have the same SocksPort, Nickname, Address, MyFamily. All daemon point to different DataDirectory, but each of them have the 'keys' directory identical. All daemon advertise the ORPort 443 and DirPort 80, but bind on other ports. IPVS configuration: # Clear ipvsadm -C # Add a virtual server (-A) for ORPort. ipvsadm -A -t superrelay.net:443 -s sh # Add a virtual server (-A) for DirPort. ipvsadm -A -t superrelay.net:80 -s sh # Add all real servers/daemons (-a) for ORPort ipvsadm -a -t superrelay.net:443 -r localhost:1000 -m ipvsadm -a -t superrelay.net:443 -r localhost:1001 -m ... ipvsadm -a -t superrelay.net:443 -r localhost:100X -m # Add all real servers/daemons (-a) for DirPort ipvsadm -A -t superrelay.net:80 -s sh ipvsadm -a -t superrelay.net:80 -r localhost:2000 -m ipvsadm -a -t superrelay.net:80 -r localhost:2001 -m ... ipvsadm -a -t superrelay.net:80 -r localhost:200X -m Note the scheduling method: sh - Source Hashing: assigns jobs to servers through looking up statically assigned hash table by their source IP addresses. Any source-ip will be always binded to the same daemon. I think 'Advertised Bandwidth' on onionoo/atlas can be inexact. I can experiment a relay like that, or can be problematic/unexpected for Tor network? Thanks for any feedback.

4 5