Improving the robustness of Tor Check

[Robert Hogan]

On Friday 14 March 2008 11:21:55 you wrote:
> On Tue, Mar 11, 2008 at 08:35:17PM +0000, Robert Hogan wrote:
> > - 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.
>
> Thanks for the suggestion.
>
> The reason I didn't use this approach is because what happens if the
> browser is not configured to use Tor. A blank image or generic "could
> not resolve domain name" error message is not very helpful. With my
> proposal, a user would be sent to a webpage which explains what went
> wrong and how to fix it.
>

What I had in mind was html along the following lines:

<p>This wizard will test if your browser is correctly configured for using 
Tor.</p>
<p>Take a look at the box below. Does it contain an image of the Tor logo?</p>
<IMG src="http://jfklsfjslkfdsl.tor/torlogo.jpg" alt="If you can see this 
text, please click 'No'" width="200" height="200" align="middle" border="2">
<br>
<INPUT type="button" name="Yes" value="Yes">
<INPUT type="button" name="No" value="No">

Clicking 'No' (as prompted by the alt text if the image is not displayed 
and/or the text above the image) would serve the webpage describing what the 
user needs to do to prevent dns leaking. If the image is properly displayed, 
the user would click Yes and go to a page serving another image that tests 
external connectivity. There's no reason why both these pages couldn't be 
served directly by Tor also.

> There is still one problematic case, which is if the proxy
> configuration is set to the wrong port. Here the user would see a
> generic error message. Maybe there could be some way to combine the
> two approaches, since connections to 127.0.0.1 will bypass proxy
> settings in most cases.
>
> This does mean, however, that if Tor is not running at all, the user
> would get a generic error page. I can't think of a solution which
> fixes both cases in a neat way.

The tor web service I'm suggesting would only be useful for controllers, since 
presumably users aren't going to want to type something exotic like 
127.0.0.1:9999 into their address bar. In this situation the Torbrowser 
bundle or TorK 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.

This would mitigate against both the problems above, but it's probably 
impossible to prevent them ever happening.

I think our use cases may be different enough for both to be worth pursuing 
separately. An internet-based web service that Tor knows about and can use to 
advise users if they're properly configured is good for torbutton users and 
the like who just want something to click when they're asking for help on IRC 
or reading the docs. A tor-based web service would be good for controllers 
since they can make sure it's available and configured before use and can 
avoid the problems associated with relying on an external service outside 
their control. 

I'll do up a proper proposal so the pros and cons of what I'm suggesting are 
clear.

>
> That said, the main scenario I want to prevent is a user thinking
> they're using Tor when they're not. Having their browser unable to
> access any web page is undesirable, but at least they're not going to
> do anything unsafe.
>
> Steven.


-------------- 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/20080315/cc6f2e00/attachment.pgp>