George Kadianakis transcribed 5.2K bytes:
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.
What if we were to try to use meek as a sort of "are we actually on/offline" check? Or, sometime in the future (say six months or so), when BridgeDB is using meek's domain fronting ideas, [0] we could use the BridgeDB domain front to check if we're actually online (and also, potentially, request a bridge for good measure, in case the network is just filtered).
- Notice that the pseudocode contains no logic about bridges. I'm not sure how bridges should be handled here.
My 2¢: I think the bridge code should be kept separate to the entry guard code.
While it's understandable that we've lumped them together in the past because, functionally, clients would use one or the other, bridges are quite different. Even more so now that bridges will soon be using entry guards. [1] (Also, it makes reviewing the bridge code kind of a pain when it's haphazardly crammed into like ten other modules.)
What if we did something like:
int get_entry_guard(circuit_t) { if (get_options()->UseBridges) { go_do_the_bridgey_thing_in_the_bridge_module() return 0; } if (guard_list.n_guards_attempted_lately > GUARDS_ATTEMPTED_THRESHOLD) { […]
Or check from wherever get_entry_guards() is being called… but perhaps the latter would be more error prone if a programmer forgets to check that they should be using bridges instead (also, code duplication).
[0]: https://bugs.torproject.org/16650 [1]: https://gitweb.torproject.org/user/isis/tor.git/log/?h=bug7144