[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r13955: Promote xxx-verify-tor-usage.txt to proposal 131 (draft) (in tor/trunk/doc/spec/proposals: . ideas)



Author: sjm217
Date: 2008-03-10 14:51:55 -0400 (Mon, 10 Mar 2008)
New Revision: 13955

Added:
   tor/trunk/doc/spec/proposals/131-verify-tor-usage.txt
Removed:
   tor/trunk/doc/spec/proposals/ideas/xxx-verify-tor-usage.txt
Modified:
   tor/trunk/doc/spec/proposals/000-index.txt
Log:
Promote xxx-verify-tor-usage.txt to proposal 131 (draft)

Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt	2008-03-10 16:47:21 UTC (rev 13954)
+++ tor/trunk/doc/spec/proposals/000-index.txt	2008-03-10 18:51:55 UTC (rev 13955)
@@ -53,6 +53,7 @@
 128  Families of private bridges [DRAFT]
 129  Block Insecure Protocols by Default [FINISHED]
 130  Version 2 Tor connection protocol [FINISHED]
+131  Help users to verify they are using Tor [DRAFT]
 
 
 Proposals by status:
@@ -101,3 +102,4 @@
  DRAFT:
    127  Relaying dirport requests to Tor download site / website
    128  Families of private bridges
+   131  Help users to verify they are using Tor

Copied: tor/trunk/doc/spec/proposals/131-verify-tor-usage.txt (from rev 13937, tor/trunk/doc/spec/proposals/ideas/xxx-verify-tor-usage.txt)
===================================================================
--- tor/trunk/doc/spec/proposals/131-verify-tor-usage.txt	                        (rev 0)
+++ tor/trunk/doc/spec/proposals/131-verify-tor-usage.txt	2008-03-10 18:51:55 UTC (rev 13955)
@@ -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: Draft
+
+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.

Deleted: tor/trunk/doc/spec/proposals/ideas/xxx-verify-tor-usage.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-verify-tor-usage.txt	2008-03-10 16:47:21 UTC (rev 13954)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-verify-tor-usage.txt	2008-03-10 18:51:55 UTC (rev 13955)
@@ -1,121 +0,0 @@
-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.