[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25985 [Obfuscation/Snowflake]: Add AMP cache as another domain fronting option with Google
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs