This continues to asserts the known version while decoding. The client
will only ever generate the latest version while encoding and if the
response needs to change, the impetus will be a new feature, set in the
deserialized request, which can be used as a distinguisher.
A follow-up wants to pass in a new property from the ClientConfig but it
would be an API breaking change to NewBrokerChannel.
However, it's unclear why NewBrokerChannel is exported at all. No other
package in the repo depends on it and the known users of the library
probably wouldn't be construct them.
While this patch was being reviewed, a new constructor was added,
NewBrokerChannelWithUTLSSettings, with effectively the same issue.
Both of those exported ones are deleted here.
Let's reserve Tor error logs for more severe events that indicate
a client-side bug or absolute failure. By default, tor logs at severity
level notice (and above).
This change adds two new connection failure events for snowflake
proxies. One fires when the datachannel times out and another fires when
the connection to the proxy goes stale.
This should increase the maximum amount of inflight data and hopefully
the performance of Snowflake, especially for clients geographically
distant from proxies and the server.
Makes BrokerChannel abstract over a rendezvousMethod. BrokerChannel
itself is responsible for keepLocalAddresses and the NAT type state, as
well as encoding and decoding client poll messages. rendezvousMethod is
only responsible for delivery of encoded messages.
Formerly, BrokerChannel represented the broker URL and possible domain
fronting as
bc.url *url.URL
bc.Host string
That is, bc.url is the URL of the server which we contact directly, and
bc.Host is the Host header to use in the request. With no domain
fronting, bc.url points directly at the broker itself, and bc.Host is
blank. With domain fronting, we do the following reshuffling:
if front != "" {
bc.Host = bc.url.Host
bc.url.Host = front
}
That is, we alter bc.url to reflect that the server to which we send
requests directly is the CDN, not the broker, and store the broker's own
URL in the HTTP Host header.
The above representation was always confusing to me, because in my
mental model, we are always conceptually communicating with the broker;
but we may optionally be using a CDN proxy in the middle. The new
representation is
bc.url *url.URL
bc.front string
bc.url is the URL of the broker itself, and never changes. bc.front is
the optional CDN front domain, and likewise never changes after
initialization. When domain fronting is in use, we do the swap in the
http.Request struct, not in BrokerChannel itself:
if bc.front != "" {
request.Host = request.URL.Host
request.URL.Host = bc.front
}
Compare to the representation in meek-client:
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=v0.35.0#n94
var options struct {
URL string
Front string
}
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/meek-client.go?h=v0.35.0#n308
if ok { // if front is set
info.Host = info.URL.Host
info.URL.Host = front
}
The tests were using a broker URL of "test.broker" (i.e., a schema-less,
host-less, relative path), and running assertions on the value of
b.url.Path. This is strange, especially in tests regarding domain
fronting, where we care about b.url.Host, not b.url.Path. This commit
changes the broker URL to "http://test.broker" and changes tests to
check b.url.Host. I also added an additional assertion for an empty
b.Host in the non-domain-fronted case.
We used a WaitGroup to prevent a call to Peers.End from melting
snowflakes while a new one is being collected. However, calls to
WaitGroup.Add are in a race with WaitGroup.Wait. To fix this, we use a
Mutex instead.
