Improving the robustness of Tor Check
robert at roberthogan.net
Sat Mar 15 09:23:37 UTC 2008
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
<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">
<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
I'll do up a proper proposal so the pros and cons of what I'm suggesting are
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the tor-dev