Change placeholder bridge addresses to make snowflake and meek work with ReachableAddresses/FascistFirewall

Change the addresses in bridge lines to use port 80 so that tor will consider the bridge lines usable.

A torrc Bridge line requires an IP:port address as part of the syntax. The IP:port address is required, even for transports that are not based on making a single connection to a single endpoint; for that reason, Snowflake and meek use "placeholder" addresses, currently 192.0.2.3:1 and 192.0.2.2:2 respectively. However, this causes a problem with ReachableAddresses/FascistFirewall (i.e. the "This computer goes through a firewall that only allows connections to certain ports" setting). tor doesn't know that these transports do not actually connect to the placeholder addresses; all it sees is that port 1 and port 2 are not on the permitted list, so it considers the bridge unusable (tpo/core/tor#19487 (closed)):

[NOTICE] Bridge at '192.0.2.2:2' isn't reachable by our firewall policy. Asking bridge authority instead.

The anti-censorship team proposes to set the port of placeholder addresses to 80, so that Snowflake and meek will be usable even when ReachableAddresses/FascistFirewall is set.

tpo/anti-censorship/pluggable-transports/snowflake#40159 (comment 2834570)

We currently assign placeholder addresses using the format

192.0.2.t:n

where t indicates the transport (1=flashproxy, 2=meek, 3=snowflake) and n is a counter if there are multiple bridge lines for single transport (currently that doesn't happen, but in the past we had :1 for meek-google, :2 for meek-amazon, :3 for meek-azure; and tpo/anti-censorship/pluggable-transports/snowflake#28651 (closed) will add a second snowflake bridge).

If we switch to a hardcoded port of 80, there will not be separate places to encode t and n. But we could encode them both into one byte, using 4 bits for t and 4 bits for n:

192.0.2.(16(n−1)+t):80

The team discussed this at the 2022-09-08 meeting.

http://meetbot.debian.net/tor-meeting/2022/tor-meeting.2022-09-08-15.58.log.html#l-66

16:26:30 <meskio> "A new format for placeholder addresses in PT bridge lines"
16:26:37 <dcf1> okay, quick note about placeholder addresses
16:27:12 <dcf1> we have been using placeholder addresses with incrementing port numbers :1, :2, :3, etc., because tor requires all PT bridges to have different IP:port, or it gets them confused
16:27:56 <dcf1> this causes a problem when tor is configured with ReachableAddresses or FascistFirewall, because tor thinks the PT is going to try to actually make a TCP connection to those placeholder addresses
16:28:22 <dcf1> and it says "port 1 is not one of the ports permitted by FascistFirewall, therefore I will not attempt this bridge connection"
16:28:35 <dcf1> imo it's a bug in core tor, but it's WONTFIX for years now
16:29:15 <meskio> it might not get fixed until arti
16:29:23 <dcf1> so the proposal is to move this counter into the IP address and always use port 80 for placeholder addresses, to make them more likely to work with ReachableAddresses and FascistFirewall
16:30:49 <dcf1> Way back in flash proxy, which also needed a placeholder address, I tried to make the placeholder look as different from an actual usable IP address as possible, to reduce confusion
16:31:20 <dcf1> since then, the placeholders have been slowly morphing to look more and more like real IP addresses :)
16:31:38 <dcf1> the progression was something like:
16:31:57 <dcf1> 0.0.0.0:0 <- no good, tor uses the all-zero address as a sentinel internally
16:32:09 <dcf1> 0.0.0.1:1 <- no good, 0.0.0.X is used by SOCKS
16:32:35 <dcf1> 0.0.1.0:1 <- we used this for a while, but it ran into problems with 0/8 being considered "internal" by tor
16:32:59 <dcf1> 192.0.2.1:1 <- what we use now, using a special non-routable IP range reserved for documentation
16:33:13 <dcf1> 192.0.2.1:80 <- new proposal
...
16:39:19 <dcf1> okay well I will propose a merge request with the 192.0.2.(16(n−1)+t):80 format, it's good enough for our needs for now