-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

The relay appears to be down (still hasn't gotten the bad exit flag - who knows if they are going to start it again) but this occurrence rises a few questions in general.

...

It hasn't got the badexit flag yet.

The relay operator wasn't aware of the problem and said he would look into it on Monday.

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).

"Nevertheless, if such attacks seem to be run by an exit relay whereas they are in fact conducted by the network backbone, it is beneficial to all Tor users that this relay is assigned the BadExit flag."

we seem to agree :)

...

How long does it usually take for the dirauth operators to agree on that / deploy?

It can range from one hour to several days. It's clearly not good enough at this point and we are trying to get better at it.

Are there specific trac entries for this?

...

I also had in mind that there was a exit relay scanner (from Mike?) that would decrease response time. Is that still in place or are we depending on volunteers reporting badexits?

All exit relay scanners we are aware of are listed here: https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays

The

page states several times "let us know" (even in bold) but there is no information on how you are supposed to contact "them".

The described method to determine your exit node - by going to check.tpo is not really applicable when you are not able to reach it (ssl warning) and who knows if you are still on the same exit. Without vidalia (which is no longer used by default) it is actually non trivial [1] to find out what your exit relay was. So reporting suspicious behaviour isn't easy for ordinary users.

How long does your scanner take these days for a complete scan?

ok, found it: "makes it possible to scan all exit relays within a matter of only seconds"

That sounds impressive. Looking forward to play with it.

How long does it usually take to detect a newly started badexit?

quote: "we scanned all exit relays several times a week." So I guess less than 2days to detect a new malicious exit?

Did your scanner detect this occurrence (D9B6E8F3) before it has been reported on this mailing list?

Is there already a mailing list for automated scan result alerts? - I haven't found one.

What do you think about creating one where every scanner sends its alerts to? (something similar to the consensus-health ML)

I've got a question regarding your torbutton multi path certificat verification but will ask that elsewhere (doe not really fit to tor-relays).

[1] https://lists.torproject.org/pipermail/tor-dev/2014-July/007115.html

-----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=...

[...] relay then please **[mailto:tor-assistants@lists.torproject.org 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?