A Tor Web Service For Verifying Correct Browser Configuration

[Robert Hogan]

On Saturday 22 March 2008 15:57:57 Nick Mathewson wrote:
> On Sun, Mar 16, 2008 at 08:25:47PM +0000, Robert Hogan wrote:
>
> {For reference, this is now proposal 132.  See
>   
> http://www.torproject.org/svn/trunk/doc/spec/proposals/132-browser-check-to
>r-service.txt }
>
> > Filename: xxx-browser-check-tor-service.txt
> > Title: A Tor Web Service For Verifying Correct Browser Configuration
> > Version: $Revision: 13955 $
> > Last-Modified: $Date: 2008-03-16 18:51:55 +0000 (Sun, 16 Mar 2008) $
> > Author: Robert Hogan
> > Created: 2008-03-08
> > Status: Draft
>
> Hi, Robert!  I'd like to ask about a couple of alternative designs
> that periodically come up for this problem, and ask about security
> implications.
>
> The two main alternative designs are:
>    - Use a remote "am I using Tor" page.
>
>      This handles tests 2 and 3 pretty easily, and with a little
>      effort can be made to do test 1.
>

Here are the pros/cons for remote vs local service:

Remote - Pro:
- Fixes/Upgrades not release dependent.
- Available to all users immediately.

Remote - Con:
- A remote service not accessed through Tor could be manipulated to deceive the 
user into thinking they *are* using Tor. 
- Dependence on external resources.
- Failing the test allows Tor users to expose themselves by accessing 
well-defined resources.

Local - Pro:
- No dependence on external resources. (If test 3 is modified to serve an image 
when a circuit is successfully built, rather than serving an actual external 
resource.)

Local - Con:
- Failing the test allows Tor users to expose themselves by accessing 
well-defined resources.
- Release dependent. Users will be stuck with any implementation flaws until they 
upgrade.
- An additional HTTP service on Tor is an additional attack channel. Assuming 
that the service does not accept HTTP POST, what can an attacker garner from a 
GET? Could an attacker use it to determine if a user is running Tor? Could they 
send malformed URL requests to crash the service and exploit Tor? Perhaps the 
service could be single use - it is enabled by the controller and once it has 
served responses for all defined tests or after a period of time, closes down 
until re-enabled.


>    - Have a controller do it without modifying, or with minimal
>      modifications to, the Tor client.
>
>      Test 3 (net connectivity by Tor) is as easy as looking for
>      whether Tor can build a circuit, I think.  For test 2 (is browser
>      using Tor), just use a MAPADDRESS command to replace a randomly
>      chosen unique ID hostname with (say) torproect.org.  For test 1
>      (is browser using Tor for DNS), send the browser to request a
>      random hostname, and then look in Tor's DNS cache to see whether
>      Tor has a cached entry there.
>

Yes, the controller could create/maintain one or two static, locally stored html 
pages for the user to open. The first one would contain the tests. The second 
would contain the results gathered by the controller. Or maybe an auto-refresh 
http header would serve just as well to serve the test and then the results.

Since a tor http test service is really only going to be useful for controllers, 
maybe this approach is the best overall.  The contents of the page could be 
specified by the tor project. The html page could even be distributed with Tor 
and installed to some specified location for controllers to access. The downside 
with this is that controllers would have to modify some of the page's contents 
for the tests to work properly and copy the page to an alternative location for 
opening.

Alternatively Tor could generate the page on request (with the randomized 
hostnames etc.) at a controller selected location. But this is just passing work 
to Tor unnecessarily I think.

I think it would be important for the page to be distributed or specified by 
Tor - otherwise controller maintainers are just muddling through themselves.


>      [There may be better ways to do these.]
>
> The security implications as near as I can tell are:
>
>     * It adds a way to tell if people are using Tor: when they test an
>       instance of Tor that isn't configured properly, they'll leak
>       pretty identifiable requests to one or two well-known addresses.
>
>     * There are lots of attacks this doesn't solve, particularly
>       browser-based ones.  We could solve this by having a link to a
>       remote "am I using Tor right" page, I guess.
>
>     * It adds another local resource that speaks HTTP; experience
>       suggests that we should think about whether remote pages can use
>       links or javascript to redirect users here in a way that will be
>       useful to an adversary.
>
> None of these seem really terrible to me at the moment, but we should
> analyze them.
>
>
> What do you think?


-------------- 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/20080323/2c9a5ece/attachment.pgp>