aboutsummaryrefslogtreecommitdiff
path: root/proposals/132-browser-check-tor-service.txt
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2008-03-17 02:52:54 +0000
committerNick Mathewson <nickm@torproject.org>2008-03-17 02:52:54 +0000
commit3d9f6d3efc0f7f17c75b363a577c9c6bf839e04c (patch)
treeb4fe1bc6cc38c7ae221b3a748e6958ae2b5abbbb /proposals/132-browser-check-tor-service.txt
parent588ad72d72eac7caa382f4b79b2f483eb62adab3 (diff)
downloadtorspec-3d9f6d3efc0f7f17c75b363a577c9c6bf839e04c.tar.gz
torspec-3d9f6d3efc0f7f17c75b363a577c9c6bf839e04c.zip
r18859@catbus: nickm | 2008-03-16 22:52:52 -0400
Add proposal 132 from Robert Hogan. svn:r14061
Diffstat (limited to 'proposals/132-browser-check-tor-service.txt')
-rw-r--r--proposals/132-browser-check-tor-service.txt147
1 files changed, 147 insertions, 0 deletions
diff --git a/proposals/132-browser-check-tor-service.txt b/proposals/132-browser-check-tor-service.txt
new file mode 100644
index 0000000..d07a10d
--- /dev/null
+++ b/proposals/132-browser-check-tor-service.txt
@@ -0,0 +1,147 @@
+Filename: 132-browser-check-tor-service.txt
+Title: A Tor Web Service For Verifying Correct Browser Configuration
+Version: $Revision$
+Last-Modified: $Date$
+Author: Robert Hogan
+Created: 2008-03-08
+Status: Draft
+
+Overview:
+
+ Tor should operate a primitive web service on the loopback network device
+ that tests the operation of user's browser, privacy proxy and Tor client.
+ The tests are performed by serving unique, randomly generated elements in
+ image URLs embedded in static HTML. The images are only displayed if the DNS
+ and HTTP requests for them are routed through Tor, otherwise the 'alt' text
+ may be displayed. The proposal assumes that 'alt' text is not displayed on
+ all browsers so suggests that text and links should accompany each image
+ advising the user on next steps in case the test fails.
+
+ The service is primarily for the use of controllers, since presumably users
+ aren't going to want to edit text files and then type something exotic like
+ 127.0.0.1:9999 into their address bar. In the main use case the controller
+ will have configured the actual port for the webservice so will know where
+ to direct the request. It would also be the responsibility of the controller
+ to ensure the webservice is available, and tor is running, before allowing
+ the user to access the page through their browser.
+
+Motivation:
+
+ This is a complementary approach to proposal 131. It overcomes some of the
+ limitations of the approach described in proposal 131: reliance
+ on a permanent, real IP address and compatibility with older versions of
+ Tor. Unlike 131, it is not as useful to Tor users who are not running a
+ controller.
+
+Objective:
+
+ Provide a reliable means of helping users to determine if their Tor
+ installation, privacy proxy and browser are properly configured for
+ anonymous browsing.
+
+Proposal:
+
+ When configured to do so, Tor should run a basic web service available
+ on a configured port on 127.0.0.1. The purpose of this web service is to
+ serve a number of basic test images that will allow the user to determine
+ if their browser is properly configured and that Tor is working normally.
+
+ The service can consist of a single web page with two columns. The left
+ column contains images, the right column contains advice on what the
+ display/non-display of the column means.
+
+ The rest of this proposal assumes that the service is running on port
+ 9999. The port should be configurable, and configuring the port enables the
+ service. The service must run on 127.0.0.1.
+
+ In all the examples below [uniquesessionid] refers to a random, base64
+ encoded string that is unique to the URL it is contained in. Tor only ever
+ stores the most recently generated [uniquesessionid] for each URL, storing 3
+ in total. Tor should generate a [uniquesessionid] for each of the test URLs
+ below every time a HTTP GET is received at 127.0.0.1:9999 for index.htm.
+
+ The most suitable image for each test case is an implementation decision.
+ Tor will need to store and serve images for the first and second test
+ images, and possibly the third (see 'Open Issues').
+
+ 1. DNS Request Test Image
+
+ This is a HTML element embedded in the page served by Tor at
+ http://127.0.0.1:9999:
+
+ <IMG src="http://[uniquesessionid]:9999/torlogo.jpg" alt="If you can see
+ this text, your browser's DNS requests are not being routed through Tor."
+ width="200" height="200" align="middle" border="2">
+
+ If the browser's DNS request for [uniquesessionid] is routed through Tor,
+ Tor will intercept the request and return 127.0.0.1 as the resolved IP
+ address. This will shortly be followed by a HTTP request from the browser
+ for http://127.0.0.1:9999/torlogo.jpg. This request should be served with
+ the appropriate image.
+
+ If the browser's DNS request for [uniquesessionid] is not routed through Tor
+ the browser may display the 'alt' text specified in the html element. The
+ HTML served by Tor should also contain text accompanying the image to advise
+ users what it means if they do not see an image. It should also provide a
+ link to click that provides information on how to remedy the problem. This
+ behaviour also applies to the images described in 2. and 3. below, so should
+ be assumed there as well.
+
+
+ 2. Proxy Configuration Test Image
+
+ This is a HTML element embedded in the page served by Tor at
+ http://127.0.0.1:9999:
+
+ <IMG src="http://torproject.org/[uniquesessionid].jpg" alt="If you can see
+ this text, your browser is not configured to work with Tor." width="200"
+ height="200" align="middle" border="2">
+
+ If the HTTP request for the resource [uniquesessionid].jpg is received by
+ Tor it will serve the appropriate image in response. It should serve this
+ image itself, without attempting to retrieve anything from the Internet.
+
+ If Tor can identify the name of the proxy application requesting the
+ resource then it could store and serve an image identifying the proxy to the
+ user.
+
+ 3. Tor Connectivity Test Image
+
+ This is a HTML element embedded in the page served by Tor at
+ http://127.0.0.1:9999:
+
+ <IMG src="http://torproject.org/[uniquesessionid]-torlogo.jpg" alt="If you
+ can see this text, your Tor installation cannot connect to the Internet."
+ width="200" height="200" align="middle" border="2">
+
+ The referenced image should actually exist on the Tor project website. If
+ Tor receives the request for the above resource it should remove the random
+ base64 encoded digest from the request (i.e. [uniquesessionid]-) and attempt
+ to retrieve the real image.
+
+ Even on a fully operational Tor client this test may not always succeed. The
+ user should be advised that one or more attempts to retrieve this image may
+ be necessary to confirm a genuine problem.
+
+Open Issues:
+
+ The final connectivity test relies on an externally maintained resource, if
+ this resource becomes unavailable the connectivity test will always fail.
+ Either the text accompanying the test should advise of this possibility or
+ Tor clients should be advised of the location of the test resource in the
+ main network directory listings.
+
+ Any number of misconfigurations may make the web service unreachable, it is
+ the responsibility of the user's controller to recognize these and assist
+ the user in eliminating them. Tor can mitigate against the specific
+ misconfiguration of routing HTTP traffic to 127.0.0.1 to Tor itself by
+ serving such requests through the SOCKS port as well as the configured web
+ service report.
+
+ Now Tor is inspecting the URLs requested on its SOCKS port and 'dropping'
+ them. It already inspects for raw IP addresses (to warn of DNS leaks) but
+ maybe the behaviour proposed here is qualitatively different. Maybe this is
+ an unwelcome precedent that can be used to beat the project over the head in
+ future. Or maybe it's not such a bad thing, Tor is merely attempting to make
+ normally invalid resource requests valid for a given purpose.
+