[tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google

[Tor Bug Tracker & Wiki]

#25985: Add AMP cache as another domain fronting option with Google
-----------------------------------+------------------------
 Reporter:  twim                   |          Owner:  (none)
     Type:  project                |         Status:  new
 Priority:  Medium                 |      Milestone:
Component:  Obfuscation/Snowflake  |        Version:
 Severity:  Normal                 |     Resolution:
 Keywords:                         |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------

Comment (by dcf):

 I think this AMP cache idea is really viable and can be implemented
 quickly. twim, do you have the time and interest to work on an
 implementation in Snowflake?

 This is the design I am picturing:


 == In the broker ==

 Add a new route `/amp/client`. This is similar to the existing `/client`
 (`clientOffers` function), except that it conforms to AMP requirements.
 Specifically, when a request arrives:
  1. Take the final path component in request URL, decode it using the
 base64 URL-safe alphabet, and store that as `offer`.
  2. If `ctx.snowflakes.Len() <= 0`, return an AMP-appropriate "not found"
 response (in case AMP does not pass our current status 503
 `StatusServiceUnavailable` unmodified).
  3. Keep the same logic up to `answer := <-snowflake.answerChannel`.
  4. When writing the answer, instead of writing it directly to the body,
 encode it using base64 and wrap it in the necessary AMP markup.
     (Side note: if AMP provides a way to pass JSON through unmodified
 (maybe the `r` does this?), that would be ideal.)
  5. In the `<-time.After(time.Second * ClientTimeout)` case, we may have
 to think of some other way to signal a timeout, in case the AMP cache
 doesn't pass the status 502 (`StatusGatewayTimeout`) unmodified.

 We can discuss alternatives paths to `/amp/client`. We could even perhaps
 overload `/client` if something else in the request marks it as being AMP
 (but there's no need to be cute if we don't have to).


 == In the client ==

 Add a new command-line flag `-amp` that sets a global AMP flag. My
 thinking here is that the AMP use case is similar enough to existing
 domain fronting use case that we can use the same conventions. These are
 the use cases I think should be supported:

  access broker directly::
  `client -url https://snowflake-broker.bamsoftware.com/`
  access broker through a domain front::
  `client -url https://snowflake-broker.azureedge.net/ -front
 ajax.aspnetcdn.com`
  access broker via AMP cache::
  `client -amp -url https://snowflake--broker-bamsoftware-
 com.cdn.ampproject.org/`
  access broker via domain-fronted AMP cache::
  `client -amp -url https://snowflake--broker-bamsoftware-
 com.cdn.ampproject.org/ -front www.google.com`

 In `BrokerChannel.Negotiate` (rendezvous.go), when the global AMP flag is
 set,
  1. Instead of appending `"client"` to `bc.url`, append
 `"c/s/<bc.Host>/amp/client/<random>/<base64(data)>"`.
  2. Use GET with an empty body, instead of POST.
  3. In the `http.StatusOK` case, read the body and strip out the AMP
 markup before deserializing the answer.
  4. In the `http.StatusServiceUnavailable` and `http.StatusBadRequest`
 cases, do whatever is needed to match how those errors are represented in
 the broker.

 As a bit of perhaps premature optimization, we can probably remove the
 cache-inhibiting `<random>` from the URLs, because the client offers
 already contain `ice-pwd` and `fingerprint` fields that (I think) don't
 repeat.

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