Opened 6 years ago

Closed 6 years ago

#9652 closed enhancement (not a bug)

Treat Pluggable Transports as Individual Bridges

Reported by: sysrqb Owned by:
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Keywords: bridgedb-dist, tor-bridge
Cc: isis, asn, arma, karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Right now we store the pluggable transports that a bridge supports as an attribute of a bridge. This is technically correct, however it also means that all OR ports and PTs are interchangable when we apply different filters. This leads to unnecessary address:port leakage. Two options I see are to

1) Add some kludgey thing to track which properties of a bridges were distributed to a user
2) Pretend that each PT is its own bridge and distribute them individually

Problem: The bridge and its PTs all have the same fingerprint.
Solution: Tweak the hash before we place it in the ring?

Will this screw up or improve any metrics? If we're not careful this will mess up the bridge assignment file, so we should make sure that file doesn't change (serializing each bridge with its ring and its supported PTs).

Child Tickets

Change History (6)

comment:1 Changed 6 years ago by sysrqb

Cc: arma added; armadev removed

oops

comment:2 in reply to:  description ; Changed 6 years ago by asn

I like the idea.

Replying to sysrqb:

Problem: The bridge and its PTs all have the same fingerprint.
Solution: Tweak the hash before we place it in the ring?

Why is it a problem that the bridge and its PTs all have the same fingerprint?

Does that result in the bridge and its PTs being placed in the same section of the hash ring? If yes, I guess that tweaking the hash (by adding some more inputs) makes sense.

comment:3 in reply to:  2 Changed 6 years ago by sysrqb

Replying to asn:

I like the idea.

Great

Replying to sysrqb:

Problem: The bridge and its PTs all have the same fingerprint.
Solution: Tweak the hash before we place it in the ring?

Why is it a problem that the bridge and its PTs all have the same fingerprint?

Does that result in the bridge and its PTs being placed in the same section of the hash ring? If yes, I guess that tweaking the hash (by adding some more inputs) makes sense.

Correcto. If we don't tweak/salt the input, then the Bridge and its PTs will be consecutive. I don't think this is as beneficial.

comment:4 Changed 6 years ago by sysrqb

Some thoughts so I can make progress on this.

Make a bridge's location in the ring is dependent on:
1) its fingerprint and port number (or ip addr and port)
2) a salt and the fingerprint
3) <a better idea>

The ORPort bridge instance must still contain a list of all transports and we will need to ignore all transports when we iterate over the dict when we dump the assignments to file (but this will be easy).

I'm heavily leaning towards 1) with regard to how we distinguish the Bridge instances, until someone tells me this is A Bad Idea. Also, these changes won't be localized, this will require touching many parts of the code but they won't be difficult modifications.

comment:5 in reply to:  4 Changed 6 years ago by asn

Replying to sysrqb:

Some thoughts so I can make progress on this.

Make a bridge's location in the ring is dependent on:
1) its fingerprint and port number (or ip addr and port)
2) a salt and the fingerprint
3) <a better idea>

The ORPort bridge instance must still contain a list of all transports and we will need to ignore all transports when we iterate over the dict when we dump the assignments to file (but this will be easy).

I'm heavily leaning towards 1) with regard to how we distinguish the Bridge instances, until someone tells me this is A Bad Idea. Also, these changes won't be localized, this will require touching many parts of the code but they won't be difficult modifications.

Using the TCP port as a way to separate bridges from their PTs sounds like a fine idea to me. I'm not sure what else should be included in the hash calculation. Doesn't BridgeDB also include a salt of some kind? Maybe it's a good idea to keep it in.

Also, let's keep in mind that we will "soon" want to stop passing out vanilla bridges through BridgeDB, so this change will be even more important then.

comment:6 Changed 6 years ago by isis

Keywords: bridgedb-dist tor-bridge added
Resolution: not a bug
Status: newclosed

Just to make sure I'm interpreting this correctly:

We currently have a hashring for each distributor, then an extra pseudo-hashring for buckets. Each hashring is subdivided into subhashrings according to filters (which would include filters for PT type, IPv4/6, etc.), and/or the client's IP address /24, and/or other parameters. These subhashrings are cached (or at least some number N of them are).

If you get a bridge's fingerprint, you get the bridge's @type bridge-server-descriptor. Even though my local tor client is configured to download extra-info descriptors, I've never been able to get the control port to spit out an @type bridge-extrainfo-document with GETINFO extra-info/digest/* and the extra-info digest from the @type bridge-server-descriptor. tl;dr: Given one PT type IP:port, I don't think you can get the other PT types IP:ports; however, given the fingerprint you can get the main ORPort of the bridge.

We can't really keep that separate without making changes to little-t tor, and probably redesigning large portions of how the ExtORPort functions. I'm not really sure what to do for this ticket, unless I'm misunderstanding something.

Note: See TracTickets for help on using tickets.