123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148 |
- Filename: 131-verify-tor-usage.txt
- Title: Help users to verify they are using Tor
- 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:
- <h2>Connection chain</h2>
- <ul>
- <li>Tor 0.1.2.14-alpha</li>
- <!-- Tor Connectivity Check: success -->
- </ul>
- 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:
- <h2>Connection chain
- <ul>
- <li>Tor 0.1.2.14-alpha</li>
- <li>Polipo version 1.0.4</li>
- <!-- Tor Connectivity Check: success -->
- </ul>
- 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:
- <a id="TorCheckResult" target="success" href="/"></a>
- failure like this:
- <a id="TorCheckResult" target="failure" href="/"></a>
- and DNS leaks like this:
- <a id="TorCheckResult" target="dnsleak" href="/"></a>
- 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.
|