[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-relays] improving the badexit flag process
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> I was planning to make an announcement
good news
>> If you are implying that the current process starts with 'let the
>> relay operator handle it', I'd suggest to set the badexit for
>> confirmed bad "properties" *first* (no matter whether they are
>> caused by the relay operator itself or its upstream/ISP) and give
>> the relay operator the chance to request a badexit flag removal
>> upon repair (not the other way around).
>
> Ideally I agree. Trouble is that BadExiting requires manual
> intervention by the directory authority operators, so adding then
> removing flags would each create churn for them.
Yes, directory authority operators shouldn't become the
(responsiveness) bottleneck since they are probably busy doing lots of
other things.
I believe this process should be (semi)automatic for two reason:
- response time is critical
The potential harm done by an malicious exit relay is probably
rising faster then linearly with its (exit flag) uptime. Fast
detection and response can significantly limit an attacker's impact on
tor users.
- lets not add another task to dir auth operators
theoretically one could argue that this isn't something new, but it
would be new if you strive towards a certain response time.
At the end they will always be in charge to manage the badexit flag
process - after all that is what dir auths are responsible for - but
the workload should be kept minimal for dir auth operators.
So there is the goal to reduce the response time in case a badexit
relay is coming up. At the same time we don't want to give a single
bot the ability to trick dir auths into setting badexit flags to many
relays automatically.
I could imagine something like this:
Have 2-3 trusted exit scanners* (run by different trusted parties)
send their gpg signed alerts to a mailing list in a machine readable
format.
Have dir auths fetch these emails.
1) verify gpg signature
discard email without valid signature
2) increase "badness" counter for a given candidate with every
incoming report (one scanner has only one vote per relay)
3) once the badness value reached >=2 set the badexit flag
*automatically*
4) send an email back to the mailing list about that (and optionally
to the operator)
Exits having a badness value > 0 but smaller than 2 should be
investigated and acted upon manually.
Add some rate limiting protection safeguards that would prevent the
dirauts from blacklisting the entire exits in case the scanner's gpg
keys get compromised. (e.g. don't blacklist more than N in a timeframe
of Y).
A negative side effect of this distributed trust design is that exits
will have to be scanned more then once - which is a higher burden on
the network but Philipp's scan design explicitly addresses the
resource issue. If badexits do sampling and perform MITM on every Nth
connection (as seen by Philipp) the likelihood of automatic response
might be quite low, but I would say lets collect some experience.
To further focus the resources to places where they are most useful I
would also envision a scan prioritization that scans new exits more
frequently than exits that have been around for months/years without
issues.
*) theoretically there wouldn't be anything wrong with letting the
dirauths run the scanner themselves - quite the contrary - but it is
more of a resource question I guess.
>> Are there specific trac entries for this?
>
> Nope.
I assume you will create one once your announcement is out of the door.
> Trouble is the manual intervention, and actually in the past bad
> relay reports have often never been acted upon. A particularly bad
> instance of this is what's prompting us to finally fix it.
Do you mind telling us more about the 'particularly bad instance'? (or
where can we find info about that?)
Incidents can also be used to increase the motivation and awareness to
fix issues. If the knowledge about incidents is kept within closed
circles their "positive" side effect will also remain within closed
circles.
>
>> The page states several times "let us know" (even in bold) but
>> there is no information on how you are supposed to contact
>> "them".
>
> Those are email links.
Not in my HTML browser:
[...]
relay then please <strong>let us know</strong>.
[...]
to find out about the email address you would have to go through the
trouble of fetching the wiki page "source":
https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays?format=txt
[...]
relay then please **[mailto:tor-assistants@xxxxxxxxxxxxxxxxxxxx let
us know]**.
[...]
> We plan on making a closed list for bad relay reports. That might
> be a good spot for ExitMap's output too.
I believe the process that limits a (potential) volunteer's ability to
volunteer (getting the badexit flag) should be as open and transparent
as possible. The "blacklist" is also open anyway. By having an open
list you will also likely get more confirm/can't confirm feedback for
a given badexit candidate.
What is the reason for making it a 'behind closed doors' list?
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJTxPwUAAoJEDcK3SCCSvoeDJUP/2qbq4hfERtkHcVXFkBB22Vf
6apAEOeM7RaoNriIte2KWQSKuga5L2A1idSw6WNKLWSd1gs/n2AIf7zK1vLMscul
Pha3Iy+iw7/qsl7aa5KolB2mFCZuTx+4YVOF2om13qo5M5hwAy09z2OZUSu/9ULQ
fLd2ncQQz2QNTC/nVkFp2bPlJ0OHo45p+W0z/ZzVJSwcDEZs0kJrKHpAlSXQ/9W4
b+zFR765K1YeaK6yS3rAR9DQQlk+3S3I5r6tmwu8pb9wUJJGFtpvMewz0JXYMjQk
p0Go/jkK082yqNknFPfJq5AwHXJD/2hf80xD6HQCEvaITnWeauXrk2/GUrZzyxtK
W3Lpl3oOIVJ67AAu8lzIRDFm+UR51I5QmMUIFfhohdOE7+BqFfh0RbBnGFG+/d0I
gdI5tUD9ukhytI9oxECjMLRw3YxAFM4DwU5ZWKLghGjEAgJKYwGjnWQeqPspsP+C
+LPRpvML8+sUUbrVycX8DxhTlJjOA0F9JhF506Uv1KjNcq3xw4IUgVzrNqh0n5xa
5Kn4eQGdKpfRtkxsc90G2TdCaFfcxecYkhHgu7AB6Qpl+NHDgM1l5T+msncWYxUj
KVkQqvsvWbPGY4u2JGkr9LEdNtnstuMZ3meQeE2HtueWB68UiTdAdfTWvViMB5dp
3uSIv47nEfynjtbOrpq2
=cNvH
-----END PGP SIGNATURE-----
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays