[or-cvs] r18711: {torvm} Update the design document introduction and clarify some par (torvm/trunk/doc)
coderman at seul.org
coderman at seul.org
Sat Feb 28 05:59:51 UTC 2009
Author: coderman
Date: 2009-02-28 00:59:49 -0500 (Sat, 28 Feb 2009)
New Revision: 18711
Modified:
torvm/trunk/doc/design.html
torvm/trunk/doc/design.xml
Log:
Update the design document introduction and clarify some paragraphs.
Modified: torvm/trunk/doc/design.html
===================================================================
--- torvm/trunk/doc/design.html 2009-02-27 22:02:03 UTC (rev 18710)
+++ torvm/trunk/doc/design.html 2009-02-28 05:59:49 UTC (rev 18711)
@@ -1,22 +1,32 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>A Tor Virtual Machine Design and Implementation</title><meta name="generator" content="DocBook XSL Stylesheets V1.68.1" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="torvmdesign"></a>A Tor Virtual Machine Design and Implementation</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Martin</span> <span class="surname">Peck</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a href="mailto:coderman at gmail dot com">coderman at gmail dot com</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Kyle</span> <span class="surname">Williams</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a href="mailto:kyle.kwilliams at gmail dot com">kyle.kwilliams at gmail dot com</a>></code></p></div></div></div></div><div><p class="copyright">Copyright © 2008 The Tor Project, Inc.</p></div><div><p class="pubdate">September 24, 2008</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2465250">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#transoverview">1.1. Transparent Proxy Overview</a></span></dt><dt><span class="sect2"><a href="#vmoverview">1.2. Virtual Machine Benefits</a></span></dt><dt><span class="sect2"><a href="#multivm">1.3. Application Isolation Virtual Machines</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2456318">2. Tor VM Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="#threatmodel">2.1. Threat Model</a></span></dt><dt><span class="sect2"><a href="#designreqs">2.2. Design Requirements</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2455640">3. Tor VM Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#buildenv">3.1. Build Environment</a></span></dt><dt><span class="sect2"><a href="#vmimpl">3.2. Virtual Machine Software</a></span></dt><dt><span class="sect2"><a href="#patches">3.3. Tor VM Patchset</a></span></dt><dt><span class="sect2"><a href="#vmos">3.4. Tor VM Build</a></span></dt><dt><span class="sect2"><a href="#torcfg">3.5. Tor Configuration</a></span></dt><dt><span class="sect2"><a href="#storage">3.6. Persistent Storage</a></span></dt><dt><span class="sect2"><a href="#vmint">3.7. Host Virtual Machine Integration</a></span></dt><dt><span class="sect2"><a href="#netcfg">3.8. Network Configuration</a></span></dt><dt><span class="sect2"><a href="#ui">3.9. User Interface</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2470003">4. Legal Notice</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2465250"></a>1. Introduction</h2></div></div></div><p>
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>A Tor Virtual Machine Design and Implementation</title><meta name="generator" content="DocBook XSL Stylesheets V1.68.1" /></head><body><div class="article" lang="en" xml:lang="en"><div class="titlepage"><div><div><h1 class="title"><a id="torvmdesign"></a>A Tor Virtual Machine Design and Implementation</h1></div><div><div class="author"><h3 class="author"><span class="firstname">Martin</span> <span class="surname">Peck</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a href="mailto:coderman at gmail dot com">coderman at gmail dot com</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Kyle</span> <span class="surname">Williams</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a href="mailto:kyle.kwilliams at gmail dot com">kyle.kwilliams at gmail dot com</a>></code></p></div></div></div></div><div><p class="copyright">Copyright © 2008-2009 The Tor Project, Inc.</p></div><div><p class="pubdate">February 27, 2009</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2465250">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#privacyintro">1.1. Privacy and Anonymity</a></span></dt><dt><span class="sect2"><a href="#transoverview">1.2. Transparent Proxy Overview</a></span></dt><dt><span class="sect2"><a href="#vmoverview">1.3. Virtual Machine Advantages</a></span></dt><dt><span class="sect2"><a href="#multivm">1.4. Application Isolation and Consistency</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2456359">2. Tor VM Design</a></span></dt><dd><dl><dt><span class="sect2"><a href="#threatmodel">2.1. Threat Model</a></span></dt><dt><span class="sect2"><a href="#designreqs">2.2. Design Requirements</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2455699">3. Tor VM Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#buildenv">3.1. Build Environment</a></span></dt><dt><span class="sect2"><a href="#vmimpl">3.2. Virtual Machine Software</a></span></dt><dt><span class="sect2"><a href="#patches">3.3. Tor VM Patchset</a></span></dt><dt><span class="sect2"><a href="#vmos">3.4. Tor VM Build</a></span></dt><dt><span class="sect2"><a href="#torcfg">3.5. Tor Configuration</a></span></dt><dt><span class="sect2"><a href="#storage">3.6. Persistent Storage</a></span></dt><dt><span class="sect2"><a href="#vmint">3.7. Host Virtual Machine Integration</a></span></dt><dt><span class="sect2"><a href="#netcfg">3.8. Network Configuration</a></span></dt><dt><span class="sect2"><a href="#ui">3.9. User Interface</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id2510275">4. Legal Notice</a></span></dt></dl></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2465250"></a>1. Introduction</h2></div></div></div><p>
This document describes a transparent <span class="trademark">Tor</span>™ proxy design and implementation for
<span class="trademark">Windows</span>® and other operating
systems using a virtual machine platform. An overview of the transparent proxy approach is provided
in addition to design goals and implementation detail.
- </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="transoverview"></a>1.1. Transparent Proxy Overview</h3></div></div></div><p>
+ </p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="privacyintro"></a>1.1. Privacy and Anonymity</h3></div></div></div><p>
+Privacy is the ability to selectively disclose information about yourself and who you share it with.
+ Tor is a privacy enhancing technology designed to provide low latency anonymity on the Internet against an
+ adversary who can generate, modify, or delete traffic, run malicious Tor nodes, and perform other attacks
+ against participants in the network.
+ </p><p>
+Using the nymity slider as reference Tor aims to provide Unlinkable Anonymity for its users. A poor implementation
+ of Tor may expose the user to set reduction attacks eroding privacy to Linkable Anonymity. A more effective
+ attack could further degrade user privacy to Persistent Pseudonymity via a unique identifier, for example. And
+ worst case side channel attacks that reveal origin IP address can void all of the privacy
+ intent of the Tor software. These side channel or catastrophic attacks completely defeat the privacy goals of Tor
+ and indicate a failure of the implementation.
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="transoverview"></a>1.2. Transparent Proxy Overview</h3></div></div></div><p>
A <a href="http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy" target="_top">transparent Tor proxy</a>
- operates at layer3/4 of the OSI model instead of the usual application layer
- like a SOCKS or HTTP proxy. Configuring specific applications to use Tor for
- anonymous TCP and name resolution is no longer required; the transparent proxy intercepts TCP and
- DNS traffic from these programs and routes it through Tor without any explicit application setup.
+ operates at the network and transport layers of of the OSI model instead of the usual application layer
+ like SOCKS or HTTP. Intercepting and routing traffic in this manner avoids the risk of catastrophic side
+ channel attacks that pose the most significant risk to privacy, particularly in a Windows environment.
</p><p>
-There are many benefits to this approach despite some added difficulties, particularly in a
- Windows environment. By transparently routing host traffic through Tor a number of privacy compromising
- side channel attacks are no longer possible. Usability is also improved as users no longer need to
- struggle with SOCKS configuration or proxy wrappers on a per application basis.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="vmoverview"></a>1.2. Virtual Machine Benefits</h3></div></div></div><p>
+Usability is also improved as manual SOCKS or HTTP proxy configuration is no longer necessary in each anonymized
+ application. Software that does not support any kind of proxy feature can also be supported in this manner
+ without any additional effort.
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="vmoverview"></a>1.3. Virtual Machine Advantages</h3></div></div></div><p>
A virtual machine environment can further improve the security position by providing defense in depth against
attacks which rely on using local applications to make requests to Tor that can compromise anonymity. This
benefit is mainly achieved through the use of isolated network stacks in the host and guest OS. Separate
@@ -34,20 +44,34 @@
<a href="http://monkey.org/~provos/libevent/" target="_top">edge triggered IO</a> can significantly improve
the performance of Tor and eliminate
<a href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems" target="_top">socket buffer problems</a>.
- </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="multivm"></a>1.3. Application Isolation Virtual Machines</h3></div></div></div><p>
-
- </p></div><div class="literallayout"><p><br />
-</p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2456318"></a>2. Tor VM Design</h2></div></div></div><p>
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="multivm"></a>1.4. Application Isolation and Consistency</h3></div></div></div><p>
+The use of multiple virtual machines to isolate application instances can protect against linkability of
+ user communications by providing a consistent and trusted initial state for anonymous applications using
+ a static virtual machine image to ensure that any changes made within that isolated environment are not
+ persisted from one runtime instance to the next.
+ </p><p>
+This fixed virtual machine state is critical for using otherwise dangerous software like browser plugins
+ that can write persistent and unique identifying information to hard disk and relay this information to
+ an attacker.
+ </p></div><div class="literallayout"><p><br />
+</p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2456359"></a>2. Tor VM Design</h2></div></div></div><p>
The transparent Tor proxy virtual machine must provide a usable and secure interface to the Tor
- network. A number of design criteria are necessary to achieve this goal.
+ network that preserves the unlinkable anonymity intent of Tor. A number of design criteria are
+ necessary to achieve this goal.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="threatmodel"></a>2.1. Threat Model</h3></div></div></div><p>
-A number of threats are expected when using the Tor network for anonymous exit into the Internet.
- Many of these threats can be mitigated with a robust Tor implementation while other risks cannot
- be discouraged without significant effort and constrained usage.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456347"></a>Attacker Intent</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Identify User Endpoint</strong></span><p>
-The goal of an attacker within this threat model is to obtain the Tor user origin IP address or fingerprint a specific
- Tor user.
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456370"></a>Attacker Capabilities and Methods</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Proxy Bypass</strong></span><p>
+A number of threats are expected when using the Tor network for anonymous communication over the
+ Internet.
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456386"></a>Attacker Intent</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Identify User Endpoint</strong></span><p>
+One goal of the attacker within this threat model is to obtain the Tor user origin IP address.
+ </p></li><li><span><strong class="command">Identify User Verinym</strong></span><p>
+The attacker may desire uniquely identifying user information like name and address stored on the
+ host computer.
+ </p></li><li><span><strong class="command">Reduce Privacy to Persistent Pseudonym</strong></span><p>
+While not as useful as the identifying information above the attacker may wish to uniquely track the individuals
+ using Tor even if their true identities remain unknown.
+ </p></li><li><span><strong class="command">Link Anonymous Communications</strong></span><p>
+The attacker may also attempt to correlate anonymous communications from the same user with each other.
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456449"></a>Attacker Capabilities and Methods</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Proxy Bypass</strong></span><p>
If the attacker can inject some kind of content to invoke a client request that bypasses application proxy
settings they can achieve their goal of determining user endpoint. Social engineering attacks which entice
a user to make a request that may bypass proxy settings are also included in this class of techniques.
@@ -67,16 +91,20 @@
individual they can
<a href="https://torbutton.torproject.org/dev/design/#fingerprinting" target="_top">track individual activity</a>
and likely achieve their goal of identifying user endpoint.
- </p></li><li><span><strong class="command">Linking Attacks</strong></span><p>
-The attacker may use files or application state stored on disk to link separate user instances of Tor use with
- each other. This is a useful method of reducing the anonymity set of the target.
+ </p></li><li><span><strong class="command">Linking Attacks via Persistent State</strong></span><p>
+The attacker may use files or application state stored on disk to link separate instances of Tor use with
+ each other. Note that unique identifiers or configuration associated with applications or operating system
+ components can be used to link communications from the same user if exposed to an attacker.
</p></li><li><span><strong class="command">Fingerprinting Attacks</strong></span><p>
-
+The attacker may obtain as much information as possible about the application and environment it is running
+ in to obtain a set of parameters unique to each pseudonym targeted.
</p></li><li><span><strong class="command">Full Remote Code Execution Attacks</strong></span><p>
-
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456496"></a>Indefensible Attacks</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Tor Attacks</strong></span><p>
-Attacks which Tor cannot defend against, like a global passive adversary, are obviously outside the scope
- of even the most robust Tor implementation.
+Vulnerabilities in applications or configuration may be exploited remotely for arbitrary execution of the
+ attackers code. This will typically grant access to most of the files and configuration on the operating
+ system.
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456579"></a>Indefensible Attacks</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Tor Attacks</strong></span><p>
+Attacks which Tor cannot defend against, like a global passive adversary or traffic confirmation attacks,
+ are obviously outside the scope of even the most robust Tor implementation.
</p></li><li><span><strong class="command">Some Remote Exploit and Arbitrary Execution Attacks</strong></span><p>
Attacks which leverage an application or operating system flaw to gain full remote code execution on the
host system are not defensible. This highlights the need for secure hosts when relying on Tor
@@ -87,8 +115,8 @@
The multiple virtual machine model provides defense in depth against these types of attacks and may constrain the
scope of any compromise to the single virtual machine instance affected by the exploit. It is possible
(though hard to quantify how difficult) to escalate from a compromised guest VM to secondary exploit of the host
- OS, rendering all protections ineffective.
- </p></li><li><span><strong class="command">Correlation Attacks</strong></span><p>
+ OS, again rendering all protections ineffective.
+ </p></li><li><span><strong class="command">Some Correlation Attacks</strong></span><p>
If a Tor user interacts with the same site or service when using Tor and not using Tor it is likely
trivial for an attacker to correlate the anonymous activity with the original user, and thus achieve their
goal of identifying origin endpoint. Users must be aware of the absolute necessity of keeping anonymous
@@ -99,46 +127,28 @@
which is too complicated and restrictive to apply to the entire spectrum
of applications and protocols that may be used over a transparent Tor proxy implementation. For this reason a
"toggle" capability is explicitly not included in the design goals for this implementation.
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2456581"></a>Attacks Difficult to Defend Against Transparently</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Partitioning Attacks</strong></span><p>
-As mentioned above, there is a fundamental trade off between the transparent approach and a constrained single
- application use of Tor with strong state isolation and communication normalization. Scrubbing every byte and filtering
- every potentially misused component of an application protocol is the only way to ensure that partitioning attacks
- are prevented (as much as possible). This entails a significant effort and significantly constrains the capabilities
- of the application. Attempting such an effort for a transparent proxy would require extensive development and testing
- for every application layer protocol that might be encountered, and would still be unable to scrub content inside
- encrypted sessions like SSL.
- </p><p>
-For situations where a user needs additional applications or protocols they are already reducing their
- anonymity set; a correct transparent proxy implementation will prevent all IP disclosure vulnerabilities
- via side channels that would otherwise provide an attacker with vulnerable client endpoint
- addresses using trivial effort.
- </p><p>
-In a Windows environment (and even other operating systems) there are simply too many vectors for proxy bypass
- and DNS side channels to trust most application specific proxy configurations.
- </p><p>
-The implications of this trade off and its practical impact on various types of Tor users needs further study.
- Defending against these types of attacks is outside the scope of this implementation, however, it would be
- useful to encourage use of plugins or other tools that normalize application content on the host OS where
- it is most effective.
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455369"></a>Attacks Difficult to Defend Against Transparently</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Partitioning and Fingerprinting Attacks</strong></span><p>
+While side channel attacks can be thwarted effectively with a robust transparent Tor implementation it is more
+ difficult to protect the content of the communications from partitioning or fingerprinting attacks. The use of
+ TorButton and other such tools is encouraged to provide additional defense against these attacks. Application
+ virtual machines may be difficult to implement for the full spectrum of applications in a way that defeats these
+ attacks.
</p></li><li><span><strong class="command">The Faithless Endpoint</strong></span><p>
-Another difficult problem for transparent proxy configurations is the opportunity for malicious exit nodes to observe
- and manipulate traffic exiting from their router to compromise user privacy and security.
+Another difficult problem for Tor implementations is the opportunity for malicious exit nodes to observe
+ and manipulate traffic from their router to compromise user privacy and security.
<a href="" target="_top">The Faithless Endpoint</a> details a
- number of risks that users may not be aware of. This is another trade off where the risks of side channel attacks
- identifying endpoint location are weighed against other risks introduced by users unaware, unable, or unwilling
- to encrypt their sensitive traffic end to end while using Tor. Sending sensitive private information through a malicious
- exit node can potentially give an attacker all the information necessary to identify the client endpoint IP address.
+ number of risks that users may not be aware of.
</p><p>
Educating the user about these risks in an intuitive manner and providing them tools to prevent unintended exposure to
malicious participants in the Tor network is a complicated effort and outside the scope of this implementation.
</p></li></ul></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="designreqs"></a>2.2. Design Requirements</h3></div></div></div><p>
The risks identified in the threat model above drive a number of design criteria necessary to thwart or
mitigate compromise of user privacy.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="transproxyreqs"></a>Transparent Proxy Requirements</h4></div></div></div><div class="orderedlist"><ol type="1"><li><span><strong class="command">All TCP and DNS Traffic Proxied</strong></span><p>
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="transproxyreqs"></a>Transparent Proxy Requirements</h4></div></div></div><div class="orderedlist"><ol type="1"><li><span><strong class="command">Proxy All TCP and DNS Traffic</strong></span><p>
All TCP and DNS traffic must be routed through the Tor VM without fail. This requires that no local subnets
be exposed on the host network stack once started to prevent the combined local and remote DNS exploits
described above.
- </p></li><li><span><strong class="command">Filter Traffic</strong></span><p>
+ </p></li><li><span><strong class="command">Filter Remaining Traffic</strong></span><p>
Traffic that is not TCP or DNS must be dropped at the Tor VM instance to prevent forwarding potentially
sensitive multicast, ICMP, or other datagrams to the upstream router(s). Likewise certain protocols, like SMTP
and NetBIOS, should be filtered as soon as they leave the host.
@@ -163,11 +173,16 @@
The ability to run multiple VM instances for application runtime isolation and defense in depth against unknown
application or guest operating system vulnerabilities is required. Kernel level VM acceleration is potentially
useful, however, the expanded attack surface presented by such acceleration layers should be considered carefully.
- </p></li></ol></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="hosttransreqs"></a>Host Transport Requirements</h4></div></div></div><div class="orderedlist"><ol type="1"><li><span><strong class="command">IP Routing Through Tor VM</strong></span><p>
+ </p></li></ol></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="hosttransreqs"></a>Host Requirements</h4></div></div></div><div class="orderedlist"><ol type="1"><li><span><strong class="command">IP Routing Through Tor VM</strong></span><p>
All operating systems that are able to run Tor should be able to route traffic in the manner required for
transparent proxy through the virtual machine. Using the combined bridge and tap adapter configuration
there is no need to rely on VPN or DHCP resources for Tor VM functionality; basic IP interface configuration
and IP routing facilities are all that is necessary.
+ </p></li><li><span><strong class="command">Privilege Separation</strong></span><p>
+To obtain the most benefit of a transparent virtual machine implementation host access controls
+ and privilege separation should be used to constrain the capabilities of the implementation and
+ the applications used with it. Newer Windows versions go beyond the typical owner / group based
+ distinction into fine grained access control which may be useful.
</p></li></ol></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="uireqs"></a>User Interface Requirements</h4></div></div></div><div class="orderedlist"><ol type="1"><li><span><strong class="command">Native GUI Controller (Vidalia)</strong></span><p>
Vidalia is an existing feature rich and well known controller for Tor on Windows
and other operating systems that would provide much of the interface desired. This requires that an
@@ -177,13 +192,13 @@
VM kernel but never stored on disk. This would allow control port access without connection behavior changes with the
limitation that any Vidalia restart requires a restart of the VM as well.
</p></li></ol></div></div></div><div class="literallayout"><p><br />
-</p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2455640"></a>3. Tor VM Implementation</h2></div></div></div><p>
+</p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2455699"></a>3. Tor VM Implementation</h2></div></div></div><p>
A solution that satisfies these requirements can be implemented using a variety of GNU/Linux and Win32
software. The open source licenses associated with these tools ensure that adequate scrutiny of the
code base supporting a Tor virtual machine is possible for those who choose to evaluate it.
</p><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="buildenv"></a>3.1. Build Environment</h3></div></div></div><p>
The following dependencies are required for building the Tor VM image and supporting VM tools.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455668"></a>Linux Build Environment</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">OpenWRT Distribution</strong></span><p>
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455726"></a>Linux Build Environment</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">OpenWRT Distribution</strong></span><p>
<a href="http://openwrt.org/" target="_top">OpenWRT</a> provides a full cross compile toolchain and
Linux image build tools including the initramfs with all the usual system and networking tools. Creating a minimal
kernel image with only the functions and linkage needed reduces the compiled bootable image size and helps reduce
@@ -191,7 +206,7 @@
</p><p>
The full toolchain build is configured by default for broad build platform support. Debian based Linux systems are
the best supported build platforms on i386, x86-64, UltraSparc, and PowerPC architectures for the OpenWRT kernel builds.
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455706"></a>Windows Platform and Build Tools</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command"><span class="trademark">Windows XP</span>™</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455765"></a>Windows Platform and Build Tools</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command"><span class="trademark">Windows XP</span>™</strong></span><p>
Windows XP is used to build the Qemu virtual machine with all necessary patches and libraries required for
a portable Tor VM implementation. The build process creates a CDROM ISO image that can be used with a
Windows VM or host to automate the build environment preparation and Qemu compilation.
@@ -216,25 +231,23 @@
direct execution and lack of memory protection between the two operating system instances.
</p><p>
Qemu on the other hand provides full CPU emulation for much stronger host / guest isolation and does not require
- any changes to the guest kernel or ring0 drivers on the host. For these reasons Qemu is preferred for the
+ any changes to the guest kernel or system level drivers on the host. For these reasons Qemu is preferred for the
virtual machine implementation despite the increased CPU and memory overhead associated with full emulation.
</p><p>
Both solutions provide bridged network devices via the WinPcap driver and point-to-point connections using the
- Tap32 adapter. An unknown amount of effort will be needed to make the existing open source WinPcap driver portable.
- The <a href="http://microolap.com/products/network/pssdk/faq/" target="_top">Packet Sniffer SDK</a> libraries
- are a good example of the desired portability requirements for a modified WinPcap implementation.
+ Tap32 adapter.
</p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="patches"></a>3.3. Tor VM Patchset</h3></div></div></div><p>
A number of patches are necessary for the implementation of Tor VM using the tools identified in this document. These
modifications are provided as a series of small patches (patch set) for greater transparency into the modifications
applied with the intent of adoption by upstream maintainers for these projects where appropriate. This will help
reduce the maintenance required for up to date builds of the Tor VM implementation.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469338"></a>Qemu Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">WinPcap Bridge Support</strong></span><p>
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455158"></a>Qemu Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">WinPcap Bridge Support</strong></span><p>
</p><div class="literallayout"><p><code class="function">qemu-winpcap-0.9.1.patch<br />
</code></p></div><p>
</p></li><li><span><strong class="command">Kernel Command Line via STDIN</strong></span><p>
</p><div class="literallayout"><p><code class="function">qemu-kernel-cmdline-from-stdin.patch<br />
</code></p></div><p>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469393"></a>OpenWRT Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Superfluous Code Reduction</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455213"></a>OpenWRT Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Superfluous Code Reduction</strong></span><p>
</p><div class="literallayout"><p><code class="function">kamikaze-mod-basefiles.patch<br />
kamikaze-mod-kernel-config.patch<br />
kamikaze-build-config.patch<br />
@@ -243,17 +256,12 @@
</p><div class="literallayout"><p><code class="function">kamikaze-tor-package.patch<br />
kamikaze-libevent-package.patch<br />
</code></p></div><p>
- </p></li><li><span><strong class="command">Boot and Runtime Modifications</strong></span><p>
-</p><div class="literallayout"><p><code class="function">build/iso/<br />
-</code></p></div><p>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469473"></a>WinPcap Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Portable Driver Layer</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2455270"></a>WinPcap Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Portable Driver Layer</strong></span><p>
</p><div class="literallayout"><p><code class="function">winpcap-tor-device-mods.patch<br />
</code></p></div><p>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469505"></a>OpenVPN TAP-Win32 Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">TAP-Win32 Network Device Driver</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469669"></a>OpenVPN TAP-Win32 Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Portable TAP-Win32 Network Device Driver</strong></span><p>
</p><div class="literallayout"><p><code class="function">openvpn-tor-tap-win32-driver.patch<br />
</code></p></div><p>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469537"></a>Vidalia Patches</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Start and Stop Control of VM</strong></span><p>
- </p></li><li><span><strong class="command">Direct (non-Tor) and Blocked Port Setup</strong></span><p>
</p></li></ul></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="vmos"></a>3.4. Tor VM Build</h3></div></div></div><p>
</p><pre class="programlisting">
# IMPORTANT: You will need about 2G of space for a full build.
@@ -276,10 +284,10 @@
on a persistent data storage facility of some kind that preserves cached network status, saved keys and configuration, and
other critical capabilities. There are a number of ways to configure the virtual disk storage for the VM based
on the role of the node in the network and the environment where it resides.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469644"></a>Virtual Block Device</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Virtual IDE Hard Disk</strong></span><p>
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469774"></a>Virtual Block Device</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Virtual IDE Hard Disk</strong></span><p>
A virtual disk image is provided with the Qemu build that contains an empty XFS file system. This file system is mounted
at boot and used to store persistent Tor configuration and data, in addition to other system state, like /dev/random seed.
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469668"></a>Loop-AES Privacy Extensions</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">GNU Privacy Guard Passphrase Authentication</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469799"></a>Loop-AES Privacy Extensions</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">GNU Privacy Guard Passphrase Authentication</strong></span><p>
</p><div class="literallayout"><p><code class="function"><br />
</code></p></div><p>
</p></li><li><span><strong class="command">Loop-AES Disk Key Generation, Storage, and Authorization</strong></span><p>
@@ -291,7 +299,7 @@
the threats detailed above.
</p><p>
Any effective methods of improving usability should be considered.
- </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469746"></a>Virtual Machine and Application Management</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Tor VM Process Launcher</strong></span><p>
+ </p><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469876"></a>Virtual Machine and Application Management</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Tor VM Process Launcher</strong></span><p>
A portable Tor VM implementation requires a number of driver and network configuration tasks integrated into a
application to manage the TAP-Win32 and WinPcap device driver installation and removal, as well as virtual machine
instance configuration, activation, and monitoring. A parent process to manage these details is provided as a native
@@ -302,11 +310,11 @@
Kernel level virtual machine acceleration is particularly useful for running graphical applications with SVGA
displays and high color depth. The KQemu accelerator can provide a useful performance increase for these graphical
applications.
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469810"></a>Application Window Based Multi-VM Model</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">MingW X Display</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469933"></a>Application Window Based Multi-VM Model</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">MingW X Display</strong></span><p>
</p></li><li><span><strong class="command">Lightweight X Application VMs</strong></span><p>
- </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469851"></a>Windows Application Isolation VM</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Read-Only Guest OS Images</strong></span><p>
+ </p></li></ul></div></div><div class="sect3" lang="en" xml:lang="en"><div class="titlepage"><div><div><h4 class="title"><a id="id2469973"></a>Windows Application Isolation VM</h4></div></div></div><div class="itemizedlist"><ul type="disc"><li><span><strong class="command">Read-Only Guest OS Images</strong></span><p>
</p></li><li><span><strong class="command">Wine Win32 API Implementation</strong></span><p>
@@ -327,7 +335,7 @@
</p></li></ul></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="ui"></a>3.9. User Interface</h3></div></div></div><p>
- </p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2470003"></a>4. Legal Notice</h2></div></div></div><p>
+ </p></div></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2510275"></a>4. Legal Notice</h2></div></div></div><p>
You may distribute or modify this document according to the terms of the <a href="http://www.gnu.org/licenses/fdl-1.2.txt" target="_top">GNU Free Documentation License Version 1.2 or later</a>.
</p><p>
"<span class="trademark">BSD</span>® is a registered trademark of UUnet Technologies, Inc."
Modified: torvm/trunk/doc/design.xml
===================================================================
--- torvm/trunk/doc/design.xml 2009-02-27 22:02:03 UTC (rev 18710)
+++ torvm/trunk/doc/design.xml 2009-02-28 05:59:49 UTC (rev 18711)
@@ -29,9 +29,9 @@
</affiliation>
</author>
- <pubdate>September 24, 2008</pubdate>
+ <pubdate>February 27, 2009</pubdate>
<copyright>
- <year>2008</year>
+ <year>2008-2009</year>
<holder>The Tor Project, Inc.</holder>
</copyright>
</articleinfo>
@@ -46,26 +46,42 @@
in addition to design goals and implementation detail.
</para>
+ <sect2 id="privacyintro">
+ <title>Privacy and Anonymity</title>
+ <para>
+Privacy is the ability to selectively disclose information about yourself and who you share it with.
+ Tor is a privacy enhancing technology designed to provide low latency anonymity on the Internet against an
+ adversary who can generate, modify, or delete traffic, run malicious Tor nodes, and perform other attacks
+ against participants in the network.
+ </para>
+ <para>
+Using the nymity slider as reference Tor aims to provide Unlinkable Anonymity for its users. A poor implementation
+ of Tor may expose the user to set reduction attacks eroding privacy to Linkable Anonymity. A more effective
+ attack could further degrade user privacy to Persistent Pseudonymity via a unique identifier, for example. And
+ worst case side channel attacks that reveal origin IP address can void all of the privacy
+ intent of the Tor software. These side channel or catastrophic attacks completely defeat the privacy goals of Tor
+ and indicate a failure of the implementation.
+ </para>
+ </sect2>
+
<sect2 id="transoverview">
<title>Transparent Proxy Overview</title>
<para>
A <ulink url="http://wiki.noreply.org/noreply/TheOnionRouter/TransparentProxy">transparent Tor proxy</ulink>
- operates at layer3/4 of the OSI model instead of the usual application layer
- like a SOCKS or HTTP proxy. Configuring specific applications to use Tor for
- anonymous TCP and name resolution is no longer required; the transparent proxy intercepts TCP and
- DNS traffic from these programs and routes it through Tor without any explicit application setup.
+ operates at the network and transport layers of of the OSI model instead of the usual application layer
+ like SOCKS or HTTP. Intercepting and routing traffic in this manner avoids the risk of catastrophic side
+ channel attacks that pose the most significant risk to privacy, particularly in a Windows environment.
</para>
<para>
-There are many benefits to this approach despite some added difficulties, particularly in a
- Windows environment. By transparently routing host traffic through Tor a number of privacy compromising
- side channel attacks are no longer possible. Usability is also improved as users no longer need to
- struggle with SOCKS configuration or proxy wrappers on a per application basis.
+Usability is also improved as manual SOCKS or HTTP proxy configuration is no longer necessary in each anonymized
+ application. Software that does not support any kind of proxy feature can also be supported in this manner
+ without any additional effort.
</para>
</sect2>
<sect2 id="vmoverview">
- <title>Virtual Machine Benefits</title>
+ <title>Virtual Machine Advantages</title>
<para>
A virtual machine environment can further improve the security position by providing defense in depth against
attacks which rely on using local applications to make requests to Tor that can compromise anonymity. This
@@ -90,11 +106,18 @@
</sect2>
<sect2 id="multivm">
- <title>Application Isolation Virtual Machines</title>
+ <title>Application Isolation and Consistency</title>
<para>
-<!-- MRP
--->
- </para>
+The use of multiple virtual machines to isolate application instances can protect against linkability of
+ user communications by providing a consistent and trusted initial state for anonymous applications using
+ a static virtual machine image to ensure that any changes made within that isolated environment are not
+ persisted from one runtime instance to the next.
+ </para>
+ <para>
+This fixed virtual machine state is critical for using otherwise dangerous software like browser plugins
+ that can write persistent and unique identifying information to hard disk and relay this information to
+ an attacker.
+ </para>
</sect2>
@@ -108,16 +131,16 @@
<title>Tor VM Design</title>
<para>
The transparent Tor proxy virtual machine must provide a usable and secure interface to the Tor
- network. A number of design criteria are necessary to achieve this goal.
+ network that preserves the unlinkable anonymity intent of Tor. A number of design criteria are
+ necessary to achieve this goal.
</para>
<sect2 id="threatmodel">
<title>Threat Model</title>
<para>
-A number of threats are expected when using the Tor network for anonymous exit into the Internet.
- Many of these threats can be mitigated with a robust Tor implementation while other risks cannot
- be discouraged without significant effort and constrained usage.
+A number of threats are expected when using the Tor network for anonymous communication over the
+ Internet.
</para>
<sect3>
@@ -126,11 +149,30 @@
<listitem><command>Identify User Endpoint</command>
<para>
-The goal of an attacker within this threat model is to obtain the Tor user origin IP address or fingerprint a specific
- Tor user.
+One goal of the attacker within this threat model is to obtain the Tor user origin IP address.
</para>
</listitem>
+ <listitem><command>Identify User Verinym</command>
+ <para>
+The attacker may desire uniquely identifying user information like name and address stored on the
+ host computer.
+ </para>
+ </listitem>
+
+ <listitem><command>Reduce Privacy to Persistent Pseudonym</command>
+ <para>
+While not as useful as the identifying information above the attacker may wish to uniquely track the individuals
+ using Tor even if their true identities remain unknown.
+ </para>
+ </listitem>
+
+ <listitem><command>Link Anonymous Communications</command>
+ <para>
+The attacker may also attempt to correlate anonymous communications from the same user with each other.
+ </para>
+ </listitem>
+
</itemizedlist>
</sect3>
@@ -175,24 +217,26 @@
</para>
</listitem>
- <listitem><command>Linking Attacks</command>
+ <listitem><command>Linking Attacks via Persistent State</command>
<para>
-The attacker may use files or application state stored on disk to link separate user instances of Tor use with
- each other. This is a useful method of reducing the anonymity set of the target.
+The attacker may use files or application state stored on disk to link separate instances of Tor use with
+ each other. Note that unique identifiers or configuration associated with applications or operating system
+ components can be used to link communications from the same user if exposed to an attacker.
</para>
</listitem>
<listitem><command>Fingerprinting Attacks</command>
<para>
-<!-- MRP
--->
+The attacker may obtain as much information as possible about the application and environment it is running
+ in to obtain a set of parameters unique to each pseudonym targeted.
</para>
</listitem>
<listitem><command>Full Remote Code Execution Attacks</command>
<para>
-<!-- MRP
--->
+Vulnerabilities in applications or configuration may be exploited remotely for arbitrary execution of the
+ attackers code. This will typically grant access to most of the files and configuration on the operating
+ system.
</para>
</listitem>
@@ -206,8 +250,8 @@
<listitem><command>Tor Attacks</command>
<para>
-Attacks which Tor cannot defend against, like a global passive adversary, are obviously outside the scope
- of even the most robust Tor implementation.
+Attacks which Tor cannot defend against, like a global passive adversary or traffic confirmation attacks,
+ are obviously outside the scope of even the most robust Tor implementation.
</para>
</listitem>
@@ -223,11 +267,11 @@
The multiple virtual machine model provides defense in depth against these types of attacks and may constrain the
scope of any compromise to the single virtual machine instance affected by the exploit. It is possible
(though hard to quantify how difficult) to escalate from a compromised guest VM to secondary exploit of the host
- OS, rendering all protections ineffective.
+ OS, again rendering all protections ineffective.
</para>
</listitem>
- <listitem><command>Correlation Attacks</command>
+ <listitem><command>Some Correlation Attacks</command>
<para>
If a Tor user interacts with the same site or service when using Tor and not using Tor it is likely
trivial for an attacker to correlate the anonymous activity with the original user, and thus achieve their
@@ -251,43 +295,22 @@
<title>Attacks Difficult to Defend Against Transparently</title>
<itemizedlist>
- <listitem><command>Partitioning Attacks</command>
+ <listitem><command>Partitioning and Fingerprinting Attacks</command>
<para>
-As mentioned above, there is a fundamental trade off between the transparent approach and a constrained single
- application use of Tor with strong state isolation and communication normalization. Scrubbing every byte and filtering
- every potentially misused component of an application protocol is the only way to ensure that partitioning attacks
- are prevented (as much as possible). This entails a significant effort and significantly constrains the capabilities
- of the application. Attempting such an effort for a transparent proxy would require extensive development and testing
- for every application layer protocol that might be encountered, and would still be unable to scrub content inside
- encrypted sessions like SSL.
+While side channel attacks can be thwarted effectively with a robust transparent Tor implementation it is more
+ difficult to protect the content of the communications from partitioning or fingerprinting attacks. The use of
+ TorButton and other such tools is encouraged to provide additional defense against these attacks. Application
+ virtual machines may be difficult to implement for the full spectrum of applications in a way that defeats these
+ attacks.
</para>
- <para>
-For situations where a user needs additional applications or protocols they are already reducing their
- anonymity set; a correct transparent proxy implementation will prevent all IP disclosure vulnerabilities
- via side channels that would otherwise provide an attacker with vulnerable client endpoint
- addresses using trivial effort.
- </para>
- <para>
-In a Windows environment (and even other operating systems) there are simply too many vectors for proxy bypass
- and DNS side channels to trust most application specific proxy configurations.
- </para>
- <para>
-The implications of this trade off and its practical impact on various types of Tor users needs further study.
- Defending against these types of attacks is outside the scope of this implementation, however, it would be
- useful to encourage use of plugins or other tools that normalize application content on the host OS where
- it is most effective.
- </para>
</listitem>
<listitem><command>The Faithless Endpoint</command>
<para>
-Another difficult problem for transparent proxy configurations is the opportunity for malicious exit nodes to observe
- and manipulate traffic exiting from their router to compromise user privacy and security.
+Another difficult problem for Tor implementations is the opportunity for malicious exit nodes to observe
+ and manipulate traffic from their router to compromise user privacy and security.
<ulink href="http://www.cosic.esat.kuleuven.be/publications/article-896.pdf">The Faithless Endpoint</ulink> details a
- number of risks that users may not be aware of. This is another trade off where the risks of side channel attacks
- identifying endpoint location are weighed against other risks introduced by users unaware, unable, or unwilling
- to encrypt their sensitive traffic end to end while using Tor. Sending sensitive private information through a malicious
- exit node can potentially give an attacker all the information necessary to identify the client endpoint IP address.
+ number of risks that users may not be aware of.
</para>
<para>
Educating the user about these risks in an intuitive manner and providing them tools to prevent unintended exposure to
@@ -313,7 +336,7 @@
<title>Transparent Proxy Requirements</title>
<orderedlist>
- <listitem><command>All TCP and DNS Traffic Proxied</command>
+ <listitem><command>Proxy All TCP and DNS Traffic</command>
<para>
All TCP and DNS traffic must be routed through the Tor VM without fail. This requires that no local subnets
be exposed on the host network stack once started to prevent the combined local and remote DNS exploits
@@ -321,7 +344,7 @@
</para>
</listitem>
- <listitem><command>Filter Traffic</command>
+ <listitem><command>Filter Remaining Traffic</command>
<para>
Traffic that is not TCP or DNS must be dropped at the Tor VM instance to prevent forwarding potentially
sensitive multicast, ICMP, or other datagrams to the upstream router(s). Likewise certain protocols, like SMTP
@@ -382,7 +405,7 @@
</sect3>
<sect3 id="hosttransreqs">
- <title>Host Transport Requirements</title>
+ <title>Host Requirements</title>
<orderedlist>
<listitem><command>IP Routing Through Tor VM</command>
@@ -394,6 +417,15 @@
</para>
</listitem>
+ <listitem><command>Privilege Separation</command>
+ <para>
+To obtain the most benefit of a transparent virtual machine implementation host access controls
+ and privilege separation should be used to constrain the capabilities of the implementation and
+ the applications used with it. Newer Windows versions go beyond the typical owner / group based
+ distinction into fine grained access control which may be useful.
+ </para>
+ </listitem>
+
</orderedlist>
</sect3>
@@ -517,14 +549,12 @@
</para>
<para>
Qemu on the other hand provides full CPU emulation for much stronger host / guest isolation and does not require
- any changes to the guest kernel or ring0 drivers on the host. For these reasons Qemu is preferred for the
+ any changes to the guest kernel or system level drivers on the host. For these reasons Qemu is preferred for the
virtual machine implementation despite the increased CPU and memory overhead associated with full emulation.
</para>
<para>
Both solutions provide bridged network devices via the WinPcap driver and point-to-point connections using the
- Tap32 adapter. An unknown amount of effort will be needed to make the existing open source WinPcap driver portable.
- The <ulink url="http://microolap.com/products/network/pssdk/faq/">Packet Sniffer SDK</ulink> libraries
- are a good example of the desired portability requirements for a modified WinPcap implementation.
+ Tap32 adapter.
</para>
</sect2>
@@ -582,13 +612,6 @@
</para>
</listitem>
- <listitem><command>Boot and Runtime Modifications</command>
- <para>
-<literallayout><function>build/iso/
-</function></literallayout>
- </para>
- </listitem>
-
</itemizedlist>
</sect3>
@@ -612,7 +635,7 @@
<title>OpenVPN TAP-Win32 Patches</title>
<itemizedlist>
- <listitem><command>TAP-Win32 Network Device Driver</command>
+ <listitem><command>Portable TAP-Win32 Network Device Driver</command>
<para>
<literallayout><function>openvpn-tor-tap-win32-driver.patch
</function></literallayout>
@@ -622,24 +645,6 @@
</itemizedlist>
</sect3>
-
- <sect3>
- <title>Vidalia Patches</title>
- <itemizedlist>
-
- <listitem><command>Start and Stop Control of VM</command>
- <para>
- </para>
- </listitem>
-
- <listitem><command>Direct (non-Tor) and Blocked Port Setup</command>
- <para>
- </para>
- </listitem>
-
- </itemizedlist>
- </sect3>
-
</sect2>
More information about the tor-commits
mailing list