- tor-relays - lists.torproject.org

Re: [tor-relays] tor-relays Digest, Vol 78, Issue 19
by 0dayshoppingspree＠tutanota.com 22 Jul '17

22 Jul '17

Hello. I apologize for leaving some of the relevant information out on the 1st email. The relay operator did contact me but im not him. Ive seen it from the client side, where all my relays starting with a US bridge automatically connects to 1 or both other nodes which are also in the US. Ive had all 3 of them, Guard Middle and Exit All US Ips over and over and over again. Changing bridges only works if the bridge is changed to a non-US IP. As soon as i change the bridge to 1 that hits a US Ip it automatically gives me a middle or exit or both in the US. Later in the day i was contacted by a HS operator who said they had also witness strange relay behavior in the last 2 or 3 days. He subsequently has shut down his HS. Ive studied Tor for the last 5 years and have been an active penetration tester in the community for the last 2 years. Something feels wrong but i just cant put my finger on it. Thank You For Your Time 0Day -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 21. Jul 2017 18:00 by tor-relays-request(a)lists.torproject.org: > Send tor-relays mailing list submissions to > > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > > Today's Topics: > > 1. Traffic Confimration Attacks/ Bad Relays > (> 0dayshoppingspree(a)tutanota.com> ) > 2. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) > 3. Re: 100K circuit request per minute for hours killed my relay > (Arisbe) > 4. Re: Traffic Confimration Attacks/ Bad Relays (Matt Traudt) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 21 Jul 2017 18:12:25 +0200 (CEST) > From: <> 0dayshoppingspree(a)tutanota.com> > > To: <> tor-relays(a)lists.torproject.org> > > Subject: [tor-relays] Traffic Confimration Attacks/ Bad Relays > Message-ID: <> Kp_uyMv--3-0(a)tutanota.com> > > Content-Type: text/plain; charset="utf-8" > > Hello > > A few users have detected suspicious activity around certain Relays in the network. There could be Time Confirmation Attacks happening currently on the Live Tor Network. > > If any Tor dev see this, Please Start Checking The US Relays in the network. > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com >

1 0

Necto.onion relays (Necto4 etc)
by Geoff Down 21 Jul '17

21 Jul '17

Dear operator of relays Necto4 etc. Please remove OpenDNS filtering of any sort from your exit relays. Note that abuse-team(a)necto.onion (as per your port 80 page) is not a routeable email address. GD -- http://www.fastmail.com - IMAP accessible web-mail

1 0

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

20 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