[tor-bugs] #29207 [Circumvention/Snowflake]: New design for broker -- proxy protocol for snowflakes

[Tor Bug Tracker & Wiki]

#29207: New design for broker -- proxy protocol for snowflakes
-------------------------------------------------+-------------------------
 Reporter:  cohosh                               |          Owner:  cohosh
     Type:  enhancement                          |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:
Component:  Circumvention/Snowflake              |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  snowflake, design, ex-sponsor-19,    |  Actual Points:
  anti-censorship-roadmap                        |
Parent ID:                                       |         Points:  5
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor28-must
-------------------------------------------------+-------------------------

Comment (by cohosh):

 Overall, we want to move to putting all relevant information in the HTTP
 response body and provide `200 OK` responses from the broker for all valid
 interactions. I think it's okay to leave the `400 Bad Request` responses
 alone for requests we catch that definitely deviate from the snowflake
 protocol.

 We want to do this in a backwards compatable way to accomodate proxies
 that have not yet updated. Note that we have control over the broker
 deployment at this time. I propose the following changes:

 ==== Proxy Poll ====
 Updated proxies send

 {{{
 POST [broker URL] HTTP [version]

 {
     version: "1.0",
     sid: [session id]
 }
 }}}
 The broker checks to see if the response body contains a JSON format with
 a version field that specifies version 1.0. If not, revert to old method
 but don't compare the HTTP header with the body (I'm not sure what the
 usefulness of that is).

 The broker then responds with one of two messages:

 - If there are no clients matched the proxy, it sends:
 {{{
  HTTP 200 OK

  {
      status: "no proxies"
  }
 }}}

 For old snowflakes (determined as described above), it sends the old `HTTP
 504 Gateway Timeout` response.

 We might be able to avoid some branching logic and send the new 200
 response to old proxies. I think this is OK to do for backwards
 compatability because the call to `webrtc.Deserialize` will fail and
 [https://github.com/cohosh/snowflake/blob/master/proxy-
 go/snowflake.go#L351 return a null offer] for proxy-go instances and
 browser-based proxies will also
 [https://github.com/cohosh/snowflake/blob/master/proxy/snowflake.js#L112
 fail to received the offer] and continue polling. However, it feels a bit
 risky.

 - If there is a client matched to the proxy, it sends to updated proxies:
 {{{
  HTTP 200 OK
  {
      status: "client match",
      {
          type: offer,
          sdp: [WebRTC SDP]

      }
  }
 }}}
 and the old message to non updated proxies. I'm not sure if the new
 message will work, I have to read more about how the JSON functions in Go
 and node respond to this structure. To receive the offer, the proxy needs
 to be able to find the "type" and "sdp" fields in the JSON object.

 ==== Proxy Answers ====

 Updated proxies send:

 {{{
 POST [broker URL] HTTP[version]

 {
     version: "1.0",
     sid: [session id],
     {
         type: answer,
         sdp: [WebRTC SDP]
     }
 }
 }}}

 The broker then checks the version as above to determine whether it's an
 old or new proxy and uses the provided session ID to match this answer
 with the correct snowflake and provides one of three responses:

 - If the proxy took too long to respond, it sends:
 {{{
  HTTP 200 OK

  {
      status: "client gone"
  }
 }}}
  to updated proxies and `HTTP 410 Gone` to old ones. We ''could'' send the
 new message to old proxies, however old proxies
 [https://github.com/cohosh/snowflake/blob/master/proxy-
 go/snowflake.go#L197 assume the answer was sent to a client] and will wait
 for a data channel to open if they receive a `200 OK` message. We do have
 a timeout built in now since #25688 and #31100 so the token will
 eventually free a slot for more clients.

 - If the body of the POST request was empty or surpassed the read limit,
 it still sends `HTTP 400 Bad Request` to all proxies.

 - If the answer was sent to the client, it sends to all proxies:
 HTTP 200 OK
 {{{
  HTTP 200 OK

  {
      status: "success"
  }
 }}}

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