Opened 4 years ago

Closed 4 years ago

#15517 closed defect (fixed)

BridgeDB considers IPv6 clients in the same /64 to be "in the same subnet"

Reported by: isis Owned by: isis
Priority: Very High Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-dist, bridge-enumeration, ipv6, bridgedb-0.3.2
Cc: isis, sysrqb Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by isis)

And an IPv6 /48 is rather trivial to obtain. When discussing this in the IRC channel, several people immediately spoke up to say that they have an IPv6 /48 subnet, which is equivalent to 65535 /64s. The current code (from #4297 and this commit) at bridgedb.Dist.uniformMap() would allow anyone with an /48 to pretend to be a maximum of 65535 clients to BridgeDB (which would still allow them to request IPv4 bridges, as well as Pluggable Transport bridges, I might add) and obtain a maximum of 65535 unique positions within a distributor's hashring per period, allowing the bridges within most hashrings to be entirely enumerated within a matter of a few hours.

As for fixing this bug, I planned to use (both for IPv4 and IPv6) whatever logic tor uses for the EnforceDistinctSubnets option. However, as it turns out, there may be a bug in that logic (#15518) with respect to IPv6.

I propose (from talking to people, and glancing at https://en.wikipedia.org/wiki/IPv6_subnetting_reference and https://www.arin.net/resources/request/ipv6_initial_assign.html) that BridgeDB switch to treating IPv6 /32s (the minimum ARIN allocation for an LIR) as distinct subnets, and treat clients within the same /32 as coming from the same IP address.

[This was discovered while working on #4771 and #1839.]

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by isis

Description: modified (diff)
Keywords: ipv6 added

comment:2 Changed 4 years ago by 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.

comment:3 in reply to:  2 ; Changed 4 years ago by isis

Replying to 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.

comment:4 Changed 4 years ago by isis

Keywords: bridgedb-0.3.2 added
Status: newneeds_revision

I've changed this behaviour from the old /64s to /32s in my fix/15522-ipv6-enumeration branch.

I kind of want to merge and deploy it fast, because this ticket it public and I feel that this is serious and may have luckily gone unnoticed thus far.

comment:5 Changed 4 years ago by isis

Status: needs_revisionneeds_review

comment:6 in reply to:  3 Changed 4 years ago by isis

Replying to isis:

Replying to 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.


I forgot to mention that it seems that something of the thing you want was seemingly half-implemented many years ago, and never finished. There are these things called "clusters" in the hashrings of the HTTPS Distributor; these are not present in the Email Distributor. I've attempted to document their structure here.

These "clusters" (besides needing a better name and documentation) could more easily be separated into some for clients coming from IPv4, and some for clients from IPv6. Separating the Tor/proxy users in the same manner is slightly more difficult, because those users have another different, janky, poorly-named, and completely-undocumented structure. (Hooray. And, again, I didn't do it; I've barely touched this code.)

comment:7 in reply to:  4 Changed 4 years ago by isis

Resolution: fixed
Status: needs_reviewclosed

Replying to isis:

I've changed this behaviour from the old /64s to /32s in my fix/15522-ipv6-enumeration branch.

I kind of want to merge and deploy it fast, because this ticket it public and I feel that this is serious and may have luckily gone unnoticed thus far.


Merged for bridgedb-0.3.2.

Note: See TracTickets for help on using tickets.