Improving the robustness of Tor Check

[Robert Hogan]

On Monday 10 March 2008 18:46:52 you wrote:
>
> Proposal:
>
>   A DNS name should be registered and point to an IP address
>   controlled by the Tor project and likely to remain so for the
>   useful lifetime of a Tor client. A web server should be placed
>   at this IP address.
>
>   Tor should be modified to treat requests to port 80, at the
>   specified DNS name or IP address specially. Instead of opening a
>   circuit, it should respond to a HTTP request with a helpful web
>   page:
>
>   - If the request to open a connection was to the domain name, the web
>     page should state that Tor is working properly.
>   - If the request was to the IP address, the web page should state
>     that there is a DNS-leakage vulnerability.
>
>   If the request goes through to the real web server, the page
>   should state that Tor has not been set up properly.

Here's an alternative, maybe it was considered and discounted for a good 
reason, but:

1. Tor runs a primitive 'web service' on localhost:9999 or whatever.
2. The user/controller connects to this service directly through a browser.
3. The service consists of a web page saying 'This is your Tor client'. 'Click 
Next To Test Your Tor'.
4. Then, from an embedded set of frames (or a series of 'next' buttons) your 
browser launches a set of requests served in the html from Tor. This could 
include stuff like :

- A frame (or image link ) that launches a request to 
http://[unqiuesessionid].tor/test.jpg. This frame has a caption stating 
that 'could not resolve domain name' or a blank image means you are leaking 
DNS. If you are not, Tor recognises the sessionid and special url and serves 
a 'DNS OK' page or image in that frame.
- A frame that launches a request to an external domain. Caption something 
like 'if you see a nice picture here your Tor is working, if the image has 
not loaded there's a problem'

Anyway, I hope you get my drift. Given that Tor already *has* a http service I 
imagine this would be pretty straightforward to implement. Given that the 
check page is likely to be used by bundles and controllers almost exclusively 
it should be pretty seamless from a user's point of view.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20080311/02ca3a88/attachment.pgp>