mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
Add candidate proposal xxx-verify-tor-usage
svn:r13937
This commit is contained in:
parent
0df1564298
commit
0c56c7201f
121
doc/spec/proposals/ideas/xxx-verify-tor-usage.txt
Normal file
121
doc/spec/proposals/ideas/xxx-verify-tor-usage.txt
Normal file
@ -0,0 +1,121 @@
|
||||
Filename: xxx-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:
|
||||
<h2>Connection chain</h2>
|
||||
<ul>
|
||||
<li>Tor 0.1.2.14-alpha
|
||||
<!-- 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>Polipo version 1.0.4
|
||||
<!-- 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.
|
||||
|
||||
Security and resiliency implications:
|
||||
|
||||
What attacks are possible?
|
||||
|
||||
If the IP addressed 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
|
||||
belive 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.
|
Loading…
Reference in New Issue
Block a user