Re: [tor-relays] I bumped out some more bad relays
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I bumped out some more bad relays
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 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I bumped out some more bad relays
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 -- Croax signature.asc Description: This is a digitally signed message part ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I bumped out some more bad relays
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 ? -- Toralf OpenPGP_0xC4EACDDE0076E94E.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] I bumped out some more bad relays
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: i...@cypherpunklabs.com at OVH 023455597DAB689EE84FB3A7BC7FC5F9A3E27FD6 044E647F34EDA4AC975EDAD628C4E9BCFFF1FB08 04699AF0CB2B5A7F5CF943D31011F50F601BE8C7 05601B110B888BF3A12E10E8BF3C0B02166BF3F1 075FDD85EF4B783BCC9040580168F1FC5576B101 09930800210FF35CE84F2DEEDB4F9B67812B9717 0B7B08C50E419004F77447A72FFD578061F58311 0BAE1E20ACCB1F454A3A473185D83743E140B9D5 0BB27C3A307B35B5B2D2E8774D69DF7FA4B97867 0BE6EEB76C5641BF5D2E63C49C28CD50D2A40C15 0BF30C2AC9DBEF9C79B1119808F2FCC3FD81EE0A 0D58067912EA84D955565C82A4C00A47CDEF11DC 0DD55CF27BBA1F51131A46BC0A0EED68A177D1BB 1766E98ECC8A457FDBCBA7322C93F51FE1F896E7 186FF078A2EE09E8208ACBF4DDB61FFF96AD64B0 1B1351D85E8328BE21539EA9C0C0317E3A1CE380 1BD9EEB672246E8ADFFA5FA6B1D82F43447D 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
