s7r <[email protected]> writes: > Hi, >
Hello, thanks for the feedback! I pushed some small updates to my branch based on your comments. You can check them out here: https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bug12595 > On 8/20/2015 2:28 PM, George Kadianakis wrote: >> 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 >> >> >> > 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. >> > > This number looks good to me. Could you make it dynamic, so in the > future we don't have to change this code? Being optimistic here about > Tor's scale in the future. E.g. calculate: > GUARDS_ATTEMPTED_THRESHOLD == 'total no of Guards in a consensus' * 0.05 > and change update it in our 'State' every time we receive a valid new > consensus document which changes it. Should be slight updates here, > like maybe 78, maybe 82, etc. If the result of the above calculation > is not an even number, approximate with deduction (e.g. if result = > 81,6, set the limit to 81). > I added a comment to make both GUARDS_ATTEMPTED_THRESHOLD and PRIMARY_GUARDS consensus parameters, so that we can change them if we ever understand this problem better. >> 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. >> > > Bad idea for anonymity and also not a very good idea regarding to load > balancing (80/443 Guards might get hammered more). We do have a torrc > option for this, in case the should enable it so Tor will only look > for 80/443 Guards, or use bridges. > I agree. However, most people don't know about the FascistFirewall torrc option. >> - 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? >> >> If we can't find bad attacks here, then maybe we should stop >> worrying about those path bias attacks so much. >> >> For example a threat here with the old guard logic, is that if we >> used this evil gateway just for 10 minutes (in an airport), the >> adversary could launch a path bias attack and force us to connect >> to her guard node. Then even after we left that airport, we would >> still stick to the evil guard node which is bad. >> > > That is why we have some primary guards which we retry for some time, > and not remove them from the list if we cannot connect to them one or > two times. Our network could be down or the Guard's network could be > down, etc. > Based on your comments, I changed the reset timer for primary guards retrying down to 5 minutes. I could also get behind the exponential backoff idea. >> Also, an adversary that manages to own our guard using path bias >> attacks, then has further possibilites for biasing the rest of the >> circuit. What can this adversary do? >> > > Would it make sense for Tor to change Guard if it fails more than n > circuits at a given time? If the attacker owns our guard and wants to > path bias attack the rest of the circuit, since the client is the one > who selects the path, it will cause a lot of circuit failures on > client side - we should use this as a metric to detect this > possibility and defend against it. > Yes maybe. Not sure if the path bias code currently does this. I will consider this as an orthogonal problem for now. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
