Re: [tor-dev] please update your MyFamily

[Sec INT]

Think I'm on dev-tor list now - sorry for spamming - all family info should be 
up to date now

regards

Mark B


> On 8 Dec 2016, at 14:07, Sec INT  wrote:
> 
> Should all be correct now 
> 
> regards
> 
> Mark B
> 
> 
>> On 8 Dec 2016, at 11:56, nusenu  wrote:
>> 
>> Dear snaptorg tor operator,
>> 
>> 
>> teor wrote [1]:
>>> TL;DR: we're talking about blacklisting your non-exit relays,
>>> because they don't have MyFamily set correctly.
>>> 
>>> If you'd like help configuring MyFamily correctly, please let us know.
>> 
>> 
>> If you are wondering which relay is misconfigured, the last column
>> (MyFamilyCount) should say at least 7 (or 8 if you plan to recycle your
>> Creanova relay key).
>> 
>> https://atlas.torproject.org/#details/9BFBF1EA78A3FC1A790F7A7789F074338E7F81E3
>> 
>> +-+--+--+---+---+
>> | first_seen  | nickname | exit | guard | MyFamilyCount |
>> +-+--+--+---+---+
>> | 2016-12-03 23:00:00 | SnapTorCAN   |0 | 0 |5. |
>> | 2016-11-28 14:00:00 | SnapExitUS   |1 | 1 |7. |
>> | 2016-11-28 11:00:00 | SnapExitBULG |1 | 0 |7. |
>> | 2016-11-27 00:00:00 | SnapTorBANG  |0 | 0 |8. |
>> | 2016-11-26 23:00:00 | SnapTorSNPR  |0 | 0 |8. |
>> | 2016-11-26 23:00:00 | SnapTorSTRAS |0 | 0 |8. |
>> | 2016-11-12 00:00:00 | SnapTorFr|0 | 0 |8. |
>> +-+--+--+---+---+
>> 
>> 
>> 
>> [1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html
>> 
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?

[nusenu]

> I do not think that this is worthwhile. It establishes a precedent where
> setting your contact info is something that gets you banned, potentially
> incorrectly because it's unauthenticated, whereas we're unable to identify
> people who actually maliciously run several relays without such indicators.

"actually maliciously" somehow implies that openly run groups (all
relays have the same contact info) are certainly not malicious because
they do not try to hide? (set contact info)
While I even assume that this is true for most such operators, it does
not have to be the operator itself as soon as his admin machine gets
compromised.

Since openly run groups are not blacklisted
there is no reason for someone with malicious intents to to even try to
hide.


> If we did this, also why would we blacklist the nonexit relays? That
> seems to not make sense, as a relay operator could have multiple relays
> that act as guard and exit simultaneously.

Exit relays with the guard flag have usually a guard probability of 0%
according to onionoo. Since exit capacity is harder to get I was
suggesting to blacklist the guard-only relays of such groups, so the
exit capacity could still be used while breaking the end-to-end
capabilities (if we can assume onionoo's guard_probability to be correct).

also see:
https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html




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

[tor-dev] blacklisting relays with end-to-end correlation capabilities?

[nusenu]

Dear tor directory authorities,

TLDR: Would you blacklist relays with end-to-end correlation capabilities?

I'm asking to find out whether it makes sense to put any effort into
finding such operators [2]. If most dir auths would not blacklist such
relays than it does not make sense to look for them I guess.

So please let us know whats your opinion on that - thank you.


More information below and there [1]:


The process could look something like this:

- someone identifies such a relay groups (basically based on contactinfo
[2])
- contact the operators asking to fix this (ideally this would be a
@torproject.org sender)
- give them 15 days to fix it
- if not fixed: blacklist respective guard relays
- give them the possibility to get removed from the blacklist once fixed


teor [1]:
> And, of course, it's worth noting that the ContactInfo might be 
> incorrect, so we would have to do this on a case-by-case basis, and 
> convince the directory authority operators it's a sensible thing to
> do.

[1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html
[2] examples:
https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dangerous_relaygroups.txt




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

Re: [tor-dev] please update your MyFamily

[nusenu]

Dear snaptorg tor operator,


teor wrote [1]:
> TL;DR: we're talking about blacklisting your non-exit relays,
> because they don't have MyFamily set correctly.
> 
> If you'd like help configuring MyFamily correctly, please let us know.


If you are wondering which relay is misconfigured, the last column
(MyFamilyCount) should say at least 7 (or 8 if you plan to recycle your
Creanova relay key).

https://atlas.torproject.org/#details/9BFBF1EA78A3FC1A790F7A7789F074338E7F81E3

+-+--+--+---+---+
| first_seen  | nickname | exit | guard | MyFamilyCount |
+-+--+--+---+---+
| 2016-12-03 23:00:00 | SnapTorCAN   |0 | 0 |5. |
| 2016-11-28 14:00:00 | SnapExitUS   |1 | 1 |7. |
| 2016-11-28 11:00:00 | SnapExitBULG |1 | 0 |7. |
| 2016-11-27 00:00:00 | SnapTorBANG  |0 | 0 |8. |
| 2016-11-26 23:00:00 | SnapTorSNPR  |0 | 0 |8. |
| 2016-11-26 23:00:00 | SnapTorSTRAS |0 | 0 |8. |
| 2016-11-12 00:00:00 | SnapTorFr|0 | 0 |8. |
+-+--+--+---+---+



[1] https://lists.torproject.org/pipermail/tor-dev/2016-December/011715.html



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