November 2021 - tor-relays - lists.torproject.org

Loss of Guard and HS Dir flags
by Eddie 29 May '22

29 May '22

I currently run 3 relays, across different servers and today I noticed that one has now lost it's Guard and HS Dir flags. What's surprising is that this particular relay has the highest Bandwidth and Consensus Weight of all 3 and has not been restarted for over a month. The stats for all 3 can be found with: OhNoAnotherRelay I know that just running the relay is the important part and caring about what flags it has is a side issue, but I'm just interested in seeing why this has happened. Cheers.

4 7

Bridge showing offline
by Eddie 12 Jan '22

12 Jan '22

Looking at tor metrics, one of my bridges is showing as off-line: B080140DC1BAB5B86D1CE5A4CA2EF64F20282440 However, the log isn't showing any issues: Oct 14 00:00:28.000 [notice] Tor 0.4.5.8 opening new log file. Oct 14 00:00:28.000 [notice] Configured hibernation. This interval began at 2021-10-14 00:00:00; the scheduled wake-up time was 2021-10-14 00:00:00; we expect to exhaust our quota for this interval around 2021-10-15 00:00:00; the next interval begins at 2021-10-15 00:00:00 (all times local) Oct 14 01:49:40.000 [notice] Heartbeat: Tor's uptime is 124 days 6:00 hours, with 0 circuits open. I've sent 907.23 GB and received 922.28 GB. I've received 63052 connections on IPv4 and 8375 on IPv6. I've made 512684 connections with IPv4 and 100974 with IPv6. Oct 14 01:49:40.000 [notice] While not bootstrapping, fetched this many bytes: 1801791624 (server descriptor fetch); 175792 (server descriptor upload); 221750347 (consensus network-status fetch); 10974 (authority cert fetch); 19905655 (microdescriptor fetch) Oct 14 01:49:40.000 [notice] Heartbeat: Accounting enabled. Sent: 140.52 MB, Received: 140.69 MB, Used: 281.21 MB / 200.00 GB, Rule: sum. The current accounting interval ends on 2021-10-15 00:00:00, in 22:10 hours. Oct 14 01:49:40.000 [notice] Heartbeat: In the last 6 hours, I have seen 14 unique clients. Initially I thought of a previous issue I had with IPv6 connectivity, but don't think this is the problem here as the 2nd bridge on the same server is showing on-line. Also an IPv6 port scan shows the ports for both bridges as accessible. Ideas ?? Cheers.

5 8

General overload -> DNS timeouts
by Intrepid Ibex 07 Jan '22

07 Jan '22

Hi everybody, I am new to tor (as server operator) and try to support the network by operating an exit node. Machine is running Ubuntu 20.04 - Tor 0.4.6.8. nyx is giving me a notive every 10 minutes or so: [NOTICE] General overload -> DNS timeouts (6) fraction 1.4742% is above threshold of 1.0000% DNS on this machine however works perfectly. I told my tor browser to use my specific exit node, everything works fine. Node is running since 4 days now. Load is as expected. Thanks in advance for any help! Ibex \-- Sent using MsgSafe.io's Free Plan Private, encrypted, online communication For everyone. https://www.msgsafe.io

13 25

Relay operator section in our forum
by Georg Koppen 21 Dec '21

21 Dec '21

Hello! Some of you might already have seen that we have a shiny new forum now.[1] And, of course, there is a part of it dedicated to providing support for relay operators as well.[2] Check it out and feel free to contribute! Thanks, Georg [1] https://forum.torproject.net/ [2] https://forum.torproject.net/c/support/relay-operator/17

5 7

[Looking for feedback] An easier way to declare families
by Nick Mathewson 14 Dec '21

14 Dec '21

Hello, relay operators! I'm hoping to get some feedback from relay operators, particularly those who use the MyFamily option, about the best way to deploy proposal 321. You can read the proposal at: https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/321-… The main idea of this proposal is to provide an easier way for relays to declare that they are in the same family. With proposal 321, each relay in the same family uses a cryptographic certificate to prove that it is in the same family as the others. (That's just a summary; see the full proposal at the link above for a write up of how it works, an a description of backwards compatibility issues.) Now, my question is, how can we make this approach as usable as possible? There are several different ways that we could have it work in practice: Option 1: Every family would have a shared secret. This would be a random file that you'd have to copy to every relay in the family when you set it up. The relays would use this shared secret to derive a shared private key. If this file is ever exposed (for example, if a relay is compromised), you'd need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We could provide a convenient function to make a new secure shared secret, something like: $ tor --new-family-secret <filename> Option 2: As above, except instead of the shared secret, it would be a shared ed25519 private key for the family. This would be an ed25519 private key that would have to be copied to every relay in the family. If this key is ever exposed (For example, if one relay in the family is compromised), you'll need to make a new one, and copy it to every relay in the family. (Otherwise, an attacker could claim to be in your family.) We'd provide a command to generate new keys; it would look something like: $ tor --new-family-key <keyfile> Option 3: Offline certificate generation with separate distribution. In this scheme, there would be an ed25519 private key for the family, but you wouldn't have to copy it to the relays. Instead, you'd have to generate certificates from the private key offline, and then copy those certificates to the relays. They would have a lifetime of N days; you'd need to make new certificates every N days. If a relay's certificate is exposed, you don't need to generate new certificates for the other relays. You just stop generating certificates for that one relay. If the offline private key were ever exposed, you'd have to generate a new one, and a new set of certificates. The interface would probably look something like: $ tor --new-family-key <keyfile> $ tor --make-family-certs --key <keyfile> --members \ <family_list_file> --out <certfile> --lifetime <n days> Then you'd do something like: $ for member in $(cat family_hostnames); do scp <certfile> member:/srv/tor/tor-family-cert done Option 3 requires regular updates to all the relays in the family, which makes it cumbersome. Its advantage is that if a relay is compromised, you don't need to re-key the family. Options 1 and 2 are less secure, since you have to re-key your whole family if the key is ever compromised. But they have the advantage that they don't take any maintenance in the regular case. Option 1 is a little more convenient than option 2, since you can use any old random file. But that makes it more error prone: if somebody chooses an insecure password as their random file, an attacker could guess it and become a family member. So... If all three of these options were available, which of these would you choose? Is there anything else that we could do to make this system simpler or easier to use? If I'm left to my own devices, I will probably just implement option 2 for now, but leave the door open for option 3 in the future. best wishes, -- Nick

5 11

I bumped out some more bad relays
by Roger Dingledine 10 Dec '21

10 Dec '21

Hi folks, I spent some time this week refining a new exit scanner, and today we pushed some new reject rules to kick out some relays that we confirmed were running mitmproxy to do more sslstrips. For past context, see these urls: https://blog.torproject.org/bad-exit-relays-may-june-2020 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html Expect some upcoming next steps that aim to change the fundamental arms race, including experiments to use https by default in Tor Browser, either via HTTPS Everywhere's "Encrypt All Sites Eligible" option (you can turn that on right now) or via Firefox's upcoming built-in version of the idea: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19850 For completeness, I'm including below the set of fingerprints that we bumped out. Note that we didn't confirm misbehavior from all of them -- some of them we're bumping out because they seemed sufficiently similar to the confirmed ones. If any of these are your relays, please speak up! Thanks, --Roger Group #1: COMID (coronamitmdisease2019) at OVH 019839E66C7229039367BEB4E83B27D08A9C2B37 110F26C0BFB2122BBB856EADC9A2D497989DE949 1B473D4B5C1D7C594E88B3044823D04E2BC51DBA 28EA24439668FBE905C801F8170C192E119C9FBD 378C5C8381700EC68EFDC427148CDE18DD94A014 48325E9146758F8636473D6D25FD4D7734E189CB 52DDF76A32CC3E0BFBAD72E511A0354343A224B3 7A8089D801EC09B20B1091CB031C79B7E0371818 7BD7DB37884F3DADC61E755FA9F03F499BC3C552 840C79C994150D6F6A48B5F8E8658AB74D36B052 852FB4885C5F9DEDE66BB9E5515A81EAE6E43B6B 8FAB1ADF9BE2D0E821AF92B8215F692CD715FD73 A2BA8791AA2A27DCB5B0C5B51E8CCF2337A5C1E2 BD32854443E891DBB685E43854BB382DEF081E94 C271F036CDFE8A90881B60712BF6ACF742259764 CA2F7497106CB8B9AAF0E1A7CF9866EAC9DB43B5 D26C58809FBC2C0D0251FB2991470A6AAB3EDC5B DE50C4066BE7200F5D6AD0FC88452667451D39A9 F2D5E3A3E8B11CA72FF340C450A46F4C67AD8D1E Group #2: info(a)cypherpunklabs.com at OVH 023455597DAB689EE84FB3A7BC7FC5F9A3E27FD6 044E647F34EDA4AC975EDAD628C4E9BCFFF1FB08 04699AF0CB2B5A7F5CF943D31011F50F601BE8C7 05601B110B888BF3A12E10E8BF3C0B02166BF3F1 075FDD85EF4B783BCC9040580168F1FC5576B101 09930800210FF35CE84F2DEEDB4F9B67812B9717 0B7B08C50E419004F77447A72FFD578061F58311 0BAE1E20ACCB1F454A3A473185D83743E140B9D5 0BB27C3A307B35B5B2D2E8774D69DF7FA4B97867 0BE6EEB76C5641BF5D2E63C49C28CD50D2A40C15 0BF30C2AC9DBEF9C79B1119808F2FCC3FD81EE0A 0D58067912EA84D955565C82A4C00A47CDEF11DC 0DD55CF27BBA1F51131A46BC0A0EED68A177D1BB 1766E98ECC8A457FDBCBA7322C93F51FE1F896E7 186FF078A2EE09E8208ACBF4DDB61FFF96AD64B0 1B1351D85E8328BE21539EA9C0C0317E3A1CE380 1BD9EEB6725555246E8ADFFA5FA6B1D82F43447D 1C11D59B0144E9B33BB932A031BA8A3A5B81C65E 1D0971FA9B98AE2807D6A44AE6EB7EB120AB5675 1D515E91312D5F79895D607D6C27392DD5F6A84E 1EC0CCAFA8ABD5470B062AF470EAC97DD069C655 1F00A270AFDA1172DEDEC138AFEE977CFFB0FAD1 1FD39D081A3AA8E3D6F0962F8281A448D536C879 2369F6855A7CF31E3174CE26678FBBAD6A31D883 23BCFD8AB533AAE05639D1D79A445DEE76F8E57A 2541C0EB6F66C1344B3F14AB65EE7D6882EEF15F 29EC42BC7A3E7ED811578D5F656EC76D7A7AA2A5 2DE12251A7AF25B2CDFA9DE0F1B4022685ABAF3B 325499E7D6927D51229019F2EE031F26EBE095BB 386425D28458D4DB41F74F256AFF99ADB7E25271 38C36322890194015837A1085907DFA6AE3A9B00 3A6164437EF523E4907E7D97CAB135EFC39621F6 3BB398CA2D1F1E83AFC46641ABF8FECC989B8F19 3C5491293747761AFE9AF014FDA4B92960304D21 3CAA25A190B2F030DE86D0E99329E4D399472FB4 3CE91268F607E373482D1BCD33018CF1C77FAFA6 3DF6717E1C62D9ACF65CD5B3C609FBB271D9586D 3EE2A784ADB2F56E631F281F2688104A656E19C2 41280DE9ABE5BF10F7F5DCB13A28C07082064147 41E9201B42807012BCAFA6B94BCF9AD00CD787EA 442058BAE48FDFA68A3992988CBA6E2035FA8782 446FA7DE8A5DC2F2B0EBB9083753D127BB217F60 466F6F3B37435A6285C1F73F49EC58FA9D3A5260 47B22D6B46447B533E962966B9559E249B6F915C 4B777C07DFB28938D7D9B84737275F2412B5CA2A 4C52890A00964648E3AED7EB7CB178BA082610E6 4C6E75E65818844B7D3F3A8A9666525680006EAF 50A4A3A09AC7BC09F578670618A9BB864772EE03 554E9EE1586220B016B7C43490E7398F57C254D5 5A8A80399011B703FDB40E11226A389162DE0DD1 5BA611940BC239597312636D257F615F4F4D7BEB 5E6CB5FC020088CFC99342784A4109E468D7C94A 60D6F3FEE07527E749BD6BB3E401E5EB389EA45C 62CC081F58E5415DDD49A20D80A0E9A8A2E35CF3 63E4BD985E436877C471A743F1625F10FA114458 678FDB3BA0EEAA2572329A0BB0FF50E449D714ED 67FBB854B6DBD2DCBA5747FD761BF36096EFC0C0 6B6B3650F2FF83BD767AD84838600C62F937558B 6DA708660BA6F0BE1B67434951F0D0FE6AE72728 753C8EEDB1C2A9E1DBBF4DF75A2F549FD1A7F0FC 8002F46087D145E1CC5F4F11725494059E7A823D 80DF1465F2F27AA933DDB3A8F8A2AE06D3D859DA 823C31DD41F31ECDB44DB17198EAC2EDB7A295E8 85BFDBFCF9E711CF0F1A22C115368724D7C101F7 85D895B55F1A021663D441587F4FD822082E73C9 8668B39793EBDADD148AE8BB256B1E2E6ACD78D5 87B449E227ACB5C3FEB580942242183993866138 8D112569E620CB316F1FDC08BCFD93FF54F22ED9 8D599159A555665F199DD0F9E81277417C8D3973 94729C093EBFFC6102C47EE1EB40A8827AEF28E8 968CF9A51740B682ABE4DB11829488281B66DBD8 99F01989477E1F553BE789E25FB63CC2A2276E33 9A46602C82BD2C174F1C115A1D6E012DD0DFB57F 9C2EF7092D80859AC3DD4A39DF50B725D2BC3D5D 9CA1FCF374E5CE8F652DB08B16BB874EA839C0BF A3317BF385CFF595CC27997BB5A6C2FB35846D47 A6DBE4FFB33677E56BBBD0911AA489927650ADCA A7FA78D175541179556D66C8C78D69D238274F7A A81B621D6401BBEEC8E2C84228141BAFA711D0D9 A8D70BB95B76B3B5E6F6B4E30C2EFB11A21E9D1F A8E6126DA7D6DE9A719162CE8980F8755B612F21 AED640FB85D0A5C43C756FBEE19D1075DAF8E686 B34E09B1C68F46483A1A90551ACC78D87C80C08A B6F6B44DF12B2F1B74B666AA48F2BA0E5CFDF169 BA38FDB6FE97442388C35FE83F371BB1C6C4324B BA405E953DBE33BA2388F6B5954EDFBCE4CD1196 BC70877D0CBDFA77E6B4B88DDC23D03F8299CC02 BD9E37F7FD8773AD0C07B22394F179288DC5E2CC BEE5A27A9DD05BD7D9B6E046AEDEF43D2A4B85CE C31A5F636926B69C72F992F005D0BDF48040B283 C50ED548D22C1908E58AA194AD3DC966FD267E06 C6F1E2ECA92A5DE6710F1317DB040EF2CFFC5C92 CDAA1A9F705EBE23E9FB63B3EFE6699205E2F8C6 D018720BE031BA9CC0DF4C0E21ADBC649C325C62 D2816DE9B3040231DE6A431583C26FE65B5C929D D57751F73AE9DBFEAFAC282473615E5F6D269614 D7204D395ED3E4B6F6D81C38D8D6A9241F58250F D74C47EA991FAE041C2CBB233493C6780B197A14 D888307FB9A44E75FEDF0DD2DE3AB9659E6DC6F9 DC74048330C6037ADC505E0AF63E2A9F765F6B57 DCB6273B2D2AD09AAC021141136CD461994D1533 DFE448D8C5D81AE687289A225B64F704A7FAC877 E5A3F4D29B0E3AC5DD93D9921FE203702F558BD0 E781B862FEBE3C40029A0350BB0ABF4E184086DA E8F32BBFEAD7EDC6A40732EAEB15CF5C6DEFF225 F0CD6DD3766EFB6CB409EB148B6B22FF0B765533 F6CDD5AAF675F44B88BB326EC0738BD7277CBC12 F8E6613A7AA382960E00FC70A2E15A7B2F3F3FA0 F9DF89DCD30D238443245B5483A5E10F3D52C101 FA611C0BABB9DF7A63AC2877A5AB5A6880FBA51F FC33CA0B739EB8290180C7D22A536726B8EE90E4 FD00BDB335960AFDCA6CD565B81DEF2BA7F27E7D FE9313D50FB0E68F674812BF7CED0D8F2C2B65E6 FFF5DF7E9EF2A78210BE8E17E396CFC79797AC92 Group #3: Cypherpunklabs(a)protonmail.com at OVH 0D97E4B39B1986B688E90BE1FD996E492F2552DB 0E0D2A2E71A61B9D209DB4CE5E6DBEB98473E4EB 175D1B74B0271F5997C27E020AA167A013FFB7C9 215A723CB44D8ACB001D12C7832FC742921B4F64 241F67E50CA7D5E522F94E28B5AB5ABE4F166616 2723A5FFD3B6ED842EB44C380D3AB4D26DEF60AA 34BA457C5120D5E7DA9513C7B98733C57503E3E6 3A992EE90A372FF4ED0DB1E26D9662E967C84A92 3DAEC5687EAB19CC9FBE98303780137E143236AB 4169E219D6FFCF419A5F5DA6A66E0DC5782F8F8B 42215683AE0D359B6BADF2674D09BEA348BE388A 438587D73152254E935FC1D387003DFA18166EC5 56B310D18861A5F2A57D73269B6C11EDFA4EED1A 63584BC1EF29E794A63C264136D7825C33F0889D 78E40CFC92AA9265BB50494B75BE8E7F94659E8E 8049F8C058587A66246E8A93A56957CE29165F72 84D4A8CCE76EEAC3FC45ED7A78A05F7DCD68CE72 A613E402885F5D248889CD6EA85DE61D022D760E B3AA9132A7D759863BFAB6CD12DA6646F2A5D1AD B4598727C0B2A1313AB9DE822EDC6ECFDCC78FC0 BE1E17C00A4BE0FF280CFE062D03F261061E2E63 BE48173BCF9F2C3448192916BEEF01EA745F7DA3 C1C568D3802481F1BC15F9CB75A4B4DF7592BE50 DC818C243B318D19D07DACFC2E7CAD327C7E0B3E DE81E82F60AFCA34FB5F94D78F590FEEBB435CDC E05546C3458B68C2B1ADC7273AE0539E6325B910 EBF91C6220CE4890E2E94D32F3B6B96991ADC807 EC1EEF4ABBAA11CE8C978E6C87182F63AD27A4F8 F5AD7DE58D0E038B48761AD995F9117DA072BA47 FABCC633B0DEEE6FABEF3FA415A2B0038B2A5A00 FC8C3644FEE491C828EF7A980F9E2CB0D12F4D0C Group #4: other OVH relays probably run by the above 029F57C3B3504B797C189C208AC57B5D141F66D3 05EEF2F6029F70734AC5F64557AA2FE37306214F 11F30B96054A494093AE43310B1BD681AF76CADD 13E07E74D492BAC41B6C83DF66CD6022C576C4CF 18D0C3D3145B3F6FE48D13030A3B62641CBD3969 199937E2431394D8FE1219535763ED45DEEC6F9B 1B7A8EB93B36BAE221B5E0B66688864F508CDEBA 2254F9FB12C036595777E3C55C7F9AEEFDB3A0A9 309A43E7861F9DDCBF9C063B7FF94C53C7784BCD 336815FFC4B20050F240827FCDD20A66454C538C 3EAD45A64281E3447EE501B3D88CA8FBB041C749 4ADCECEF8450D38FAD26154A3689CF5DD53121EA 551CF8E26FD81CD95EC75E7530A6ED5120AFA769 56731D73A7BF7600C2942ED84F2371B9BE26117C 6513031975D1B4835C5483F482152B85BBA8F2DC 7F52A31991B48A95A52EDE2CA4E161ED70124B4A 815E359B9C9CC44B9CE2D7233D40E96AF9000206 89BDEBC7DC4FB7FAA0914E18167F3E9A69E20700 8D4AA79E47B1C99116DC8E8F301BD574021B88AE 9CBF4C88F2C687DB501A374ABB960EDBAA1CD911 A249B7EE9F843694A8CCE1DF8DBE8627A1EA51CB B2DB1519E42B22BF2C204D2873A2021BEBD7249E C52426AA31F0D90A4E53320858B98547A81BC86D EFAB57D3EBABB4F922F850763E88B447A2F4CC09 Group #5: at Frantech 13BFB7E95E303AC22A005F7D4D08CA9655925B40 14F21BEDEE20BED716234E7026822DF9E69EC356 1EBE3083FCDC9658188A2C7F67B83C531E641039 1FBEAFC6CFE71F1EEC3D5F62A2D896B1F87B2F4D 258837F888FF885131F8F12BC409D69F99597E6A 2DBA4CFFFD04A3EDA74A58264B4E4F351AA0F5A2 3D07B333ED3A81C557D39DE8A4EABD9BC0D6B0C1 3DCFC8F04E088BB33228FED97662D4E87B0F195A 3DE14798CDD62F6FA29DF21F418B4DFCEB0D59F4 3EAA79A75F96F4A082DB92E5FA231452BAD3F80C 4084E7226F6A6463C32F28841EA10A7796D10254 475C893CCA9661B407865B6DBB30C021AE45F1DA 6636D34B1502FABFE0DF848043CBCC0E4C52F12E 6E4DC86BC268306583E6C5640F11F17677663EDE 70797E7080F116E302A0F2A8F901FE914A3E625F 817C637920A7D4036CF665C6EC2D9842A7E73B77 85C8DBFB5574A338CAC8603CAF330EBF93219079 8A4C65C62D82C8783A6B51379A0E033464A4DF3C A40D5345ACA7439DAEA3801C3C473731B68A6E9B A95E579F730F719941392B6282676319839627F5 AD2A2BCC14044DA38F17FF37E6416C30BA1DF80B BCE0092B89D2C804483161D6E4C8FC81C56AA2B6 CED3133934C7B50F5A66323BC37AAEDDC875460D DB739627A2E20DE302A0D25F21B8B372D4AC2963 F44CDC27499333A14D55B8E28B9240BC8B206532 Group #6: at Leaseweb 0110D7D65C572B36C4CF4DD564B0BBB0B2ABF98D 08D8EC605A5CF77B6AC3F9CF34FA2B32E6F0EB3A 0B477F70980938C5287C04A8256951DEDBB72E4B 17038EAF590FCFCD4D17BF800892D61498D922D2 1818B3DA74DCBFC796CBA1011CEF41329B500DA6 1A7C2D579CDCE10C85E42FE515EFBA48A17A7D17 1AC81B2F05A3EE1DFEA330D3FD981E2E7F450C79 28724DB378396B1CD079D75824D9ADAEABC4C469 289730865CD9615FDAE620C65C973B3D99F6BB07 29AA1984FEEFA60093F72160B5EF44CA50B4EBBD 319A356599E538FC22697F8E982D94E0611C800B 333396E790E6CFA31C594B0D5F08DECBD02F8FEA 349379251F9F22044F46B214EC793DF724341096 36A358DC10EC2195303E141FC408A0706E5DFD81 3767BCA088F4C54D688F47C57B9868C9DF7D8D64 42EECE234646FB6CA84552BE7C915867E2ACDAC1 46A97AF8E2E20178EDD4D9F931B054FC1BEDC00A 47E7F131379F8DEC0909F2F9395331F4C67A538A 4839BD15B8E8BBDA5CDF304ECD7516D104CDC7F4 48E6494B14CAA7DFB4D87E0A76CA829F37C8D1C3 590D532DF6DB0E4E55150E397F2EFC3ABF76E755 591361152F37D13DCE8FA5827D109071725416FC 59571FEE54462C0E1B540D1E155B2334B9F10498 609A3FC47277EFD1683A0FC5A5FD07E261D0833B 612BF4A52D0DE957BBE376D4ED5A4203F9B2D7B6 62074297A05126F4C9C4F30F1338FD6C69099623 6A676D859C2D12CA8B699E710DF63CACC406B08F 6C03F70B7A90BF179ABBD3E0A854C2A1AF123966 74F71248F22646392AF63D4C4170C3B3A02E48A7 777F3A4B86A4042489F21F0CE608BDB8026BFF5A 77B6C374D5E16FDFC7698A645383CA9914F379ED 7BA2E40A27A96505FD22CB3BCD12E3B189CFFCF5 7E8834745EF551B668F83489F56D24B05A1F897F 808B7A04D08C6D2DE38FBE3D25EC7BC745B8D341 85F1A5CBFDE60BC53F00D1E98165A259AB984B58 89CB9B4F63638DB8C3702E0990845B2170B914BA 8AB40AD126DAC0C5A7C04B17CD85315E0D32B14E 9C432CC79130F4B923ADCD853A1ED621798728E6 A1F0D5720A71E6608DBB488CEA25BD5F1FA6E95B A41E8E3246F5750A16566DF04B38CE82CB111879 A47CF942FED91883C7EF8A8431939010CE95B206 A60A7FED7F5BA22E4B37CF238957BEF152474DA5 A64ECD9EE939825EF430175365E83643FE190BD1 A95F8F3E558D0D5B4CD3BD935EEEA14C73094A52 AE073E38C4DFF57D1AB187AF8FD523F76A9F5CBD B38F79C0789282F69D787B2133C9F8F4D1FE95E6 B3BC12E565A58902BD4E73EAFFC6AA98C46F417B B5F6D1B3AF78C55369262DD17D11420C6862142C BA100669E3D81203339579FE2224D0A7E37422AA BD7D0FB739E204D23B1B0B74DC9D8E311A0552A3 BE220BDCF8AE4E9F7DDAD2BAF85C2B4CB1A592E1 C14DE0D48928ABE0C15837CF35D070E0A3B8F0F4 C5197F6405A6F1423978683272A648FF79833F7F C556E08E13E012ED234362C1EEBC0588AAF1F1FE C75B26E3D4675F93F15AA2518860302A43D9BAC3 C85B7E5F3D06AB55AB0465E5CF66E777B1375DE5 CCC48AC17A89195AB8552EE9B5734C40B47B1075 CCF5C7C279A21C592E5DDF67D57542DD84C7146A CE67975EF0235DB732ADA85C6BF36CFDEFA18555 D25B78BB13249FA73B1AA5641847A66BDF014A6B D35EF561445474543064CC0C531BE0F3CCD198A4 E158EAA8788B8CFFF06A4D888D0C6B28DC1F057B E4B00CD81069AF2C0841B82A582C63AA32F03B0C EA8762F2D07FD5FA29B6BE05AA567A28D1545B4F EF0682CFD3724312FD550EB9646F72EFCFBA1B1D F788B67C42309E3B3A889E4CADB75D962CBF81C5 FB71593F68213499DA493FF6A4BFE015203272C9 Group #7: other 4E6C7297F16523A236EE1A2EE23AF54ABEF15490 55D490E9E440DD4458F16ABCDD79F48396D55EA9 78F699D58F3353AB6C4CE39E3BD96CE87439753A B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9

5 13

Recent rejection of relays
by Georg Koppen 02 Dec '21

02 Dec '21

Hello everyone! Some of you might have noticed that there is a visible drop of relays on our consensus-health website.[1] The reason for that is that we kicked roughly 600 non-exit relays out of the network yesterday. In fact, only a small fraction of them had the guard flag, so the vast majority were middle-only relays. We don't have any evidence that these relays were doing any attack, but there are attacks possible which relays could perform from the middle position. Therefore, we decided we'd remove those relays for our users' safety sake. While we were already tracking some of the relays for a while, a big chunk of them was also independently reported by a cypherpunk and nusenu helped analyzing the data. Thanks to both of them from our side. Foe what it is worth: a large part of those relays did not set any valid contact info and/or when we tried to contact some of the relays' operators the emails bounced. However, we sometimes need to have ways to reach relay operators, be it for debugging purposes or for helping them with relay misconfiguration. Thus, please set a valid contact info when running relays. Finally, anyone running relays: try to get connected to the community so we can build some trust among each other. That seems to be an essential part in our long-term strategy to fight bad relays trying to enter our network. Georg [1] https://consensus-health.torproject.org/graphs

10 16

Relays running an unsupported (EOL) Tor version
by Georg Koppen 01 Dec '21

01 Dec '21

Hello! Relays running unsupported Tor versions is a problem we have never really dealt with in a systematic way in the way. Some of you might recall that we (with the help of volunteers) tried back in 2019/2020 to get operators, running an unsupported Tor version, to upgrade[1] but then we dropped the ball. Alas. We just started that process again by contacting every relay operator running an outdated Tor version (any version not 0.3.5.x or 0.4.5.x or 0.4.6.x or 0.4.7.x) by email where possible. Additionally, we created a wiki page outlining the current process and things we still need to figure out.[2] On that page we plan to make statistics related to the EOL relay removal available as well, including the final list of relays we'll reject. Thus, stay tuned. Feedback, as always, is very much welcome! We plan to keep this topic on our radar this time while refining the process as we go. Meanwhile, if you are running a relay with an unsupported Tor version, please upgrade for the sake of our users' safety. If you need help, join us on #tor-relays or #tor-relays:matrix.org if you use Element. Thanks, Georg [1] https://blog.torproject.org/removing-end-life-relays-network [2] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Relay-EOL-pol…

2 4

Rerouting exit relays detected - EXNODE35037
by nusenu 24 Nov '21

24 Nov '21

BadExit: Rerouting exit relays detected (1) The following exit relays are routing their traffic back into the tor network: nickname: EXNODE35037 First seen: 2021-11-22 15:00:00 Consensus weight: 1 AS: ITL LLC OR IP address: 195.123.220.84 Exit addresses: 185.220.101.138 195.123.220.84 https://atlas.torproject.org/#details/E6FBCC437A708ADC396FDE12ACF7E333BEC02… -- https://nusenu.github.io

2 1

Mystery with Exitnode 4273E6D162ED2717A1CF4207A254004CD3F5307B (176.10.99.200)
by Tschador 23 Nov '21

23 Nov '21

Hi, in the last few days I noticed a curiosity with the Exitnode 4273E6D162ED2717A1CF4207A254004CD3F5307B: Every time I call 'https://www.startpage.com', the URL in the Browser changes to 'http://localhost/'. Other browser: same effect. Other sites - no problem. Other Exitnodes - no problem with 'https://www.startpage.com' and other sites. What's going on there …? Regards

2 2