... | ... | @@ -58,9 +58,10 @@ ongoing challenge |
|
|
### 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.
|
|
|
- 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 this way. 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?
|
|
|
|
... | ... | @@ -103,3 +104,29 @@ not have false positives |
|
|
- 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.
|
|
|
|
|
|
- q: onion services
|
|
|
- rhatto has a new tool onionprobe that tries to test the health of an onion service at every level, and it could be reused to look for attacks.
|
|
|
- (surprise! rhatto is now on the network health team because of this tool. somebody should tell him.)
|
|
|
- sit down with mike and dgoulet and brainstorm onion service questions. map out the attack space for onion services. we are understaffed at tor on onion service clue.
|
|
|
|
|
|
- idea: a dashboard for summarizing and *visualizing* the output, so we can explain the current situation in the network to broader audiences, such as users and funders
|
|
|
|
|
|
- idea: relay functionality tester: fetch descriptors, upload onion descriptors, do begindir fetches -- basically interact with each relay in every way, to verify that it works. this tool would also be useful for assessing arti when it starts having relay functionality.
|
|
|
|
|
|
- pairwise reachability between relays.
|
|
|
- "extendprobe" is a component of bermuda that tries to do this measurement. needs more people playing with it and gaining intuition.
|
|
|
- there's a tension between removing side channels and being able to diagnose anomalies on the network. For example, removing the "reason" byte from destroy cells made it harder to understand *why* relay A isn't able to reach relay B.
|
|
|
- see: https://gitlab.torproject.org/tpo/core/tor/-/issues/40623 and https://gitlab.torproject.org/tpo/core/tor/-/issues/40655
|
|
|
|
|
|
- idea: are there more ways we can be transparent about the bad-relays work? some things need to be secret but not everything does.
|
|
|
- for example, the fact that we have scanners is not secret. but a particular way to distinguish a bad relay is not a thing we should make public.
|
|
|
- we should have a clear algorithm for whether something is public or private -- and make that algorithm public!
|
|
|
|
|
|
- q: how can I as a Tor user be sure that a relay is not malicious?
|
|
|
|
|
|
- a: if they go on metrics portal (relay-search), they can see who are running these relays. the majority are relays that didn't just show up yesterday -- the majority have been running for many years. plus, we are doing these scanners consistently.
|
|
|
- the main reason to be more confident these days is that *we are looking*
|
|
|
- Comparison to trying to assess whether there is corruption in a country: if nobody is looking for corruption, that doesn't mean there is no corruption. The safest situation is if many people are looking, and the corruption is being reported, and you know how much there is.
|
|
|
|
|
|
- idea: we should do some public talks on our bad-relays work, to let people know what we have learned, how it is working and not working. for example, Roger considered submitting a Defcon talk in 2022, and is still considering one in 2023. Another idea is to have a talk on network health and scanning at CCC at end of 2022. |