diff options
author | Nick Mathewson <nickm@torproject.org> | 2008-03-17 02:52:54 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2008-03-17 02:52:54 +0000 |
commit | 23c355e4eab5765c697447bc9efdbe99110fab5b (patch) | |
tree | a5338de7104f99f5581dc846a1dd8149e1e810a2 /doc | |
parent | 0b941640dfa58df6e0bac530a3532e6350fcea88 (diff) | |
download | tor-23c355e4eab5765c697447bc9efdbe99110fab5b.tar.gz tor-23c355e4eab5765c697447bc9efdbe99110fab5b.zip |
r18859@catbus: nickm | 2008-03-16 22:52:52 -0400
Add proposal 132 from Robert Hogan.
svn:r14061
Diffstat (limited to 'doc')
-rw-r--r-- | doc/spec/proposals/000-index.txt | 2 | ||||
-rw-r--r-- | doc/spec/proposals/132-browser-check-tor-service.txt | 147 |
2 files changed, 149 insertions, 0 deletions
diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index e4010797cf..c2bbf0c509 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -54,6 +54,7 @@ Proposals by number: 129 Block Insecure Protocols by Default [FINISHED] 130 Version 2 Tor connection protocol [FINISHED] 131 Help users to verify they are using Tor [NEEDS-REVISION] +132 A Tor Web Service For Verifying Correct Browser Configuration [DRAFT] Proposals by status: @@ -104,3 +105,4 @@ Proposals by status: DRAFT: 127 Relaying dirport requests to Tor download site / website 128 Families of private bridges + 132 A Tor Web Service For Verifying Correct Browser Configuration diff --git a/doc/spec/proposals/132-browser-check-tor-service.txt b/doc/spec/proposals/132-browser-check-tor-service.txt new file mode 100644 index 0000000000..d07a10dcde --- /dev/null +++ b/doc/spec/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. + |