Filename: 131-verify-tor-usage.txt Title: Help users to verify they are using Tor Version: $Revision$ Last-Modified: $Date$ Author: Steven J. Murdoch Created: 2008-01-25 Status: Needs-Revision Overview: Websites for checking whether a user is accessing them via Tor are a very helpful aid to configuring web browsers correctly. Existing solutions have both false positives and false negatives when checking if Tor is being used. This proposal will discuss how to modify Tor so as to make testing more reliable. Motivation: Currently deployed websites for detecting Tor use work by comparing the client IP address for a request with a list of known Tor nodes. This approach is generally effective, but suffers from both false positives and false negatives. If a user has a Tor exit node installed, or just happens to have been allocated an IP address previously used by a Tor exit node, any web requests will be incorrectly flagged as coming from Tor. If any customer of an ISP which implements a transparent proxy runs an exit node, all other users of the ISP will be flagged as Tor users. Conversely, if the exit node chosen by a Tor user has not yet been recorded by the Tor checking website, requests will be incorrectly flagged as not coming via Tor. The only reliable way to tell whether Tor is being used or not is for the Tor client to flag this to the browser. 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. Extensions: Identifying proxy server: If needed, other applications between the web browser and Tor (e.g. Polipo and Privoxy) could piggyback on the same mechanism to flag whether they are in use. All three possible web pages should include a machine-readable placeholder, into which another program could insert their own message. For example, the webpage returned by Tor to indicate a successful configuration could include the following HTML:

Connection chain

When the proxy server observes this string, in response to a request for the Tor connectivity check web page, it would prepend it's own message, resulting in the following being returned to the web browser:

Connection chain Checking external connectivity: If Tor intercepts a request, and returns a response itself, the user will not actually confirm whether Tor is able to build a successful circuit. It may then be advantageous to include an image in the web page which is loaded from a different domain. If this is able to be loaded then the user will know that external connectivity through Tor works. Automatic Firefox Notification: All forms of the website should return valid XHTML and have a hidden link with an id attribute "TorCheckResult" and a target property that can be queried to determine the result. For example, a hidden link would convey success like this: failure like this: and DNS leaks like this: Firefox extensions such as Torbutton would then be able to issue an XMLHttpRequest for the page and query the result with resultXML.getElementById("TorCheckResult").target to automatically report the Tor status to the user when they first attempt to enable Tor activity, or whenever they request a check from the extension preferences window. If the check website is to be themed with heavy graphics and/or extensive documentation, the check result itself should be contained in a seperate lightweight iframe that extensions can request via an alternate url. Security and resiliency implications: What attacks are possible? If the IP address used for this feature moves there will be two consequences: - A new website at this IP address will remain inaccessible over Tor - Tor users who are leaking DNS will be informed that Tor is not working, rather than that it is active but leaking DNS We should thus attempt to find an IP address which we reasonably believe can remain static. Open issues: If a Tor version which does not support this extra feature is used, the webpage returned will indicate that Tor is not being used. Can this be safely fixed? Related work: The proposed mechanism is very similar to config.privoxy.org. The most significant difference is that if the web browser is misconfigured, Tor will only get an IP address. Even in this case, Tor should be able to respond with a webpage to notify the user of how to fix the problem. This also implies that Tor must be told of the special IP address, and so must be effectively permanent.