- tor-relays - lists.torproject.org

Traffic Confimration Attacks/ Bad Relays
by 0dayshoppingspree＠tutanota.com 22 Jul '17

22 Jul '17

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

3 3

Re: [tor-relays] tor-relays Digest, Vol 78, Issue 20
by Charlie Luna 22 Jul '17

22 Jul '17

what you feel is wrong are the U.S. Feds (FBI, NSA, etc.) enacting their influence on the Tor network and trying to capture all traffic because the DOJ just announced the take down of AlphaBay on Tor. It's not a good time for anything right now. > On Jul 21, 2017, at 5:17 PM, tor-relays-request(a)lists.torproject.org wrote: > > 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. Re: tor-relays Digest, Vol 78, Issue 19 > (0dayshoppingspree(a)tutanota.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 22 Jul 2017 02:17:07 +0200 (CEST) > From: <0dayshoppingspree(a)tutanota.com> > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] tor-relays Digest, Vol 78, Issue 19 > Message-ID: <KpbduUO--3-0(a)tutanota.com> > Content-Type: text/plain; charset="utf-8" > > 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

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