... | ... | @@ -6,3 +6,100 @@ |
|
|
* Not taker: arma
|
|
|
* Duration: 1 hour
|
|
|
* Description: In this session we will discuss the tools that keep the tor network safe and the working group capacity.
|
|
|
|
|
|
## Notes taken during the session
|
|
|
|
|
|
### Context for session
|
|
|
|
|
|
- network health team: geko hiro juga, sometimes dgoulet arma gus
|
|
|
|
|
|
- "bad relays" is a specific group in tor (inside the network health team) that scans the network and removes relays that are identified as misbehaving.
|
|
|
|
|
|
- we don't have public meetings specific to bad relays
|
|
|
|
|
|
- not currently part of sponsored work, but in the near future it will be part of a DRL grant
|
|
|
|
|
|
- there are other things the network health team does, like better bandwidth scanners, like checking if the myfamily settings are set correctly
|
|
|
|
|
|
- we are lacking volunteers paying attention to the new relays that join the network
|
|
|
|
|
|
- we have a mailing list and irc channel, both closed.
|
|
|
|
|
|
- goal of session: provide an overview of what tools we have, and who is supposed to be doing what
|
|
|
|
|
|
### Current pain points
|
|
|
|
|
|
- we have a bunch of tools but checking the outputs is a bottleneck
|
|
|
|
|
|
- geko shows a wiki page documenting the current set of tools: a table of tools and maintainers etc.
|
|
|
|
|
|
- bad-relay-reports@ list used for knowledge transfer
|
|
|
|
|
|
- (depictor? do we use that at all or just doctor?)
|
|
|
|
|
|
### History of tools
|
|
|
|
|
|
- used to run dgoulet's v2 hsdir bad-relay catcher on dgoulet's machine
|
|
|
|
|
|
- migrating tools to run on Tor's infrastructure is an ongoing goal and an
|
|
|
ongoing challenge
|
|
|
|
|
|
- watching the output of these tools is also an ongoing challenge
|
|
|
|
|
|
- some of the tools: exitmap, doctor, bermuda, tornetradar, metrics-alerts, chat-with-gus-and-gk
|
|
|
|
|
|
- chat with gus and gk, two parts:
|
|
|
- a questionnaire sent out by gus (is the template public? link to nextcloud.)
|
|
|
- some time on jitsi to talk about questions we and the relay operators might have
|
|
|
- not really aimed at detecting bad relays, more at building community and learning about the people who run relays.
|
|
|
- looking for inconsistencies in what we learn from meeting from them vs external info we can learn.
|
|
|
- can put new relay operators in touch with other resources in their area, e.g. nearby hackerspaces.
|
|
|
|
|
|
### Questions/ideas
|
|
|
|
|
|
- q: meejah developed a network health tool named "tes", to check whether an exit relay is replacing a bitcoin address in an http page. (There is a question of whether bitcoin addresses are the most relevant version of cryptocurrencies these days.)
|
|
|
- a: is checking for replacing a bitcoin address really the right approach? first, there are many cryptocurrencies; second, websites should be using https and that solves the whole class of bitcoin replacement attacks. That is, we should be checking for ssl-stripping and that is a superset of the bitcoin address replacement worry.
|
|
|
|
|
|
- the modified-executable checker: it looks to see if an exe downloaded via each exit relay is unchanged from what it is expected. in reality, we haven't found modified executables these ways. but we *have* discovered exit relays that are appending "bitcoin mining" javascript to every page, and they append it to the exe too and this check triggers.
|
|
|
|
|
|
- q: is our bad-relays work against cryptocurrency people getting easier these days because the bitcoin price has gone down?
|
|
|
|
|
|
- q: false positives on sslstrip / bermuda?
|
|
|
- we can only usefully run these tests on cloudflare and a few other providers, because false positives are too common on less consistent providers.
|
|
|
- distinguishing censorship (by cloudflare or by the network) from mitm (by exit) makes automation harder.
|
|
|
|
|
|
- q: relay churn is an important network health question, and many of the bad-relays tracking scripts will be helpful for tracking relay churn too.
|
|
|
|
|
|
- q: common output format for every tool? put a prometheus exporter in every
|
|
|
tool?
|
|
|
- then we could make a dashboard out of the output from every tool, to display results, send summaries to mailing lists, etc.
|
|
|
- unfortunately, this idea didn't make it into this round of the network-health funding proposal, because it didn't fit in the budget.
|
|
|
- but it is still on the long term wishlist!
|
|
|
|
|
|
- q: do these tools have code that's in common? Opportunities to refactor out into shared or common libraries?
|
|
|
- we have shared helper scripts to write out relay addresses and fingerprints in a format the directory authorities can import directly.
|
|
|
|
|
|
- q: it would be smart to look through the landscape of tools, and look for redundancies:
|
|
|
- e.g. exitmap modules that are obsolete now that we have something more specialized.
|
|
|
- e.g. declaring there are no more bitcoin sites on port 80, so we don't need to worry so much about bitcoin replacement attacks
|
|
|
- e.g. margot might be able to replace some of the tornetradar detectors, to notice clusters of relays that we didn't notice before
|
|
|
|
|
|
- q: tor browser now has https-only mode, so we don't have to pay attention to http as much?
|
|
|
- but, onion browser, brave, etc still produces http-using users.
|
|
|
- action item: we need to push for those browsers to add this feature too.
|
|
|
- action item: bermuda has a feature to use brave's http headers, which we don't regularly use and we should start
|
|
|
- because brave users are more cryptocurrency focused, because of brave's tokens
|
|
|
- (on the one hand, we might say who cares about brave users, because we want to focus on protecting tor browser users. but, if the brave users are there, and the attackers show up to attack them, it becomes a tor network health problem.)
|
|
|
|
|
|
- q: automating notifications from our tools
|
|
|
- bermuda is super useful at finding things, but its output is not yet
|
|
|
automated, so it is a priority
|
|
|
- the main goal here is to increase the usefulness of the reports, i.e.
|
|
|
not have false positives
|
|
|
|
|
|
- q: are there tools that are missing in our landscape?
|
|
|
- margot is a big missing piece, good thing it's on our list
|
|
|
- do we have any measurers for onion services?
|
|
|
- we used to have the v2 hsdir tester, but that is now obsolete
|
|
|
- pastly wrote an ssh scanner, but we don't have the code. but scanning
|
|
|
for ssh fingerprints is a worthwhile checker too. |