[tor-dev] [RFC] On new guard algorithms and data structures

[George Kadianakis]

isis <isis at torproject.org> writes:

> 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).
>

Isn't that a bit like using cloudflare as our "online/offline" oracle? For this
reason, I have mixed feelings about this idea.

A related (but terrible) idea would be to have a StatusAuthority, which clients
can connect to when they want to learn if they are online or offline. Still
terribly centralized though, and it also has security implications. 

(FWIW, I generally really like the meek/BridgeDB integration idea.)

>>
>> - 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).
>

Agreed.

I wonder what go_do_the_bridgey_thing_in_the_bridge_module() should be doing.