[tor-bugs] #28651 [Obfuscation/Snowflake]: Prepare all pieces of the snowflake pipeline for a second snowflake bridge

[Tor Bug Tracker & Wiki]

#28651: Prepare all pieces of the snowflake pipeline for a second snowflake bridge
-----------------------------------+------------------------
 Reporter:  arma                   |          Owner:  (none)
     Type:  enhancement            |         Status:  new
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------

Comment (by teor):

 I don't think we need to make any major design changes to snowflake or
 Tor.
 Instead, we can achieve what we want by configuring Tor and snowflake (and
 perhaps adding a small amount of code).

 Replying to [comment:2 dcf]:
 > Another design alternative, requiring changes in core tor: let a bridge
 line describe not just a single bridge fingerprint, but a set of them. The
 client is satisfied if any fingerprint in the set matches. The broker (or
 the proxy) knows the current set of bridges, and randomly selects one
 without any control by the client.

 Tor isn't really built to have more than one fingerprint per bridge.
 Instead, if Tor is configured with multiple bridge lines, it tries to
 connect to all of the bridges, then selects between available bridges at
 random.

 Here's the current design:
 * each client bridge line has a broker, bridge, and (maybe?) STUN server
 * each broker knows its corresponding bridge
 * each proxy is allocated to a broker/bridge

 This design can be gracefully upgraded to:
 * a multi-bridge client, by distributing different bridge lines with
 different brokers, bridges, and (at least 2) different STUN servers
 * a multi-bridge broker, by using a different port on the broker for each
 bridge
 * a multi-broker/bridge proxy, by having the proxy connect to multiple
 brokers, then assign client offers from each broker to the corresponding
 bridge
   * alternately, each proxy can choose a single bridge/broker at random

 > Adding a new bridge to the set would require pushing out new bridge
 lines to users (i.e., making a new Tor Browser release). But if new
 bridges are only needed to increase capacity, that should be a frequent
 enough pace.

 New bridges are also needed if one of the bridges goes down.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28651#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online