Sebastian G. <bastik.tor>:
> regarding the possible adaptation of Conflux [1] (which I did not read
> previously, because I assumed a misunderstanding* in how Tor works,
> based on a statement in the abstract. Also I was not aware Ian Goldberg
> [~iang]** was involved)
>
> As far as my understanding goes this could hinder website fingerprinting
> [2] in a major way. Using traffic splitting would make looking for
> request patterns harder.
>
> Obviously only if it is applied, which might be not the case since it
> tries to be adaptive and would create a second{ary} circuit only if
> required or requested.
>
> Supposing it is applied does it help to prevent website fingerprinting
> to a high extend? (high extend = being costly to circumvent by adversaries)
This was my estimation, too. Against passive adversaries, it should do
quite well, especially since they should have no information (or at best
incomplete information) about the Conflux path load balancing ratio for
each circuit in the Conflux path, and which bridges are participating in
which Conflux paths.
Against active adversaries, it seems like they may be able to mess with
the Conflux adaptive path load balancing to shift enough traffic onto a
single guard/bridge to get better website traffic fingerprinting
results, or at least to get traffic to flow in a way that lets them
infer or manipulate the ratios.
Still, I think I am in favor of Conflux overall. There are some minor
concerns (such as the need to prevent 2-Conflux from turning into
N-Conflux and allowing individual clients to soak up a lot of network
capacity), but I haven't heard anything that indicates it shouldn't be
deployed.
There will be some potential issues to adapt with what happens in
circuit failure conditions, how to handle adaptive timeouts, and how to
adapt our other path selection improvements and defenses to Conflux, but
I don't think there will be any extreme blockers, there either. We just
need to be careful that the proper and equivalent behaviors are applied
to conflux circuits, too (which may take some reasoning and engineering
time, though).
> ("With the introduction of bridges â unadvertised Tor routers that
> provide Tor access to users within censored regimes like China â
> low-bandwidth Tor routers are becoming more common and essential to
> Torâs ability to resist censorship.")
>
> (The logic appeared flawed to me. Bridge relays are a problem of people
> that use them. Since bridge relays don't take any other position as the
> first hop â for bridge users only â they don't affect the rest of the
> network. Low-bandwidth routers would exist without bridges, unless the
> authorities enforce a certain amount of bandwidth. The commonness of
> low-bandwidth routers in the network does not depend on bridges.
> Low-bandwidth bridges may become more common or are already more common,
> what likely depends on the fact that it's easier to contribute a bridge
> than a relay from home, due to different requirements. Also bridges are
> needed in high quantities since this is part of the censorship evasion,
> which is also why the bridges are there in the first place.)
>
> (Those bridges get more common and are essential to the diversity of the
> user-base Tor has.)
>
> (The quoted sentence still sounds to me as bridges would be the cause of
> Tor's partial slowness.)
The core problem is that bridges are unmeasured and not load balanced.
We currently have not implemented a way to check if a potential bridge
relay is fast enough for the "Fast" relay cutoff, for example, let alone
making sure users are allocated to them in proportion to bandwidth
(which is a much harder problem).
--
Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk