[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #15517 [BridgeDB]: BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"
#15517: BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"
-------------------------+-------------------------------------------------
Reporter: isis | Owner: isis
Type: defect | Status: new
Priority: | Milestone:
critical | Version:
Component: | Keywords: bridgedb-dist, bridge-enumeration,
BridgeDB | ipv6
Resolution: | Parent ID:
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Comment (by isis):
Replying to [comment:2 arma]:
> How about giving different bridges to the ipv6 users? Mapping both ipv4
and ipv6 users onto the same bridge pool means that whichever strategy the
attacker finds easier to attack is the one that will defeat that pool.
That could work. It would mean another set of rings that we'd have to
fidget with and balance between how much use its getting and how many
bridges it has in it. I'm worried a bit that we already have too many
layers of hashrings, because this is currently resulting in too few obfs4
bridges being spread too thin between too many rings, meaning that
currently sometimes users can't get obfs4 bridges when they ask for them.
For now, I would like to at least stop attackers who own a /48 (like me)
from easily pretending to be 65535 clients and enumerating ''any'' ring
they are in. You're right that with a separate IPv6 ring, at least they
wouldn't be able to enumerate the IPv4 one, but they'd still get the whole
IPv6 one quite easily. Changing it to /32 should make that second problem
a least a bit more expensive/difficult.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15517#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs