[tor-bugs] #29293 [Obfuscation/Snowflake]: New Design for client -- broker protocol for Snowflake
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Apr 16 03:30:47 UTC 2019
#29293: New Design for client -- broker protocol for Snowflake
----------------------------------------+---------------------------
Reporter: cohosh | Owner: (none)
Type: task | Status: new
Priority: High | Milestone:
Component: Obfuscation/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: snowflake, bridges, broker | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor: Sponsor19
----------------------------------------+---------------------------
Comment (by dcf):
One of the problems with the current client–broker protocol is its use of
HTTP response codes to carry some of the information in the broker's
response.
https://gitweb.torproject.org/pluggable-
transports/snowflake.git/tree/client/lib/rendezvous.go?id=6399ef9d4fa7d1dced903b43f329a43d3a80dfc7#n98
For example, when the client requests /client, the broker returns either a
200 with a response body, an empty 503, or an empty 400. This is awkward
when doing rendezvous over non-HTTP channels, or even over AMP cache,
which doesn't reliably pass through the server's original status code (see
comment:24:ticket:25985). As it is now, if the client is operating in HTTP
mode, it needs to look at the status code; but if it's operating in AMP
cache mode, it needs a separate code path that ignores the status code and
instead looks for the equivalent information somewhere in the response
body.
It would be easier if all the necessary information in the broker's
response were in the HTTP body, because that's easier to port to other
channels.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29293#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list