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@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@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
Hi all
On Fri, 2020-10-30 at 23:05 -0400, Roger Dingledine wrote:
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.
Good. Does this mean it will be check and bumped more regularly? I see that lots of relays are running for more than one month from now.
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
Yes. From the browser perspective, HTTPS should be enforced whatever the context. We may blame final Tor users or website administors for not following security guidance (eg. HSTS preload) but in the end it is the Tor user privacy that is compromised. This is lasting for months and could have been easily prevented. This game of cat and mouse is not good for Tor reputation.
Thanks
On Sat, Oct 31, 2020 at 09:37:38AM +0100, Croax wrote:
Good. Does this mean it will be check and bumped more regularly? I see that lots of relays are running for more than one month from now.
I hope so. I plan to keep running my new scripts and see where things go. Part of it depends on the next steps of the jerk who is doing this.
Or said from the other side: if you find a misbehaving relay, or if you find that a particular url seems like it's being intercepted even if you can't figure out which relay is doing it, please report it!
The sad version of the story is that there's a "long tail" of possible sites that they could mess with, and if they only mess with unpopular or uncommon, it might be a while until anybody notices.
But the happy version of the story is that the more we and others check, the farther down the long tail we push them, i.e. the lower profile they need to be to remain unnoticed. And pushing them down the long tail is also hopefully pushing them towards the point where their operations are unprofitable.
I am definitely missing the in-person gatherings around the world here. It used to be that we could say "Oh, you're in country X? Why don't you meet with so-and-so who is nearby to you" and then build human trust relationships. This year nobody meets anybody, and it is having surprising second-order effects like limiting the growth of the global internet freedom community.
Yes. From the browser perspective, HTTPS should be enforced whatever the context. We may blame final Tor users or website administors for not following security guidance (eg. HSTS preload) but in the end it is the Tor user privacy that is compromised. This is lasting for months and could have been easily prevented. This game of cat and mouse is not good for Tor reputation.
I completely agree.
You're seeing the intersection of two core areas of Tor -- "Tor Browser" and "network health" -- that were both impacted more than average by our covid budget cuts. We definitely have gotten the attention of the Tor Browser devs now, and these steps are on their roadmaps, so I'm optimistic that we'll have some not-just-cat-and-mouse improvements in the medium term.
--Roger
On 10/31/20 4:05 AM, Roger Dingledine wrote:
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.
So these got the flag "Unmeasured" but not "BadExit", right ?
On Sat, Oct 31, 2020 at 09:46:38AM +0100, Toralf Förster wrote:
On 10/31/20 4:05 AM, Roger Dingledine wrote:
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.
So these got the flag "Unmeasured" but not "BadExit", right ?
We "rejected" their fingerprints, rather than badexiting the fingerprints. So nobody will be using them for anything -- not exiting, not anything else.
The "Unmeasured" flag that you're seeing on relay-search means that for that vote, that relay didn't have the required threshold of three votes from directory authorities that run bandwidth authorities. "Unmeasured" here isn't a flag that we explicitly changed, so much as a byproduct of doing the blocking: as directory authorities added their "reject" rules over the course of some hours, the ones that did the reject first happened to be ones that ran bandwidth authorities, so there was a period of a few hours where the relays had enough votes to still get listed as Running, but not enough of the votes came with opinions about bandwidth weights.
And because relay-search shows you the last known thing about the relay (i.e. from when it was last listed in a consensus), their relay-search status is frozen in time at that moment before they disappeared entirely.
Hope that explains the weird behavior. :)
--Roger
Hi Andrey,
Roger Dingledine:
For completeness, I'm including below the set of fingerprints that we bumped out.
[...]
Group #7: other 4E6C7297F16523A236EE1A2EE23AF54ABEF15490 55D490E9E440DD4458F16ABCDD79F48396D55EA9 78F699D58F3353AB6C4CE39E3BD96CE87439753A B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9
after confirming with the hoster that you were and are in fact their customer at these and other IPs used by malicious tor relays, I was wondering whether you wanted to comment on that?
Especially since you recently added more exit relays.
kind regards, nusenu
nusenu:
Hi Andrey,
Roger Dingledine:
For completeness, I'm including below the set of fingerprints that we bumped out.
[...]
Group #7: other 4E6C7297F16523A236EE1A2EE23AF54ABEF15490 55D490E9E440DD4458F16ABCDD79F48396D55EA9 78F699D58F3353AB6C4CE39E3BD96CE87439753A B1896E58FDEB5627B6B8334E6ABD42767AB8B0D9
after confirming with the hoster that you were and are in fact their customer at these and other IPs used by malicious tor relays, I was wondering whether you wanted to comment on that?
Especially since you recently added more exit relays.
FWIW: we kicked a bunch of relays out of the network today which might or might not contain any of those, hard to tell. (In addition to other relays, too, which might or might not be related to those).
Thanks for staying vigilant, everyone. Much appreciated and needed.
Georg
kind regards, nusenu
FWIW: we kicked a bunch of relays out of the network today which might or might not contain any of those, hard to tell.
Please publish the relay fingerprints that directory authorities remove, otherwise only the malicious entities get to learn and improve since they see the removal in their logfiles anyway but we tor users don't get to learn anything because it remains largely invisible to us.
Roger's email from 2020-10-31 is a good example that made further investigations possible.
kind regards, nusenu
nusenu:
FWIW: we kicked a bunch of relays out of the network today which might or might not contain any of those, hard to tell.
Please publish the relay fingerprints that directory authorities remove, otherwise only the malicious entities get to learn and improve since they see the removal in their logfiles anyway but we tor users don't get to learn anything because it remains largely invisible to us.
That's a bit tricky because potential *other* attackers might be able to learn things from our rejects if we are not careful. On the other hand, transparency is very valuable, in particular in the bad-relays area which is one of the least transparent areas in Tor (for good reasons, though, see Roger's mail[1] from a couple of years back explaining the dilemma we are in).
That said I think we could try publishing, with some delay, the fingerprints we reject after seeing them involved in attacks. For instance, we could have a monthly list of those fingerprints which we publish, as a general rule of thumb[2], at the beginning of the following month.
I think I'll find a place in our network-health wiki for that.
Thanks for the suggestion, Georg
[1] https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html [2] There might be exceptions to that rule, though, for instance if an attack starts at the end of the month and is still on-going during the begin of the new one, or if we think the rejection is too close to the end of that month and thus the delay I talked about above is too short. In both and other cases those fingerprints will then get picked up at the begin of the month following after that.
Roger's email from 2020-10-31 is a good example that made further investigations possible.
kind regards, nusenu
Georg Koppen:
nusenu:
FWIW: we kicked a bunch of relays out of the network today which might or might not contain any of those, hard to tell.
Please publish the relay fingerprints that directory authorities remove, otherwise only the malicious entities get to learn and improve since they see the removal in their logfiles anyway but we tor users don't get to learn anything because it remains largely invisible to us.
That's a bit tricky because potential *other* attackers might be able to learn things from our rejects if we are not careful. On the other hand, transparency is very valuable, in particular in the bad-relays area which is one of the least transparent areas in Tor (for good reasons, though, see Roger's mail[1] from a couple of years back explaining the dilemma we are in).
That said I think we could try publishing, with some delay, the fingerprints we reject after seeing them involved in attacks. For instance, we could have a monthly list of those fingerprints which we publish, as a general rule of thumb[2], at the beginning of the following month.
I think I'll find a place in our network-health wiki for that.
Here we go. I added the list of fingerprints for April 2021. I plan to keep adding fingerprints monthly on the same wiki page[3], as we find them in attacks.
Georg
[1] https://lists.torproject.org/pipermail/tor-talk/2014-July/034219.html [2] There might be exceptions to that rule, though, for instance if an attack starts at the end of the month and is still on-going during the begin of the new one, or if we think the rejection is too close to the end of that month and thus the delay I talked about above is too short. In both and other cases those fingerprints will then get picked up at the begin of the month following after that.
[3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-finge...
Georg Koppen:
Here we go. I added the list of fingerprints for April 2021. I plan to keep adding fingerprints monthly on the same wiki page[3], as we find them in attacks.
Georg
[3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-finge...
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete) and continue to work even a few months or years later and is more automation/machine readable friendly than the current approach
- perform rejections in monthly files (files are included in the dir auth config) YYYY-MM
- have a monthly cronjob that copies and pushes the priors month file into a public git repository
kind regards, nusenu
nusenu:
Georg Koppen:
Here we go. I added the list of fingerprints for April 2021. I plan to keep adding fingerprints monthly on the same wiki page[3], as we find them in attacks.
Georg
[3] https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-finge...
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete)
Could you elaborate on why you think May 2021 is incomplete and how to fix that?
and continue to work even a few months or years later and is more automation/machine readable friendly than the current approach
- perform rejections in monthly files (files are included in the dir
auth config) YYYY-MM
Hrm, maybe. I am not sure. One thing that makes things complicated is that not all rejections are attacks in the sense we mentioned in the wiki, so we would suddenly need to track those cases in different files it seems.
- have a monthly cronjob that copies and pushes the priors month file
into a public git repository
The wiki is essentially a public git repository. I am not sure what another public git repository would give us.
Georg
kind regards, nusenu
Georg Koppen:
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete)
Could you elaborate on why you think May 2021 is incomplete and how to fix that?
I believe DAs rejected >1000 relays, but instead of listing their fingerprints on the page, it links to my email which includes a truncated list and does not contain full fingerprints https://lists.torproject.org/pipermail/tor-relays/2021-May/019644.html
The wiki is essentially a public git repository. I am not sure what another public git repository would give us.
it would give users of these lists the possibility to consume it in a much more trivial way without having understand the semantics of the wiki page curl https://gitlab..../$lastmonth-rejection-file
kind regards, nusenu
nusenu:
Georg Koppen:
suggestion for an improvement to this process so it will become more accurate/complete (example: May 2021 is incomplete)
Could you elaborate on why you think May 2021 is incomplete and how to fix that?
I believe DAs rejected >1000 relays, but instead of listing their fingerprints on the page, it links to my email which includes a truncated list and does not contain full fingerprints https://lists.torproject.org/pipermail/tor-relays/2021-May/019644.html
Right. I was for some reason under the assumption we could get away by just linking to your mail. But you are correct, we should do better here. So, I went over our May rejections again and updated the wiki page with the ones I think were missing.[1] Thanks!
The wiki is essentially a public git repository. I am not sure what another public git repository would give us.
it would give users of these lists the possibility to consume it in a much more trivial way without having understand the semantics of the wiki page curl https://gitlab..../$lastmonth-rejection-file
Fair enough. I am not sure yet how we'll make those improvements, but I've filed a ticket[2] at least to not forget about it. My current plan is to tackle that task while re-doing our bad-relay related tooling, which is supposed to start Q1 2022.
Georg
[1] I included an additional fingerprint that I missed while I was at it, as our tooling for that part is obviously not great yet.
[2] https://gitlab.torproject.org/tpo/network-health/team/-/issues/157
tor-relays@lists.torproject.org
-
Croax -
Georg Koppen -
nusenu -
Roger Dingledine -
Toralf Förster