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
--
ââ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev