George Kadianakis: > Hello there, > > recently we've been busy specifying various important improvements to entry > guard security. For instance see proposals 250, 241 and ticket #16861. > > Unfortunately, the current guard codebase is dusty and full of problems (see > #12466, #12450). We believe that refactoring and cleaning up the entry guard > code is essential before we proceed to more advanced security improvements. > > We've been working on new algorithms and data structures for guard nodes as part > of ticket #12595. > > In this mail I include some pseudocode for this new algorithm with the hope that > it will act as a draft for implementing these changes. You can find the pseucode > here: > > https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bug12595 Have you considered how these data structures might change for Prop 247? I like Prop 247, and think it is a significant step in the right direction for the HS-specific problem (though I'd like to think a bit more about how it would compare to a more general virtual circuit mechanism that could also protect clients even for instances of application-specific Guard discovery). More generally, I'm worried in that this is yet another case where upstream deliverables that were written over a year ago are going to cause us to arrive at a sub-optimal solution that we're forced to deploy only to rip out later. Hurray deliverables! In terms of specific suggestions: I find that code conceptually makes more sense when it at least pretends to be object oriented. You might want to consider a single guardset object that holds all of the Guard configuration state, including the main guard list, vanguards, path bias info, etc. This object would then be passed in as the first argument to all guard-related functions, especially if we're talking about overhauling it anyway. All guard-related functions would then be prefixed with guardset_ as well, to make it clear that you could find them in guardset.c. (Also note I deliberately used guardset_ instead of guardlist_ due to Prop 247). > A short description of the algorithm is included on top, and then various > methods and functions are prototyped underneath to make the logic more concrete. > > Apart from the comments and XXXs on the code, here are some more thoughts on > this work: > > - This new design focuses on protecting against path bias attacks, by slightly > damaging our reachability. > > Specifically, the old design is better at recovering in filtered networks, > because it will keep on adding new nodes till one succeeds. In this new > design, we will not try more than 80 relays per time. So if none of them > passes the filtered network, bad luck no Tor. > > While this failure mode should not happen much, it's bad news for users behind > FascistFirewalls which are actually quite frequent. A quick fix here would be > to always add an 80/443 guard on our list, however as it stands only 30% of > the guards are 80/443 guards, so this has bad anonymity consequences. I had mixed feelings about not trying to handle this better in the past, but given that such users can use the default Tor Browser bridges (and likely effectively have to, since bootstrapping takes tens of minutes anyway in this case) it may not be worth micro-optimizing for? > - To improve our algorithm and make it more robust we need to understand further > what kind of path bias attacks are relevant here. The adversary here is a > network adversary (like a gateway) that can block our connections to certain > guards. What nasty attacks can this adversary do? I see this attack vector as adding two capabilities: 1. The adversary can induce you to connect to only its chosen guards to find you later on other networks through fingerprinting (as others have mentioned). 2. The adversary gets to perform attacks that would otherwise be impossible without the Guard node's identity key (which is required in order to unwrap TLS). There are lots of these attacks: XOR-based tagging of the cipherstream to force you to use specific exits, other instances of per-circuit failure, HS circuit fingerprinting, circuit-level traffic analysis, etc. > - In general, I tried to keep the number of heuristics and kludges to the > minimum to keep the logic simple. Unfortunately, it seems that without a > "network down" indicator (#16120) there is no way to avoid edge cases and > false positives here. If you can't find a more reliable OS-specific indicator, you might look at circuit_build_times_network_is_live() and where it is called. I think the channel code also sets indicators in similar places. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev