Improving the robustness of Tor Check

[Robert Hogan]

On Tuesday 11 March 2008 20:35:17 Robert Hogan wrote:
> 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.

I should have added that my reason for suggesting this alternative is that I 
believe it solves the issues you outline in 'Open Issues' and 'Security and 
resiliency implications'. It could also help avoid possible complications 
from DNS poisoning or other crafty stuff when the page displays an image from 
an external source (specified by and known to Tor).

For example, page 2 of the assistant displays an image, a url in an html page 
served by Tor. Either the image is displayed or is not loaded. But it may 
have been displayed by some kind of crafty browser attack that bypassed Tor. 
So after a few minutes a refresh-header in the served page will then reload 
the page, this time with Tor's response on whether it saw and served the 
request for the image or not. This could also be a 'Check With Tor' button 
rather than a refresh-header.




-------------- 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/20080312/7c851094/attachment.pgp>