[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #8860 [Archived/Flashproxy]: Registration over App Engine
#8860: Registration over App Engine
---------------------------------+------------------------
Reporter: dcf | Owner: dcf
Type: project | Status: closed
Priority: High | Milestone:
Component: Archived/Flashproxy | Version:
Severity: Normal | Resolution: fixed
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
---------------------------------+------------------------
Description changed by dcf:
Old description:
> It apparently is possible to use
> [https://en.wikipedia.org/wiki/Google_App_Engine Google App Engine] apps
> if you can access !https://www.google.com/. We can use this for
> rendezvous.
>
> As an example of doing it manually, you can run
> [https://lists.torproject.org/pipermail/tor-talk/2013-April/027788.html
> flashproxy-reg-url] and paste the URL you get into an existing proxy app
> like https://g-proxy.appspot.com/ or https://bingproxy.appspot.com/, and
> that is sufficient for rendezvous.
>
> One way of doing it automatically with a custom App Engine app is to have
> the app figure out the client's IP address from the request, and insert
> it along with the client's given port number in a new registration to the
> facilitator. (This is pretty much what
> [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a
> :/flashproxy-reg-http flashproxy-reg-http] and
> [https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a:/facilitator/facilitator.cgi#l30
> facilitator.cgi] do now, except it's like having facilitator.cgi run on a
> different host than the facilitator.) The downside of this approach is
> that the IP:port information becomes known to the app and to Google.
> (Though we can't hide the IP anyway, because it's part of the HTTP
> request to the app.)
>
> A better way would be to have the app forward encrypted registration
> blobs, like Gmail does with the [#6383 email rendezvous]. The problem
> here is that the client needs to know its own IP address. I propose
> having the App Engine app interpret requests for `/ip` as a request for
> the requestor's IP address. It should return the IP address as a
> text/plain document in a single line. The other path pattern understood
> by the app will be `/reg/<blob>`, which it will simply forward by making
> a new HTTP request for https://fp-facilitator.org/<blob>.
>
> Two parts to this project:
> 1. App Engine app handling `/ip` and `/reg' as above.
> 2. A client program `flashproxy-reg-appspot`. The client program makes a
> request for `/ip` to find out its IP, then generates a base64 blob from
> the IP and port, the same way `flashproxy-reg-url` does. It then makes a
> second request to `/reg/<blob>` to effect the registration. The App
> Engine app does nothing but a URL fetch of https://fp-
> facilitator.org/reg/<blob>. The client program should have `-4` and `-6`
> options.
New description:
It apparently is possible to use
[https://en.wikipedia.org/wiki/Google_App_Engine Google App Engine] apps
if you can access !https://www.google.com/. We can use this for
rendezvous.
As an example of doing it manually, you can run
[https://lists.torproject.org/pipermail/tor-talk/2013-April/027788.html
flashproxy-reg-url] and paste the URL you get into an existing proxy app
like https://g-proxy.appspot.com/ or https://bingproxy.appspot.com/, and
that is sufficient for rendezvous.
One way of doing it automatically with a custom App Engine app is to have
the app figure out the client's IP address from the request, and insert it
along with the client's given port number in a new registration to the
facilitator. (This is pretty much what
[https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a
:/flashproxy-reg-http flashproxy-reg-http] and
[https://gitweb.torproject.org/flashproxy.git/blob/370a2650d406f3b1b2029f54b174f7e24446b61a:/facilitator/facilitator.cgi#l30
facilitator.cgi] do now, except it's like having facilitator.cgi run on a
different host than the facilitator.) The downside of this approach is
that the IP:port information becomes known to the app and to Google.
(Though we can't hide the IP anyway, because it's part of the HTTP request
to the app.)
A better way would be to have the app forward encrypted registration
blobs, like Gmail does with the [#6383 email rendezvous]. The problem here
is that the client needs to know its own IP address. I propose having the
App Engine app interpret requests for `/ip` as a request for the
requestor's IP address. It should return the IP address as a text/plain
document in a single line. The other path pattern understood by the app
will be `/reg/<blob>`, which it will simply forward by making a new HTTP
request for !https://fp-facilitator.org/<blob>.
Two parts to this project:
1. App Engine app handling `/ip` and `/reg' as above.
2. A client program `flashproxy-reg-appspot`. The client program makes a
request for `/ip` to find out its IP, then generates a base64 blob from
the IP and port, the same way `flashproxy-reg-url` does. It then makes a
second request to `/reg/<blob>` to effect the registration. The App Engine
app does nothing but a URL fetch of !https://fp-
facilitator.org/reg/<blob>. The client program should have `-4` and `-6`
options.
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8860#comment:21>
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