Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-23 Thread nusenu 
https://nusenu.github.io/OrNetRadar/2020/08/22/a3

2020-08-22

|   Up |   Ext | JoinTime   | IP| CC   |   ORp |   Dirp | Version   
| Contact   | Nickname   |   eFamMembers | FP   
|
|--+---++---+--+---++---+---++---+--|
|1 | 1 | 12:31:38   | 150.129.8.107 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
1FBDF7B76594A7A702DD165FE3AA0FF9F31E2715 |
|1 | 1 | 12:32:52   | 150.129.8.106 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
4839FCED8D9ADC24EAC27875C9DCD77A5C1756AB |
|1 | 1 | 12:33:21   | 150.129.8.105 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
D87D6CB4DEB3862D6E19720F82C03478E72F4CD9 |
|1 | 1 | 12:33:49   | 150.129.8.104 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
9E56C4C7B820411600309A2208BAADE18E20AA05 |
|1 | 1 | 12:34:19   | 150.129.8.103 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
A7CEB94E00C6F2BD3F2F01B98D08C889B2A208CA |
|1 | 1 | 12:34:46   | 150.129.8.102 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
495E1C78FF508FF890B2E713DE214C03A6FDC82B |
|1 | 1 | 12:35:14   | 150.129.8.101 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
4F6504E761747E7C97BB33476510155CB9080556 |
|1 | 1 | 12:35:38   | 150.129.8.100 | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
35EC704207E910A588D228E1F4359F4E0A8E27B2 |
|1 | 1 | 12:36:14   | 150.129.8.99  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
50232D518707213975BF54E0765B48B75D2EA9C5 |
|1 | 1 | 12:36:39   | 150.129.8.98  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
88FA32AA4017EF76149D98620194769FDA034204 |
|1 | 1 | 12:37:06   | 150.129.8.97  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
D2396C4220E3084F321E63110869C3F50D14F80C |
|1 | 1 | 12:37:33   | 150.129.8.96  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
927903D647C82EB597F5DF5A765D1267ACF62B47 |
|1 | 1 | 12:37:59   | 150.129.8.95  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
05F397E91B3F57DD825F7F587740117764889D05 |
|1 | 1 | 12:38:24   | 150.129.8.94  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
E02B0740D75858B34ED26C91A7870528D73CEAD1 |
|1 | 1 | 12:38:47   | 150.129.8.93  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
2C52CF3F1434E0766F57527349F298F289E6927B |
|1 | 1 | 12:39:11   | 150.129.8.92  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
6B5C54A595D55A8CAC0F40AFBC458F8E819233E1 |
|1 | 1 | 12:39:33   | 150.129.8.91  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
324F8A1AAD871AE9369B38F73C59330B461E66CA |
|1 | 1 | 12:39:55   | 150.129.8.90  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
0CB1BDD5661ACF3CBA223745A06392901E821DFC |
|1 | 1 | 12:40:18   | 150.129.8.89  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
07C60B62231B247D39FF3798C86D98A84967928C |
|1 | 1 | 12:40:40   | 150.129.8.88  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
B80867D9A92BDF9C51855EF0BA356CC6360148C5 |
|1 | 1 | 12:44:58   | 150.129.8.87  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
AF5169DD8D6DD8C0D30ECA83A2078795B41DFD1A |
|1 | 1 | 12:45:37   | 150.129.8.86  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
2406BD94F455B873694E314769180ACE9C36BB76 |
|1 | 1 | 12:46:01   | 150.129.8.85  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
FCCC526B10AF1C68DBD8C7DAD73C96E5B74A4261 |
|1 | 1 | 12:46:24   | 150.129.8.84  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
E9374AEB2099F5A5A4E2E5D47A9FB53BCDA16E61 |
|1 | 1 | 12:46:48   | 150.129.8.83  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
2E054C82D0E7EDA39246ED9EBD491904480BC7D7 |
|1 | 1 | 12:47:19   | 150.129.8.82  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
88AE4EEAB67903CECC411A6F5898156AD6A46D67 |
|1 | 1 | 12:47:50   | 150.129.8.81  | nl   |  9001 |   9030 | 0.4.3.6   
| None  | Unnamed| 1 | 
4034D164D11E382664592C989F6A46066B6E1EA0 |
|1 | 1 | 12:48:12   | 150.129.8.80  | nl   |  9001 |

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-20 Thread William Kane 
Most of the relays from the first group got added at the exact same
time, the second group got added within a few days - tells me someone
looking at the OrNetRadar logs isn't doing his job correctly.

2020-08-19 16:27 GMT, nusenu :
> niftybunny:
>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>
>>  There are multiple indicators that suggest that the attacker still
>> runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>
>> And on this one: I trust nusenu who told me we still have massiv
>> malicious relays.
>
> as some of you have probably seen already
> now a fraction of them got confirmed to run the same attack tools:
> https://twitter.com/notdan/status/1295813432843829251
>
> Unfortunately this is not the end of it.
>
> Some of them where directly linked in the blog post above.
>
> What I'm still wondering about is: What made Tor directory authorities
> change their policies and stop removing undeclared relay groups?
>
> +-+--++-+--+
> | first_seen  | nickname | contact|
> as_name | fingerprint  |
> +-+--++-+--+
> | 2020-06-20 01:00:00 | relay23  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 01C05513D12F63AE9E72588E8EAB459028C44689 |
> | 2020-06-20 01:00:00 | relay05  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 01DAC406BD545B6EB41D3E12476E70EAE4872407 |
> | 2020-06-20 01:00:00 | relay02  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 078A661362B4959F64F8E01DF4646101542E1AD2 |
> | 2020-06-20 01:00:00 | relay17  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 11F76D073C30EE2C8849602B90950659E79EB0B0 |
> | 2020-06-20 01:00:00 | relay21  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 17B63505746D57A2C3F240C63EA0DDE7B7EB73C8 |
> | 2020-06-20 01:00:00 | relay09  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 1970C3CE0F945DA0D16DF5191DC8B0483A421A75 |
> | 2020-06-20 01:00:00 | relay30  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 3D20E55FFEB48BB224A510A3740C3FE56036404B |
> | 2020-06-20 01:00:00 | relay24  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 40D792754B7B891672288E3705B98C612B002531 |
> | 2020-06-20 01:00:00 | relay27  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 4A14A18B4813930E04F49011D56CDA86D0D33E59 |
> | 2020-06-20 01:00:00 | relay32  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 4FF250A3701CD24523D1B0A9C1FA760FFE9BF5E6 |
> | 2020-06-20 01:00:00 | relay13  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 5C34E92C2F19FA99DB9A680D75C0382E2C91DDE9 |
> | 2020-06-20 01:00:00 | relay25  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 5F1381FA3963CAAF712235CA34D6B15FDDF14966 |
> | 2020-06-20 01:00:00 | relay22  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 7A6014B07509E75172FCF036CC4E9870260470FF |
> | 2020-06-20 01:00:00 | relay07  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 8C28E2857B25C9A92309699416D74AE7AA1A2CCC |
> | 2020-06-20 01:00:00 | relay28  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 8DFCD8E4F626AC933A93AC66847F7C5915824171 |
> | 2020-06-20 01:00:00 | relay06  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 97F3FDE85A765E009F8F94F03970234C05F82F3B |
> | 2020-06-20 01:00:00 | relay29  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | 9D63D167286F731895A2DE06C8BF6D2F549033AD |
> | 2020-06-20 01:00:00 | relay08  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | A9EE8826DF8A4E7BDE76CA9740970415516A307E |
> | 2020-06-20 01:00:00 | relay03  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | AC7FFC636CD734A0FDC22BF811841AE89743FC4F |
> | 2020-06-20 01:00:00 | relay31  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | BEFBEB3E477C77DAA8FB8FA03B6C6ABE71097786 |
> | 2020-06-20 01:00:00 | relay11  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | C00CBEE82D153439F4D1D3CDF8406646BCA2DB7E |
> | 2020-06-20 01:00:00 | relay26  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | C13BF3056344BDD6F486E1A96C89B76671A17C33 |
> | 2020-06-20 01:00:00 | relay10  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | CB78B3066AFFCC9C0DDC9CBBA5642BE162D2CEB9 |
> | 2020-06-20 01:00:00 | relay01  | kleinendorstwiebe AT gmail DOT com |
> Liteserver Holding B.V. | D7188148CF8CBACDF884C5E6615E82AA46DDB320 |
> | 2020-06-20 01:00:00 | relay14  | kleinendorstwiebe AT gmail DOT com |
>

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-19 Thread nusenu 
>>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>>
>>>  There are multiple indicators that suggest that the attacker still
>>> runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>>
>>> And on this one: I trust nusenu who told me we still have massiv
>>> malicious relays.
>>
>> as some of you have probably seen already
>> now a fraction of them got confirmed to run the same attack tools:
>> https://twitter.com/notdan/status/1295813432843829251
>>
>> Unfortunately this is not the end of it.
> 
> Yeah, it never ends. It's an ongoing issue.

Until rules are in place that reduce the risk from this reoccurring on this 
scale and at this rate.

>> What I'm still wondering about is: What made Tor directory authorities 
>> change their policies and stop removing undeclared relay groups?
> 
> I don't think this is the right list to ask directory authorities about
> that. 

It was meant to share my thoughts on this (more than actually expecting an 
answer even though there are actual dir auths on this list).

-- 
https://mastodon.social/@nusenu





signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-19 Thread nusenu 
>>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>>
>>>  There are multiple indicators that suggest that the attacker still
>>> runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>>
>>> And on this one: I trust nusenu who told me we still have massiv
>>> malicious relays.
>>
>> as some of you have probably seen already
>> now a fraction of them got confirmed to run the same attack tools:
>> https://twitter.com/notdan/status/1295813432843829251
>>
>> Unfortunately this is not the end of it.
> 
> Yeah, it never ends. It's an ongoing issue.

Until rules are in place that reduce the risk from this reoccurring on this 
scale and at this rate.

>> What I'm still wondering about is: What made Tor directory authorities 
>> change their policies and stop removing undeclared relay groups?
> 
> I don't think this is the right list to ask directory authorities about
> that. 

I was meant to shared my thoughts on this (more than actually expecting an 
answer even though there are actual dir auths on this list).

-- 
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-19 Thread Georg Koppen 
nusenu:
> niftybunny:
>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>
>>  There are multiple indicators that suggest that the attacker still
>> runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>
>> And on this one: I trust nusenu who told me we still have massiv
>> malicious relays.
> 
> as some of you have probably seen already
> now a fraction of them got confirmed to run the same attack tools:
> https://twitter.com/notdan/status/1295813432843829251
> 
> Unfortunately this is not the end of it.

Yeah, it never ends. It's an ongoing issue.

> Some of them where directly linked in the blog post above.

FWIW: We started the process of kicking all of the relays below out this
morning because we found actual misbehavior.

> What I'm still wondering about is: What made Tor directory authorities change 
> their policies and stop removing undeclared relay groups?

I don't think this is the right list to ask directory authorities about
that. And I don't think there is a policy for that either.

Georg

> +-+--++-+--+
> | first_seen  | nickname | contact| 
> as_name | fingerprint  |
> +-+--++-+--+
> | 2020-06-20 01:00:00 | relay23  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 01C05513D12F63AE9E72588E8EAB459028C44689 |
> | 2020-06-20 01:00:00 | relay05  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 01DAC406BD545B6EB41D3E12476E70EAE4872407 |
> | 2020-06-20 01:00:00 | relay02  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 078A661362B4959F64F8E01DF4646101542E1AD2 |
> | 2020-06-20 01:00:00 | relay17  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 11F76D073C30EE2C8849602B90950659E79EB0B0 |
> | 2020-06-20 01:00:00 | relay21  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 17B63505746D57A2C3F240C63EA0DDE7B7EB73C8 |
> | 2020-06-20 01:00:00 | relay09  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 1970C3CE0F945DA0D16DF5191DC8B0483A421A75 |
> | 2020-06-20 01:00:00 | relay30  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 3D20E55FFEB48BB224A510A3740C3FE56036404B |
> | 2020-06-20 01:00:00 | relay24  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 40D792754B7B891672288E3705B98C612B002531 |
> | 2020-06-20 01:00:00 | relay27  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 4A14A18B4813930E04F49011D56CDA86D0D33E59 |
> | 2020-06-20 01:00:00 | relay32  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 4FF250A3701CD24523D1B0A9C1FA760FFE9BF5E6 |
> | 2020-06-20 01:00:00 | relay13  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 5C34E92C2F19FA99DB9A680D75C0382E2C91DDE9 |
> | 2020-06-20 01:00:00 | relay25  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 5F1381FA3963CAAF712235CA34D6B15FDDF14966 |
> | 2020-06-20 01:00:00 | relay22  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 7A6014B07509E75172FCF036CC4E9870260470FF |
> | 2020-06-20 01:00:00 | relay07  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 8C28E2857B25C9A92309699416D74AE7AA1A2CCC |
> | 2020-06-20 01:00:00 | relay28  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 8DFCD8E4F626AC933A93AC66847F7C5915824171 |
> | 2020-06-20 01:00:00 | relay06  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 97F3FDE85A765E009F8F94F03970234C05F82F3B |
> | 2020-06-20 01:00:00 | relay29  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | 9D63D167286F731895A2DE06C8BF6D2F549033AD |
> | 2020-06-20 01:00:00 | relay08  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | A9EE8826DF8A4E7BDE76CA9740970415516A307E |
> | 2020-06-20 01:00:00 | relay03  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | AC7FFC636CD734A0FDC22BF811841AE89743FC4F |
> | 2020-06-20 01:00:00 | relay31  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | BEFBEB3E477C77DAA8FB8FA03B6C6ABE71097786 |
> | 2020-06-20 01:00:00 | relay11  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | C00CBEE82D153439F4D1D3CDF8406646BCA2DB7E |
> | 2020-06-20 01:00:00 | relay26  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | C13BF3056344BDD6F486E1A96C89B76671A17C33 |
> | 2020-06-20 01:00:00 | relay10  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. | CB78B3066AFFCC9C0DDC9CBBA5642BE162D2CEB9 |
> | 2020-06-20 01:00:00 | relay01  | kleinendorstwiebe AT gmail DOT com | 
> Liteserver Holding B.V. |

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-19 Thread nusenu 
niftybunny:
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>
>  There are multiple indicators that suggest that the attacker still
> runs >10% of the Tor network exit capacity (as of 2020–08–08)
> 
> And on this one: I trust nusenu who told me we still have massiv
> malicious relays.

as some of you have probably seen already
now a fraction of them got confirmed to run the same attack tools:
https://twitter.com/notdan/status/1295813432843829251

Unfortunately this is not the end of it.

Some of them where directly linked in the blog post above.

What I'm still wondering about is: What made Tor directory authorities change 
their policies and stop removing undeclared relay groups?

+-+--++-+--+
| first_seen  | nickname | contact| as_name 
| fingerprint  |
+-+--++-+--+
| 2020-06-20 01:00:00 | relay23  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 01C05513D12F63AE9E72588E8EAB459028C44689 |
| 2020-06-20 01:00:00 | relay05  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 01DAC406BD545B6EB41D3E12476E70EAE4872407 |
| 2020-06-20 01:00:00 | relay02  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 078A661362B4959F64F8E01DF4646101542E1AD2 |
| 2020-06-20 01:00:00 | relay17  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 11F76D073C30EE2C8849602B90950659E79EB0B0 |
| 2020-06-20 01:00:00 | relay21  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 17B63505746D57A2C3F240C63EA0DDE7B7EB73C8 |
| 2020-06-20 01:00:00 | relay09  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 1970C3CE0F945DA0D16DF5191DC8B0483A421A75 |
| 2020-06-20 01:00:00 | relay30  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 3D20E55FFEB48BB224A510A3740C3FE56036404B |
| 2020-06-20 01:00:00 | relay24  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 40D792754B7B891672288E3705B98C612B002531 |
| 2020-06-20 01:00:00 | relay27  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 4A14A18B4813930E04F49011D56CDA86D0D33E59 |
| 2020-06-20 01:00:00 | relay32  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 4FF250A3701CD24523D1B0A9C1FA760FFE9BF5E6 |
| 2020-06-20 01:00:00 | relay13  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 5C34E92C2F19FA99DB9A680D75C0382E2C91DDE9 |
| 2020-06-20 01:00:00 | relay25  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 5F1381FA3963CAAF712235CA34D6B15FDDF14966 |
| 2020-06-20 01:00:00 | relay22  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 7A6014B07509E75172FCF036CC4E9870260470FF |
| 2020-06-20 01:00:00 | relay07  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 8C28E2857B25C9A92309699416D74AE7AA1A2CCC |
| 2020-06-20 01:00:00 | relay28  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 8DFCD8E4F626AC933A93AC66847F7C5915824171 |
| 2020-06-20 01:00:00 | relay06  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 97F3FDE85A765E009F8F94F03970234C05F82F3B |
| 2020-06-20 01:00:00 | relay29  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | 9D63D167286F731895A2DE06C8BF6D2F549033AD |
| 2020-06-20 01:00:00 | relay08  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | A9EE8826DF8A4E7BDE76CA9740970415516A307E |
| 2020-06-20 01:00:00 | relay03  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | AC7FFC636CD734A0FDC22BF811841AE89743FC4F |
| 2020-06-20 01:00:00 | relay31  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | BEFBEB3E477C77DAA8FB8FA03B6C6ABE71097786 |
| 2020-06-20 01:00:00 | relay11  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | C00CBEE82D153439F4D1D3CDF8406646BCA2DB7E |
| 2020-06-20 01:00:00 | relay26  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | C13BF3056344BDD6F486E1A96C89B76671A17C33 |
| 2020-06-20 01:00:00 | relay10  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | CB78B3066AFFCC9C0DDC9CBBA5642BE162D2CEB9 |
| 2020-06-20 01:00:00 | relay01  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | D7188148CF8CBACDF884C5E6615E82AA46DDB320 |
| 2020-06-20 01:00:00 | relay14  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | EF5C9DD6B529FC82D812AC54EA976E14B201652A |
| 2020-06-20 01:00:00 | relay15  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. | F1B3A0B6F45727B9BB0C9E87A7AF4D62A3616F78 |
| 2020-06-20 01:00:00 | relay04  | kleinendorstwiebe AT gmail DOT com | 
Liteserver Holding B.V. |

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-16 Thread William Kane 
I knew about this issue years ago, but there's not much I can do to
mitigate it except for spinning up more, legit Tor exit instances to
try and limit the probability of an attack happening to a user.

We need way more legitimate relays, and not just on OVH, Hetzner and
Online's up streams which are likely already wiretapped due to being
the biggest entities hosting the majority of relays.

Possibly start some campaign to get people to run Tor relays as long
as they match some criteria (not on dynamic lines, not on hosters that
are already crowded with relays, etc.).

I was trying to get my tech-savvy friends to run Tor relays, but most
of them are not interested - the problem with abuse that exit
operators frequently encounter scares most of them off and they just
lose interest in running any kind of relay completely -. sadly, the
public image of Tor is just that bad - blame the media networks for
that..

I don't think monetary incentives would be feasible, but there has to
be something that we can do to get people to smarten up and run more
relays on unpopular hosters.

In the future I'd like to see at least 5 relays of all types, and
out of those, at least 15000 exit relays spread out on many different
up streams / data-centers, ran by legitimate businesses or private
entities, to minimize chances of timing correlation and similar
attacks.

Stuff like sslstrip should be addressed in the client code for the Tor
Browser, and it should be really easy to implement.

2020-08-14 20:48 GMT, Georg Koppen :
> Igor Mitrofanov:
>> Is there anything Tor can do inside the Tor browser itself?
>> I would understand and support something as drastic as disabling
>> non-HTTPS,
>> non-Onion connections altogether. When the user types a URL with no
>> protocol prefix, the browser will assume HTTPS.
>> This may break some websites, so a transition may be required. Such a
>> transition can start with a warning banner, proceed to a warning page,
>> then
>> to a browser setting to enable it, and finally to disabling the
>> capability
>> for good.
>>
>> The above assumes there is much less benefit in running a rogue Tor exit
>> if
>> the operator cannot see or alter the content it is relaying.
>
> I think that assumption is not unreasonable. Yes, we are actively
> thinking about trying an HTTPS-only mode out as part of a defense
> against similar attacks. See the blog post[1] about it which we just
> published, which should give more context for the incident as well.
>
> Georg
>
> [1] https://blog.torproject.org/bad-exit-relays-may-june-2020
>
>> On Fri, Aug 14, 2020 at 1:25 PM niftybunny <
>> abuse-cont...@to-surf-and-protect.net> wrote:
>>
>>>
>>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>>
>>>
>>>- There are multiple indicators that suggest that the attacker still
>>>runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>>
>>>
>>> And on this one: I trust nusenu who told me we still have massiv
>>> malicious
>>> relays.
>>>
>>>
>>>
>>> On 14. Aug 2020, at 19:12, Roger Dingledine  wrote:
>>>
>>> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>>>
>>> This shit has to stop. Why are the relays in question still online?
>>>
>>>
>>> Hm? The relays are not online -- we kicked them in mid June.
>>>
>>> We don't know of any relays right now that are attacking users.
>>>
>>> Or said another way, if anybody knows of relays that are doing any
>>> attacks
>>> on Tor users, ssl stripping or otherwise, please report them. I believe
>>> that we are up to date and have responded to all reports.
>>>
>>> That said, there is definitely the uncertainty of "I wonder if those
>>> OVH relays are attacking users -- they are run by people I don't know,
>>> though there is no evidence that they are." We learned from this case
>>> that making people list and answer an email address didn't slow them
>>> down.
>>>
>>> I still think that long term the answer is that we need to shift the
>>> Tor network toward a group of relay operators that know each other --
>>> transparency, community, relationships, all of those things that are
>>> costly to do but also costly to attack:
>>> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
>>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
>>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>>>
>>> But the short term answer is that nobody to my knowledge has shown us
>>> any current relays that are doing attacks.
>>>
>>> Hope that helps,
>>> --Roger
>>>
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>>
>>> ___
>>> tor-relays mailing list
>>> tor-relays@lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>
>>
>>

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread disrupt_the_flow 
On August 14, 2020 5:12:35 PM UTC, Roger Dingledine  wrote:
>On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>> This shit has to stop. Why are the relays in question still online?
>
>Hm? The relays are not online -- we kicked them in mid June.
>
>We don't know of any relays right now that are attacking users.
>
>Or said another way, if anybody knows of relays that are doing any
>attacks
>on Tor users, ssl stripping or otherwise, please report them. I believe
>that we are up to date and have responded to all reports.
>
>That said, there is definitely the uncertainty of "I wonder if those
>OVH relays are attacking users -- they are run by people I don't know,
>though there is no evidence that they are." We learned from this case
>that making people list and answer an email address didn't slow them
>down.
>
>I still think that long term the answer is that we need to shift the
>Tor network toward a group of relay operators that know each other --
>transparency, community, relationships, all of those things that are
>costly to do but also costly to attack:
>https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
>https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
>https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>
>But the short term answer is that nobody to my knowledge has shown us
>any current relays that are doing attacks.
>
>Hope that helps,
>--Roger
>
>___
>tor-relays mailing list
>tor-relays@lists.torproject.org
>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Roger had Tor Project taken some countermeasures against this type of attack? 
For example quoting from nusenu's article:
> As an immediate countermeasure against this ongoing issue the Tor Project 
> could require physical address verification for all new (joined in 2020) Tor 
> relay operators that run more than 0.5% of the Tor network’s exit or guard 
> capacity. Why 0.5%? It is a balance between the risk of malicious Tor relay 
> capacity and the required effort for verification. Using 0.5% as a threshold 
> is a realistically low number of operators to verify. As of 2020–08–08 there 
> are just five exit and one guard operator that match these criteria (new and 
> big). Some of them have similarities to previously detected malicious groups. 
> Others are somewhat known with a good reputation already. So the amount for 
> this initial verification is limited to sending 6 letters to a provided 
> physical address (more likely actually 3 since some might not request the 
> physical address verification).


pEpkey.asc
Description: application/pgp-keys
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread Georg Koppen 
Igor Mitrofanov:
> Is there anything Tor can do inside the Tor browser itself?
> I would understand and support something as drastic as disabling non-HTTPS,
> non-Onion connections altogether. When the user types a URL with no
> protocol prefix, the browser will assume HTTPS.
> This may break some websites, so a transition may be required. Such a
> transition can start with a warning banner, proceed to a warning page, then
> to a browser setting to enable it, and finally to disabling the capability
> for good.
> 
> The above assumes there is much less benefit in running a rogue Tor exit if
> the operator cannot see or alter the content it is relaying.

I think that assumption is not unreasonable. Yes, we are actively
thinking about trying an HTTPS-only mode out as part of a defense
against similar attacks. See the blog post[1] about it which we just
published, which should give more context for the incident as well.

Georg

[1] https://blog.torproject.org/bad-exit-relays-may-june-2020

> On Fri, Aug 14, 2020 at 1:25 PM niftybunny <
> abuse-cont...@to-surf-and-protect.net> wrote:
> 
>>
>> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>>
>>
>>- There are multiple indicators that suggest that the attacker still
>>runs >10% of the Tor network exit capacity (as of 2020–08–08)
>>
>>
>> And on this one: I trust nusenu who told me we still have massiv malicious
>> relays.
>>
>>
>>
>> On 14. Aug 2020, at 19:12, Roger Dingledine  wrote:
>>
>> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>>
>> This shit has to stop. Why are the relays in question still online?
>>
>>
>> Hm? The relays are not online -- we kicked them in mid June.
>>
>> We don't know of any relays right now that are attacking users.
>>
>> Or said another way, if anybody knows of relays that are doing any attacks
>> on Tor users, ssl stripping or otherwise, please report them. I believe
>> that we are up to date and have responded to all reports.
>>
>> That said, there is definitely the uncertainty of "I wonder if those
>> OVH relays are attacking users -- they are run by people I don't know,
>> though there is no evidence that they are." We learned from this case
>> that making people list and answer an email address didn't slow them down.
>>
>> I still think that long term the answer is that we need to shift the
>> Tor network toward a group of relay operators that know each other --
>> transparency, community, relationships, all of those things that are
>> costly to do but also costly to attack:
>> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
>> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>>
>> But the short term answer is that nobody to my knowledge has shown us
>> any current relays that are doing attacks.
>>
>> Hope that helps,
>> --Roger
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>>
>> ___
>> tor-relays mailing list
>> tor-relays@lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
> 
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
> 




signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread Igor Mitrofanov 
Is there anything Tor can do inside the Tor browser itself?
I would understand and support something as drastic as disabling non-HTTPS,
non-Onion connections altogether. When the user types a URL with no
protocol prefix, the browser will assume HTTPS.
This may break some websites, so a transition may be required. Such a
transition can start with a warning banner, proceed to a warning page, then
to a browser setting to enable it, and finally to disabling the capability
for good.

The above assumes there is much less benefit in running a rogue Tor exit if
the operator cannot see or alter the content it is relaying.

On Fri, Aug 14, 2020 at 1:25 PM niftybunny <
abuse-cont...@to-surf-and-protect.net> wrote:

>
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>
>
>- There are multiple indicators that suggest that the attacker still
>runs >10% of the Tor network exit capacity (as of 2020–08–08)
>
>
> And on this one: I trust nusenu who told me we still have massiv malicious
> relays.
>
>
>
> On 14. Aug 2020, at 19:12, Roger Dingledine  wrote:
>
> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>
> This shit has to stop. Why are the relays in question still online?
>
>
> Hm? The relays are not online -- we kicked them in mid June.
>
> We don't know of any relays right now that are attacking users.
>
> Or said another way, if anybody knows of relays that are doing any attacks
> on Tor users, ssl stripping or otherwise, please report them. I believe
> that we are up to date and have responded to all reports.
>
> That said, there is definitely the uncertainty of "I wonder if those
> OVH relays are attacking users -- they are run by people I don't know,
> though there is no evidence that they are." We learned from this case
> that making people list and answer an email address didn't slow them down.
>
> I still think that long term the answer is that we need to shift the
> Tor network toward a group of relay operators that know each other --
> transparency, community, relationships, all of those things that are
> costly to do but also costly to attack:
> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
>
> But the short term answer is that nobody to my knowledge has shown us
> any current relays that are doing attacks.
>
> Hope that helps,
> --Roger
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread niftybunny 
https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
 


There are multiple indicators that suggest that the attacker still runs >10% of 
the Tor network exit capacity (as of 2020–08–08)

And on this one: I trust nusenu who told me we still have massiv malicious 
relays.



> On 14. Aug 2020, at 19:12, Roger Dingledine  wrote:
> 
> On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
>> This shit has to stop. Why are the relays in question still online?
> 
> Hm? The relays are not online -- we kicked them in mid June.
> 
> We don't know of any relays right now that are attacking users.
> 
> Or said another way, if anybody knows of relays that are doing any attacks
> on Tor users, ssl stripping or otherwise, please report them. I believe
> that we are up to date and have responded to all reports.
> 
> That said, there is definitely the uncertainty of "I wonder if those
> OVH relays are attacking users -- they are run by people I don't know,
> though there is no evidence that they are." We learned from this case
> that making people list and answer an email address didn't slow them down.
> 
> I still think that long term the answer is that we need to shift the
> Tor network toward a group of relay operators that know each other --
> transparency, community, relationships, all of those things that are
> costly to do but also costly to attack:
> https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
> https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html
> 
> But the short term answer is that nobody to my knowledge has shown us
> any current relays that are doing attacks.
> 
> Hope that helps,
> --Roger
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread Roger Dingledine 
On Thu, Aug 13, 2020 at 03:34:55PM +0200, niftybunny wrote:
> This shit has to stop. Why are the relays in question still online?

Hm? The relays are not online -- we kicked them in mid June.

We don't know of any relays right now that are attacking users.

Or said another way, if anybody knows of relays that are doing any attacks
on Tor users, ssl stripping or otherwise, please report them. I believe
that we are up to date and have responded to all reports.

That said, there is definitely the uncertainty of "I wonder if those
OVH relays are attacking users -- they are run by people I don't know,
though there is no evidence that they are." We learned from this case
that making people list and answer an email address didn't slow them down.

I still think that long term the answer is that we need to shift the
Tor network toward a group of relay operators that know each other --
transparency, community, relationships, all of those things that are
costly to do but also costly to attack:
https://gitlab.torproject.org/tpo/metrics/relay-search/-/issues/40001
https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html
https://lists.torproject.org/pipermail/tor-relays/2020-July/018669.html

But the short term answer is that nobody to my knowledge has shown us
any current relays that are doing attacks.

Hope that helps,
--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread Matt Corallo 
This may be true, but I think you underestimate how few sites are on the HSTS preload list or are enforced by SSL 
Everywhere.


Ultimately, unless the first site you load in a browsing session is HTTPS or unless you end up at an HSTS 
preload-enforced site, sslstrip can just keep taking the "s" part out of the link you're about to click. And, as we've 
seen here, even sites that redirect HTTP to HTTPS and various other best practices can fall victim.


To the average user, there is little feedback that the site they're on is properly secured using HSTS preload, and many 
sites forget to enroll themselves in the preload list.


For reference, the first two "probably kinda try to be secure for their users" sites I tried were not on the list: 
wellsfargo.com and bankofamerica.com.


Matt

On 8/13/20 5:19 AM, Michael Gerstacker wrote:


https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac




So in other words when the destination website does not really care about their users safety and the user sends 
unencrypted exit traffic through Tor then an exit relay operator could do the same like your internet provider 
(spying/changing your traffic).

Properly setting MyFamily does not help in this case.

That's nothing new.

The only news is that it is getting exploited big scale now.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-14 Thread niftybunny 
WTF?

Yes, this is nothing new and your ISP could do the same thing if it would be in 
stealing your money and doing crimes. Besides the fact that ISP are not run by 
organised crime as far as I know: This is Tor. I didn't know that our new 
Mission Statement is: Tough shit happens and lets watch how malicious relays 
rob users…

This shit has to stop. Why are the relays in question still online?


> On 13. Aug 2020, at 11:19, Michael Gerstacker 
>  wrote:
> 
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>  
> 
> 
> 
> So in other words when the destination website does not really care about 
> their users safety and the user sends unencrypted exit traffic through Tor 
> then an exit relay operator could do the same like your internet provider 
> (spying/changing your traffic).
> Properly setting MyFamily does not help in this case.
> 
> That's nothing new.
> 
> The only news is that it is getting exploited big scale now.
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-13 Thread Michael Gerstacker 
>
>
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
>
>
So in other words when the destination website does not really care about
their users safety and the user sends unencrypted exit traffic through Tor
then an exit relay operator could do the same like your internet provider
(spying/changing your traffic).
Properly setting MyFamily does not help in this case.

That's nothing new.

The only news is that it is getting exploited big scale now.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-11 Thread niftybunny 
I am trying to be not this rodent … but … guys, thats really really bad … 
someone should verify this shit and start deleting relays ….

nifty



> On 9. Aug 2020, at 06:34, nusenu  wrote:
> 
> Signed PGP part
> Hi,
> 
> here is my motivation for working on automated verification of operatorurls 
> in ContactInfo:
> 
> https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac
> 
> 
> --
> https://mastodon.social/@nusenu
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Blog: How Malicious Tor Relays are Exploiting Users in 2020 (Part I)

2020-08-08 Thread nusenu 
Hi,

here is my motivation for working on automated verification of operatorurls in 
ContactInfo:

https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac


-- 
https://mastodon.social/@nusenu



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays