[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 twim):

 Replying to [comment:10 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?

 Yes, I think I can do that.

 > 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:
 > ...
 >  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).

 Another idea I got here about it is to always reply with 200, so any
 changes to AMP will less likely break things. Thus we can abstract RPC
 away from HTTP in a way and use different pluggable roundtrippers (like
 POST, AMP). It would make it easier to plug other OSSes.
 Also we can't pass headers as we do in meek.

 >     (Side note: if AMP provides a way to pass JSON through unmodified
 (maybe the `r` does this?), that would be ideal.)
 JSON is probably fine if wrapped into <pre> but I haven't test it yet. I
 don't feel like using JSON will be as safe as Base64 in terms of
 survivability against modifications.


 > 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.
 I thought about it too, but it might be a slippery slope as you have to
 ensure that paths never repeat. Random prefix doesn't introduce such a bit
 overhead to worry about.

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