Author: mikeperry Date: 2011-09-30 02:24:16 +0000 (Fri, 30 Sep 2011) New Revision: 25141
Added: website/trunk/projects/en/torbrowser/ website/trunk/projects/en/torbrowser/design/ website/trunk/projects/en/torbrowser/design/CookieManagers.png website/trunk/projects/en/torbrowser/design/index.html.en Log: Add design doc draft.
Added: website/trunk/projects/en/torbrowser/design/CookieManagers.png =================================================================== (Binary files differ)
Property changes on: website/trunk/projects/en/torbrowser/design/CookieManagers.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream
Added: website/trunk/projects/en/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/en/torbrowser/design/index.html.en (rev 0) +++ website/trunk/projects/en/torbrowser/design/index.html.en 2011-09-30 02:24:16 UTC (rev 25141) @@ -0,0 +1,955 @@ +<?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>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn_torproject\org">erinn_torproject\org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject\org">sjmurdoch#torproject\org</a>></code></p></div></div></div></div><div><p class="pubdate">Sep 29 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2881557">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Priv acy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Domain Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Domain Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Click -to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2881557"></a>1. Introduction</h2></div></div></div><p> + +This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, +<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, +<a class="link" href="#Implementation" title="3. Implementation">implementation</a>, <a class="link" href="#Packaging" title="4. Packaging">packaging</a> and <a class="link" href="#Testing" title="5. Testing">testing +procedures</a> of the Tor Browser. It is +current as of Tor Browser 2.2.32-4. + + </p><p> + +This document is also meant to serve as a set of design requirements and to +describe a reference implementation of a Private Browsing Mode that defends +against both local and network adversaries. + + </p><div class="sect2" title="1.1. Adversary Model"><div class="titlepage"><div><div><h3 class="title"><a id="adversary"></a>1.1. Adversary Model</h3></div></div></div><p> + +A Tor web browser adversary has a number of goals, capabilities, and attack +types that can be used to guide us towards a set of requirements for the +Tor Browser. Let's start with the goals. + + </p><div class="sect3" title="Adversary Goals"><div class="titlepage"><div><div><h4 class="title"><a id="adversarygoals"></a>Adversary Goals</h4></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Bypassing proxy settings</strong></span><p>The adversary's primary goal is direct compromise and bypass of +Tor, causing the user to directly connect to an IP of the adversary's +choosing.</p></li><li class="listitem"><span class="command"><strong>Correlation of Tor vs Non-Tor Activity</strong></span><p>If direct proxy bypass is not possible, the adversary will likely +happily settle for the ability to correlate something a user did via Tor with +their non-Tor activity. This can be done with cookies, cache identifiers, +javascript events, and even CSS. Sometimes the fact that a user uses Tor may +be enough for some authorities.</p></li><li class="listitem"><span class="command"><strong>History disclosure</strong></span><p> +The adversary may also be interested in history disclosure: the ability to +query a user's history to see if they have issued certain censored search +queries, or visited censored sites. + </p></li><li class="listitem"><span class="command"><strong>Location information</strong></span><p> + +Location information such as timezone and locality can be useful for the +adversary to determine if a user is in fact originating from one of the +regions they are attempting to control, or to zero-in on the geographical +location of a particular dissident or whistleblower. + + </p></li><li class="listitem"><span class="command"><strong>Miscellaneous anonymity set reduction</strong></span><p> + +Anonymity set reduction is also useful in attempting to zero in on a +particular individual. If the dissident or whistleblower is using a rare build +of Firefox for an obscure operating system, this can be very useful +information for tracking them down, or at least <a class="link" href="#fingerprinting">tracking their activities</a>. + + </p></li><li class="listitem"><span class="command"><strong>History records and other on-disk +information</strong></span><p> +In some cases, the adversary may opt for a heavy-handed approach, such as +seizing the computers of all Tor users in an area (especially after narrowing +the field by the above two pieces of information). History records and cache +data are the primary goals here. + </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Positioning"><div class="titlepage"><div><div><h4 class="title"><a id="adversarypositioning"></a>Adversary Capabilities - Positioning</h4></div></div></div><p> +The adversary can position themselves at a number of different locations in +order to execute their attacks. + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Exit Node or Upstream Router</strong></span><p> +The adversary can run exit nodes, or alternatively, they may control routers +upstream of exit nodes. Both of these scenarios have been observed in the +wild. + </p></li><li class="listitem"><span class="command"><strong>Adservers and/or Malicious Websites</strong></span><p> +The adversary can also run websites, or more likely, they can contract out +ad space from a number of different adservers and inject content that way. For +some users, the adversary may be the adservers themselves. It is not +inconceivable that adservers may try to subvert or reduce a user's anonymity +through Tor for marketing purposes. + </p></li><li class="listitem"><span class="command"><strong>Local Network/ISP/Upstream Router</strong></span><p> +The adversary can also inject malicious content at the user's upstream router +when they have Tor disabled, in an attempt to correlate their Tor and Non-Tor +activity. + </p></li><li class="listitem"><span class="command"><strong>Physical Access</strong></span><p> +Some users face adversaries with intermittent or constant physical access. +Users in Internet cafes, for example, face such a threat. In addition, in +countries where simply using tools like Tor is illegal, users may face +confiscation of their computer equipment for excessive Tor usage or just +general suspicion. + </p></li></ol></div></div><div class="sect3" title="Adversary Capabilities - Attacks"><div class="titlepage"><div><div><h4 class="title"><a id="attacks"></a>Adversary Capabilities - Attacks</h4></div></div></div><p> + +The adversary can perform the following attacks from a number of different +positions to accomplish various aspects of their goals. It should be noted +that many of these attacks (especially those involving IP address leakage) are +often performed by accident by websites that simply have Javascript, dynamic +CSS elements, and plugins. Others are performed by adservers seeking to +correlate users' activity across different IP addresses, and still others are +performed by malicious agents on the Tor network and at national firewalls. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Inserting Javascript</strong></span><p> +If not properly disabled, Javascript event handlers and timers +can cause the browser to perform network activity after Tor has been disabled, +thus allowing the adversary to correlate Tor and Non-Tor activity and reveal +a user's non-Tor IP address. Javascript +also allows the adversary to execute <a class="ulink" href="http://whattheinternetknowsaboutyou.com/" target="_top">history disclosure attacks</a>: +to query the history via the different attributes of 'visited' links to search +for particular Google queries, sites, or even to <a class="ulink" href="http://www.mikeonads.com/2008/07/13/using-your-browser-url-history-estimate-gender/" target="_top">profile +users based on gender and other classifications</a>. Finally, +Javascript can be used to query the user's timezone via the +<code class="function">Date()</code> object, and to reduce the anonymity set by querying +the <code class="function">navigator</code> object for operating system, CPU, locale, +and user agent information. + </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p> + +Plugins are abysmal at obeying the proxy settings of the browser. Every plugin +capable of performing network activity that the author has +investigated is also capable of performing network activity independent of +browser proxy settings - and often independent of its own proxy settings. +Sites that have plugin content don't even have to be malicious to obtain a +user's +Non-Tor IP (it usually leaks by itself), though <a class="ulink" href="http://decloak.net" target="_top">plenty of active +exploits</a> are possible as well. In addition, plugins can be used to store unique identifiers that are more +difficult to clear than standard cookies. +<a class="ulink" href="http://epic.org/privacy/cookies/flash.html" target="_top">Flash-based +cookies</a> fall into this category, but there are likely numerous other +examples. + + </p></li><li class="listitem"><span class="command"><strong>Inserting CSS</strong></span><p> + +CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's +Non-Tor IP address, via the usage of +<a class="ulink" href="http://www.tjkdesign.com/articles/css%20pop%20ups/" target="_top">CSS +popups</a> - essentially CSS-based event handlers that fetch content via +CSS's onmouseover attribute. If these popups are allowed to perform network +activity in a different Tor state than they were loaded in, they can easily +correlate Tor and Non-Tor activity and reveal a user's IP address. In +addition, CSS can also be used without Javascript to perform <a class="ulink" href="http://ha.ckers.org/weird/CSS-history.cgi" target="_top">CSS-only history disclosure +attacks</a>. + </p></li><li class="listitem"><span class="command"><strong>Read and insert cookies</strong></span><p> + +An adversary in a position to perform MITM content alteration can inject +document content elements to both read and inject cookies for arbitrary +domains. In fact, many "SSL secured" websites are vulnerable to this sort of +<a class="ulink" href="http://seclists.org/bugtraq/2007/Aug/0070.html" target="_top">active +sidejacking</a>. In addition, the ad networks of course perform tracking +with cookies as well. + + </p></li><li class="listitem"><span class="command"><strong>Create arbitrary cached content</strong></span><p> + +Likewise, the browser cache can also be used to <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">store unique +identifiers</a>. Since by default the cache has no same-origin policy, +these identifiers can be read by any domain, making them an ideal target for +ad network-class adversaries. + + </p></li><li class="listitem"><a id="fingerprinting"></a><span class="command"><strong>Fingerprint users based on browser +attributes</strong></span><p> + +There is an absurd amount of information available to websites via attributes +of the browser. This information can be used to reduce anonymity set, or even +<a class="ulink" href="http://mandark.fr/0x000000/articles/Total_Recall_On_Firefox..html" target="_top">uniquely +fingerprint individual users</a>. </p><p> + +The <a class="ulink" href="https://wiki.mozilla.org/Fingerprinting#Data" target="_top">Panopticlick study +done</a> by the EFF attempts to measure the actual entropy - the number of +identifying bits of information encoded in browser properties. Their result +data is definitely useful, and the metric is probably the appropriate one for +determining how identifying a particular browser property is. However, some +quirks of their study means that they do not extract as much information as +they could from display information: they only use desktop resolution (which +Torbutton reports as the window resolution) and do not attempt to infer the +size of toolbars. + + + +</p></li><li class="listitem"><span class="command"><strong>Remotely or locally exploit browser and/or +OS</strong></span><p> + +Last, but definitely not least, the adversary can exploit either general +browser vulnerabilities, plugin vulnerabilities, or OS vulnerabilities to +install malware and surveillance software. An adversary with physical access +can perform similar actions. Regrettably, this last attack capability is +outside of our ability to defend against, but it is worth mentioning for +completeness. <a class="ulink" href="http://tails.boum.org/contribute/design/" target="_top">The Tails +system</a> however can provide some limited defenses against this +adversary. + + </p></li></ol></div></div></div></div><div class="sect1" title="2. Design Requirements and Philosophy"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="DesignRequirements"></a>2. Design Requirements and Philosophy</h2></div></div></div><p> + +The Tor Browser Design Requirements are meant to describe the properties of a +Private Browsing Mode that defends against both network and local adversaries. + + </p><p> + +There are two main categories of requirements: <a class="link" href="#security" title="2.1. Security Requirements">Security Requirements</a>, and <a class="link" href="#privacy" title="2.2. Privacy Requirements">Privacy Requirements</a>. Security Requirements are the +minimum properties in order for a web client platform to be able to support +Tor. Privacy requirements are the set of properties that cause us to prefer +one platform over another. + + </p><p> + +We will maintain an alternate distribution of the web client in order to +maintain and/or restore privacy properties to our users. + + </p><div class="sect2" title="2.1. Security Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="security"></a>2.1. Security Requirements</h3></div></div></div><p> + +The security requirements are primarily concerned with ensuring the safe use +of Tor. Violations in these properties typically result in serious risk for +the user in terms of immediate deanonymization and/or observability. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Proxy Obedience</strong></span><p>The browser +MUST NOT bypass Tor proxy settings for any content.</p></li><li class="listitem"><span class="command"><strong>State Separation</strong></span><p>The browser MUST NOT provide any stored state to the content window +from other browsers or other browsing modes, including shared state from +plugins, machine identifiers, and TLS session state. +</p></li><li class="listitem"><span class="command"><strong>Disk Avoidance</strong></span><p>The +browser SHOULD NOT write any browsing history information to disk, or store it +in memory beyond the duration of one Tor session, unless the user has +explicitly opted to store their browsing history information to +disk.</p></li><li class="listitem"><span class="command"><strong>Application Data Isolation</strong></span><p>The browser +MUST NOT write or cause the operating system to +write <span class="emphasis"><em>any information</em></span> to disk outside of the application +directory. All exceptions and shortcomings due to operating system behavior +MUST BE documented. + +</p></li><li class="listitem"><span class="command"><strong>Update Safety</strong></span><p>The browser SHOULD NOT perform unsafe updates or upgrades.</p></li></ol></div></div><div class="sect2" title="2.2. Privacy Requirements"><div class="titlepage"><div><div><h3 class="title"><a id="privacy"></a>2.2. Privacy Requirements</h3></div></div></div><p> + +The privacy requirements are primarily concerned with reducing linkability: +the ability for a user's activity on one site to be linked with their +activity on another site without their knowledge or explicit consent. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Cross-Domain Identifier Unlinkability</strong></span><p> + +User activity on one url bar domain MUST NOT be linkable to their activity in +any other domain by any third party. This property specifically applies to +linkability from stored browser identifiers, authentication tokens, and shared +state. This functionality SHOULD NOT interfere with federated login in a +substantial way. + + </p></li><li class="listitem"><span class="command"><strong>Cross-Domain Fingerprinting Unlinkability</strong></span><p> + +User activity on one url bar domain MUST NOT be linkable to their activity in +any other domain by any third party. This property specifically applies to +linkability from fingerprinting browser behavior. + + </p></li><li class="listitem"><span class="command"><strong>Long-Term Unlinkability</strong></span><p> + +The browser SHOULD provide an obvious, easy way to remove all of their authentication +tokens and browser state and obtain a fresh identity. Additionally, this +should happen by default automatically upon browser restart. + + </p></li></ol></div></div><div class="sect2" title="2.3. Philosophy"><div class="titlepage"><div><div><h3 class="title"><a id="philosophy"></a>2.3. Philosophy</h3></div></div></div><p> + +In addition to the above design requirements, the technology decisions about +Tor Browser are also guided by some philosophical positions about technology. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>Preserve existing user model</strong></span><p> + +The existing way that the user expects to use a browser must be preserved. If +the user has to maintain a different mental model of how the sites they are +using behave depending on tab, browser state, or anything else that would not +normally be what they experience in their default browser, the user will +inevitably be confused. They will make mistakes and reduce their privacy as a +result. Worse, they may just stop using the browser, assuming it is broken. + + </p><p> + +User model breakage was one of the <a class="ulink" href="https://blog.torproject.org/blog/toggle-or-not-toggle-end-torbutton" target="_top">failures +of Torbutton</a>: Even if users managed to install everything properly, +the toggle model was too hard for the average user to understand, especially +in the face of accumulating tabs from multiple states crossed with the current +tor-state of the browser. + + </p></li><li class="listitem"><span class="command"><strong>Favor the implementation mechanism least likely to +break sites</strong></span><p> + +In general, we try to find solutions to privacy issues that will not induce +site breakage, though this is not always possible. + + </p></li><li class="listitem"><span class="command"><strong>Plugins must be restricted</strong></span><p> + +Even if plugins always properly used the browser proxy settings (which none of +them do) and could not be induced to bypass them (which all of them can), the +activities of closed-source plugins are very difficult to audit and control. +They can obtain and transmit all manner of system information to websites, +often have their own identifier storage for tracking users, and also +contribute to fingerprinting. + + </p><p> + +Therefore, if plugins are to be enabled in private browsing modes, they must +be restricted from running automatically on every page (via click-to-play +placeholders), and/or be sandboxed to restrict the types of system calls they +can execute. If the user decides to craft an exemption to allow a plugin to be +used, it MUST ONLY apply to the top level urlbar domain, and not to all sites, +to reduce linkability. + + </p></li><li class="listitem"><span class="command"><strong>Minimize Global Privacy Options</strong></span><p> + +<a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">Another +failure of Torbutton</a> was (and still is) the options panel. Each option +that detectably alters browser behavior can be used as a fingerprinting tool. +Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">should be +disabled in the mode</a> except as an opt-in basis. We should not load +system-wide addons or plugins. + + </p><p> +Instead of global browser privacy options, privacy decisions should be made +<a class="ulink" href="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI" target="_top">per +top-level url-bar domain</a> to eliminate the possibility of linkability +between domains. For example, when a plugin object (or a Javascript access of +window.plugins) is present in a page, the user should be given the choice of +allowing that plugin object for that top-level url-bar domain only. The same +goes for exemptions to third party cookie policy, geo-location, and any other +privacy permissions. + </p><p> +If the user has indicated they do not care about local history storage, these +permissions can be written to disk. Otherwise, they should remain memory-only. + </p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p> + +Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock +Plus</a>, <a class="ulink" href="" target="_top">Request Policy</a>, <a class="ulink" href="http://priv3.icsi.berkeley.edu/" target="_top">Priv3</a>, and <a class="ulink" href="http://sharemenot.cs.washington.edu/" target="_top">Sharemenot</a> are to be +avoided. We believe that these addons do not add any real privacy to a proper +<a class="link" href="#Implementation" title="3. Implementation">implementation</a> of the above <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirements</a>, as all third parties are +prevented from tracking users between sites by the implementation. +Filter-based addons can also introduce strange breakage and cause usability +nightmares, and will also fail to do their job if an adversary simply +registers a new domain or creates a new url path. Worse still, the unique +filter sets that each user is liable to create/install likely provide a wealth +of fingerprinting targets. + + </p><p> + +As a general matter, we are also generally opposed to shipping an always-on Ad +blocker with Tor Browser. We feel that this would damage our credibility in +terms of demonstrating that we are providing privacy through a sound design +alone, as well as damage the acceptance of Tor users by sites who support +themselves through advertising revenue. + + </p><p> +Users are free to install these addons if they wish, but doing +so is not recommended, as it will alter the browser request fingerprint. + </p></li><li class="listitem"><span class="command"><strong>Stay Current</strong></span><p> +We believe that if we do not stay current with the support of new web +technologies, we cannot hope to substantially influence or be involved in +their proper deployment or privacy realization. However, we will likely disable +certain new features (where possible) pending analysis and audit. + </p></li></ol></div></div></div><div class="sect1" title="3. Implementation"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Implementation"></a>3. Implementation</h2></div></div></div><p> + </p><div class="sect2" title="3.1. Proxy Obedience"><div class="titlepage"><div><div><h3 class="title"><a id="proxy-obedience"></a>3.1. Proxy Obedience</h3></div></div></div><p> + +Proxy obedience is assured through the following: + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox Proxy settings + <p> + The Torbutton xpi sets the Firefox proxy settings to use Tor directly as a +SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>, +<span class="command"><strong>network.proxy.socks_version</strong></span>, and +<span class="command"><strong>network.proxy.socks_port</strong></span>. + </p></li><li class="listitem">Disabling plugins + <p> + Plugins have the ability to make arbitrary OS system calls. This includes +the ability to make UDP sockets and send arbitrary data independent of the +browser proxy settings. + </p><p> +Torbutton disables plugins by using the +<span class="command"><strong>@mozilla.org/plugin/host;1</strong></span> service to mark the plugin tags +as disabled. Additionally, we set +<span class="command"><strong>plugin.disable_full_page_plugin_for_types</strong></span> to the list of +supported mime types for all currently installed plugins. + </p><p> +In addition, to prevent any unproxied activity by plugins at load time, we +also patch the Firefox source code to <a class="ulink" href="" target="_top">prevent the load of any plugins except +for Flash and Gnash</a>. + + </p></li><li class="listitem">External App Blocking + <p> +External apps, if launched automatically, can be induced to load files that +perform network activity. In order to prevent this, Torbutton installs a +component to +<a class="ulink" href="" target="_top"> +provide the user with a popup</a> whenever the browser attempts to +launch a helper app. + </p></li></ol></div></div><div class="sect2" title="3.2. State Separation"><div class="titlepage"><div><div><h3 class="title"><a id="state-separation"></a>3.2. State Separation</h3></div></div></div><p> +Tor Browser State is separated from existing browser state through use of a +custom Firefox profile. Furthermore, plugins are disabled, which prevents +Flash cookies from leaking from a pre-existing Flash directory. + </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2888086"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> +Tor Browser should optionally prevent all disk records of browser activity. +The user should be able to optionally enable URL history and other history +features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the +preferences interface</a>, we will likely just enable Private Browsing +mode by default to handle this goal. + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2914304"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> +For now, Tor Browser blocks write access to the disk through Torbutton +using several Firefox preferences. + + + +The set of prefs is: +<span class="command"><strong>dom.storage.enabled</strong></span>, +<span class="command"><strong>browser.cache.memory.enable</strong></span>, +<span class="command"><strong>network.http.use-cache</strong></span>, +<span class="command"><strong>browser.cache.disk.enable</strong></span>, +<span class="command"><strong>browser.cache.offline.enable</strong></span>, +<span class="command"><strong>general.open_location.last_url</strong></span>, +<span class="command"><strong>places.history.enabled</strong></span>, +<span class="command"><strong>browser.formfill.enable</strong></span>, +<span class="command"><strong>signon.rememberSignons</strong></span>, +<span class="command"><strong>browser.download.manager.retention</strong></span>, +and <span class="command"><strong>network.cookie.lifetimePolicy</strong></span>. + </blockquote></div></div><p> +In addition, three Firefox patches are needed to prevent disk writes, even if +Private Browsing Mode is enabled. We need to + +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0002-Make-Permissions-Manager-memory-only.patch" target="_top">prevent +the permissions manager from recording HTTPS STS state</a>, +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0003-Make-Intermediate-Cert-Store-memory-only.patch" target="_top">prevent +intermediate SSL certificates from being recorded</a>, and +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0008-Make-content-pref-service-memory-only-clearable.patch" target="_top">prevent +the content preferences service from recording site zoom</a>. + +For more details on these patches, <a class="link" href="#firefox-patches" title="3.9. Description of Firefox Patches">see the +Firefox Patches section</a>. + + </p></div><div class="sect2" title="3.4. Application Data Isolation"><div class="titlepage"><div><div><h3 class="title"><a id="app-data-isolation"></a>3.4. Application Data Isolation</h3></div></div></div><p> + +Tor Browser Bundle MUST NOT cause any information to be written outside of the +bundle directory. This is to ensure that the user is able to completely and +safely remove the bundle without leaving other traces of Tor usage on their +computer. + + </p><p>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this, +and/or what additional work or auditing needs to be done. + </p></div><div class="sect2" title="3.5. Cross-Domain Identifier Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="identifier-linkability"></a>3.5. Cross-Domain Identifier Unlinkability</h3></div></div></div><p> + +The Tor Browser MUST prevent a user's activity on one site from being linked +to their activity on another site. When this goal cannot yet be met with an +existing web technology, that technology or functionality is disabled. Our +<a class="link" href="#privacy" title="2.2. Privacy Requirements">design goal</a> is to ultimately eliminate the need to disable arbitrary +technologies, and instead simply alter them in ways that allows them to +function in a backwards-compatible way while avoiding linkability. Users +should be able to use federated login of various kinds to explicitly inform +sites who they are, but that information should not transparently allow a +third party to record their activity from site to site without their prior +consent. + + </p><p> + +The benefit of this approach comes not only in the form of reduced +linkability, but also in terms of simplified privacy UI. If all stored browser +state and permissions become associated with the top-level url-bar domain, the +six or seven different pieces of privacy UI governing these identifiers and +permissions can become just one piece of UI. For instance, a window that lists +the top-level url bar domains for which browser state exists with the ability +to clear and/or block them, possibly with a context-menu option to drill down +into specific types of state. An exmaple of this simplifcation can be seen in +Figure 1. + + </p><div class="figure"><a id="id2909608"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + +On the left is the standard Firefox cookie manager. On the right is a mock-up +of how isolating identifiers to the URL bar domain might simplify the privacy +UI for all data - not just cookies. Both windows represent the set of +Cookies accomulated after visiting just five sites, but the window on the +right has the option of also representing history, DOM Storage, HTTP Auth, +search form history, login values, and so on within a context menu for each +site. + +</div></div></div><br class="figure-break" /><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Cookies + <p><span class="command"><strong>Design Goal:</strong></span> + +All cookies should be double-keyed to the top-level domain. There exists a +<a class="ulink" href="" target="_top">Mozilla +bug</a> that contains a prototype patch, but it lacks UI, and does not +apply to modern Firefoxes. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +As a stopgap to satisfy our design requirement of unlinkability, we currently +entirely disable 3rd party cookies by setting +<span class="command"><strong>network.cookie.cookieBehavior</strong></span> to 1. We would prefer that +third party content continue to function , but we believe the requirement for +unlinkability trumps that desire. + + </p></li><li class="listitem">Cache + <p> +Cache is isolated to the top-level url bar domain by using a technique +pioneered by Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the +<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a> +attribute that Firefox uses internally to prevent improper caching of HTTP POST data. + </p><p> +However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the +security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and +unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch +Firefox to provide a cacheDomain cache attribute</a>. We use the full +url bar domain as input to this field. + </p><p> + + +Furthermore, we chose a different isolation scheme than the Stanford +implementation. First, we decoupled the cache isolation from the third party +cookie attribute. Second, we use several mechanisms to attempt to determine +the actual location attribute of the top-level window (the url bar domain) +used to load the page, as opposed to relying solely on the referer property. + </p><p> +Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original +Stanford test +cases</a> are expected to fail. Functionality can still be verified by +navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key +used for each cache entry. Each third party element should have an additional +"domain=string" property prepended, which will list the top-level urlbar +domain that was used to source the third party element. + </p></li><li class="listitem">HTTP Auth + <p> + +HTTP authentication tokens are removed for third party elements using the +<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request +observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">silent +linkability between domains</a>. We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0004-Add-HTTP-auth-headers-before-the-modify-request-obse.patch" target="_top">patch +Firefox to cause the headers to get added early enough</a> to allow the +observer to modify it. + + </p></li><li class="listitem">DOM Storage + <p><span class="command"><strong>Design Goal:</strong></span> + +DOM storage for third party domains MUST BE isolated to the url bar domain, +to prevent linkability between sites. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Because it is isolated to third party domain as opposed to top level url bar +domain, we entirely disable DOM storage as a stopgap to ensure unlinkability. + + </p></li><li class="listitem">TLS session resumption and HTTP Keep-Alive + <p> +TLS session resumption and HTTP Keep-Alive must not allow third party origins +to track users via either TLS session IDs, or the fact that different requests +arrive on the same TCP connection. + </p><p><span class="command"><strong>Design Goal:</strong></span> + +TLS session resumption IDs must be limited to the top-level url bar domain. +HTTP Keep-Alive connections from a third party in one top-level domain must +not be reused for that same third party in another top-level domain. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">plan to +disable</a> TLS session resumption, and limit HTTP Keep-alive duration. + + </p></li><li class="listitem">window.name + <p> + +<a class="ulink" href="https://developer.mozilla.org/En/DOM/Window.name" target="_top">window.name</a> is +a magical DOM property that for some reason is allowed to retain a persistent value +for the lifespan of a browser tab. It is possible to utilize this property for +<a class="ulink" href="http://www.thomasfrank.se/sessionvars.html" target="_top">identifier +storage</a>. + + </p><p> + +In order to eliminate linkability but still allow for sites that utilize this +property to function, we reset the window.name property of tabs in Torbutton every +time we encounter a blank referer. This behavior allows window.name to persist +for the duration of a link-driven navigation session, but as soon as the user +enters a new URL or navigates between https/http schemes, the property is cleared. + + </p></li><li class="listitem">Exit node usage + <p><span class="command"><strong>Design Goal:</strong></span> + +Every distinct navigation session (as defined by a non-blank referer header) +MUST exit through a fresh Tor circuit in Tor Browser to prevent exit node +observers from linking concurrent browsing activity. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +The Tor feature that supports this ability only exists in the 0.2.3.x-alpha +series. <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3455" target="_top">Ticket +#3455</a> is the Torbutton ticket to make use of the new Tor +functionality. + + </p></li></ol></div></div><div class="sect2" title="3.6. Cross-Domain Fingerprinting Unlinkability"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>3.6. Cross-Domain Fingerprinting Unlinkability</h3></div></div></div><p> + +In order to properly address the fingerprinting adversary on a technical +level, we need a metric to measure linkability of the various browser +properties that extend beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a> +by the EFF provides us with exactly this metric. The researchers conducted a +survey of volunteers who were asked to visit an experiment page that harvested +many of the above components. They then computed the Shannon Entropy of the +resulting distribution of each of several key attributes to determine how many +bits of identifying information each attribute provided. + + </p><p> + +The study is not exhaustive, though. In particular, the test does not take in +all aspects of resolution information. It did not calculate the size of +widgets, window decoration, or toolbar size, which we believe may add high +amounts of entropy. It also did not measure clock offset and other time-based +fingerprints. Furthermore, as new browser features are added, this experiment +should be repeated to include them. + + </p><p> + +On the other hand, to avoid an infinite sinkhole, we reduce the efforts for +fingerprinting resistance by only concerning ourselves with reducing the +fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. We +do not believe it is productive to concern ourselves with cross-browser +fingerprinting issues, at least not at this stage. + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins + <p> + +Plugins add to fingerprinting risk via two main vectors: their mere presence in +window.navigator.plugins, as well as their internal functionality. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +All plugins that have not been specifically audited or sandboxed must be +disabled. To reduce linkability potential, even sandboxed plugins should not +be allowed to load objects until the user has clicked through a click-to-play +barrier. Additionally, version information should be reduced or obfuscated +until the plugin object is loaded. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Currently, we entirely disable all plugins in Tor Browser. However, as a +compromise due to the popularity of Flash, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">work +towards</a> a +click-to-play barrier using NoScript that is available only after the user has +specifically enabled plugins. Flash will be the only plugin available, and we +will ship a settings.sol file to disable Flash cookies, and to restrict P2P +features that likely bypass proxy settings. + + </p></li><li class="listitem">Fonts + <p> + +According to the Panopticlick study, fonts provide the most linkability when +they are provided as an enumerable list in filesystem order, via either the +Flash or Java plugins. However, it is still possible to use CSS and/or +Javascript to query for the existence of specific fonts. With a large enough +pre-built list to query, a large amount of fingerprintable information may +still be available. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +To address the Javascript issue, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2872" target="_top">limit the number of +fonts</a> an origin can load, gracefully degrading to built-in and/or +remote fonts once the limit is reached. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Aside from disabling plugins to prevent enumeration, we have not yet +implemented any defense against CSS or Javascript fonts. + + </p></li><li class="listitem">User Agent and HTTP Headers + <p><span class="command"><strong>Design Goal:</strong></span> + +All Tor Browser users should provide websites with an identical user agent and +HTTP header set for a given request type. We omit the Firefox minor revision, +and report a popular Windows platform. If the software is kept up to date, +these headers should remain identical across the population even when updated. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Firefox provides several options for controlling the browser user agent string +which we leverage. We also set similar prefs for controlling the +Accept-Language and Accept-Charset headers, which we spoof to English by default. Additionally, we +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0001-Block-Components.interfaces-lookupMethod-from-conten.patch" target="_top">remove +content script access</a> to Components.interfaces, which <a class="ulink" href="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html" target="_top">can be +used</a> to fingerprint OS, platform, and Firefox minor version. </p></li><li class="listitem">Desktop resolution and CSS Media Queries + <p> + +Both CSS and Javascript have a lot of irrelevant information about the screen +resolution, usable desktop size, OS widget size, toolbar size, title bar size, and +other desktop features that are not at all relevant to rendering and serve +only to provide information for fingerprinting. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +Our design goal here is to reduce the resolution information down to the bare +minimum required for properly rendering inside a content window. We intend to +report all rendering information correctly with respect to the size and +properties of the content window, but report an effective size of 0 for all +border material, and also report that the desktop is only as big as the +inner content window. Additionally, new browser windows are sized such that +their content windows are one of ~5 fixed sizes based on the user's +desktop resolution. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">JavaScript +hooks</a> as well as a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/torbutton.js#l4002" target="_top">resize +new windows based on desktop resolution</a>. However, CSS Media Queries +still <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2875" target="_top">need +to be dealt with</a>. + + </p></li><li class="listitem">Timezone and clock offset + <p><span class="command"><strong>Design Goal:</strong></span> + +All Tor Browser users should report the same timezone to websites. Currently, +we choose UTC for this purpose, although an equally valid argument could be +made for EDT/EST due to the large English-speaking population density. +Additionally, the Tor software should detect if the users clock is +significantly divergent from the clocks of the relays that it connects to, and +use this to reset the clock values used in Tor Browser to something reasonably +accurate. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We set the timezone using the TZ environment variable, which is supported on +all platforms. Additionally, we plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3652" target="_top">obtain a clock +offset from Tor</a>, but this won't be available until Tor 0.2.3.x is in +use. + + </p></li><li class="listitem">Javascript performance fingerprinting + <p> + +<a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Javascript performance +fingerprinting</a> is the act of profiling the performance +of various Javascript functions for the purpose of fingerprinting the +Javascript engine and the CPU. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +We have <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3059" target="_top">several potential +mitigation approaches</a> to reduce the accuracy of performance +fingerprinting without risking too much damage to functionality. Our current +favorite is to reduce the resolution of the Event.timeStamp and the Javascript +Date() object, while also introducing jitter. Our goal is to increase the +amount of time it takes to mount a successful attack. <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">Mowery et al</a> found that +even with the default precision in most browsers, they required up to 120 +seconds of amortization and repeated trials to get stable results from their +feature set. We intend to work with the research community to establish the +optimum tradeoff between quantization+jitter and amortization time. + + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +We have no implementation as of yet. + + </p></li><li class="listitem">Keystroke fingerprinting + <p> + +Keystroke fingerprinting is the act of measuring key strike time and key +flight time. It is seeing increasing use as a biometric. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +We intend to rely on the same mechanisms for defeating Javascript performance +fingerprinting: timestamp quantization and jitter. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> +We have no implementation as of yet. + </p></li><li class="listitem">WebGL + <p> + +WebGL is fingerprintable both through information that is exposed about the +underlying driver and optimizations, as well as through performance +fingerprinting. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +Because of the large amount of potential fingerprinting vectors, we intend to +deploy a similar strategy against WebGL as for plugins. First, WebGL canvases +will have click-to-play placeholders, and will not run until authorized by the +user. Second, we intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3323" target="_top">obfuscate driver +information</a> by hooking +<span class="command"><strong>getParameter()</strong></span>, +<span class="command"><strong>getSupportedExtensions()</strong></span>, +<span class="command"><strong>getExtension()</strong></span>, and +<span class="command"><strong>getContextAttributes()</strong></span> to provide standard minimal, +driver-neutral information. + + </p><p><span class="command"><strong>Implementation Status:</strong></span> + +Currently we simply disable WebGL. + + </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> +In order to avoid long-term linkability, we provide a "New Identity" context +menu option in Torbutton. + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2894546"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + +All linkable identifiers and browser state should be cleared by this feature. + + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2904450"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + First, Torbutton disables +all open tabs and windows via nsIContentPolicy blocking, and then closes each +tab and window. The extra step for blocking tabs is done as a precaution to +ensure that any asynchronous Javascript is in fact properly disabled. After +closing all of the windows, we then clear the following state: OCSP (by +toggling security.OCSP.enabled), cache, site-specific zoom and content +preferences, Cookies, DOM storage, safe browsing key, the Google wifi +geolocation token (if exists), HTTP auth, SSL Session IDs, and the last opened URL +field (via the pref general.open_location.last_url). After clearing the +browser state, we then send the NEWNYM signal to the Tor control port to cause +a new circuit to be created. + </blockquote></div></div></div><div class="sect2" title="3.8. Click-to-play for plugins and invasive content"><div class="titlepage"><div><div><h3 class="title"><a id="click-to-play"></a>3.8. Click-to-play for plugins and invasive content</h3></div></div></div><p> +Some content types are too invasive and/or too opaque for us to properly +eliminate their linkability properties. For these content types, we use +NoScript to provide click-to-play placeholders that do not activate the +content until the user clicks on it. This will eliminate the ability for an +adversary to use such content types to link users in a dragnet fashion across +arbitrary sites. + </p><p> +Currently, the content types isolated in this way include Flash, WebGL, and +audio and video objects. + </p></div><div class="sect2" title="3.9. Description of Firefox Patches"><div class="titlepage"><div><div><h3 class="title"><a id="firefox-patches"></a>3.9. Description of Firefox Patches</h3></div></div></div><p> +The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/refs/heads/maint-2.2:/src/current-patches" target="_top">current-patches +directory of the torbrowser git repository</a>. They are: + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Block Components.interfaces and Components.lookupMethod + <p> + +In order to reduce fingerprinting, we block access to these two interfaces +from content script. Components.lookupMethod can undo our <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/jshooks4.js" target="_top">Javascript +hooks</a>, +and Components.interfaces can be used for fingerprinting the platform, OS, and +Firebox version, but not much else. + + </p></li><li class="listitem">Make Permissions Manager memory only + <p> + +This patch exposes a pref 'permissions.memory_only' that properly isolates the +permissions manager to memory, which is responsible for all user specified +site permissions, as well as stored HTTPS STS policy from visited sites. + +The pref does successfully clear the permissions manager memory if toggled. It +does not need to be set in prefs.js, and can be handled by Torbutton. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +As an additional design goal, we would like to later alter this patch to allow this +information to be cleared from memory. The implementation does not currently +allow this. + + </p></li><li class="listitem">Make Intermediate Cert Store memory-only + <p> + +The intermediate certificate store holds information about SSL certificates +that may only be used by a limited number of domains. In some cases +effectively recording on disk the fact that a website owned by a certain +organization was viewed. + + </p><p><span class="command"><strong>Design Goal:</strong></span> + +As an additional design goal, we would like to later alter this patch to allow this +information to be cleared from memory. The implementation does not currently +allow this. + + </p></li><li class="listitem">Add HTTP auth headers before on-modify-request fires + <p> + +This patch provides a trivial modification to allow us to properly remove HTTP +auth for third parties. This patch allows us to defend against an adversary +attempting to use <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies.html" target="_top">HTTP +auth to silently track users between domains</a>. + + </p></li><li class="listitem">Add a string-based cacheKey property for domain isolation + <p> + +To <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the +security of cache isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve strange and +unknown conflicts with OCSP</a>, we had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch" target="_top">patch +Firefox to provide a cacheDomain cache attribute</a>. We use the full +url bar domain as input to this field. + + </p></li><li class="listitem">Randomize HTTP pipeline order and depth + <p> +As an +<a class="ulink" href="https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting" target="_top">experimental +defense against Website Traffic Fingerprinting</a>, we patch the standard +HTTP pipelining code to randomize the number of requests in a +pipeline, as well as their order. + </p></li><li class="listitem">Block all plugins except flash + <p> +We cannot use the <a class="ulink" href="http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/components/@mozilla.org/extensions/blocklist%3B1" target="_top"> +@mozilla.org/extensions/blocklist;1</a> service, because we +actually want to stop plugins from ever entering the browser's process space +and/or executing code (for example, AV plugins that collect statistics/analyze +URLs, magical toolbars that phone home or "help" the user, skype buttons that +ruin our day, and censorship filters). Hence we rolled our own. + </p></li><li class="listitem">Make content-prefs service memory only + <p> +This patch prevents random URLs from being inserted into content-prefs.sqllite in +the profile directory as content prefs change (includes site-zoom and perhaps +other site prefs?). + </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2869647"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2906387"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2907827"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> + +The purpose of this section is to cover all the known ways that Tor browser +security can be subverted from a penetration testing perspective. The hope +is that it will be useful both for creating a "Tor Safety Check" +page, and for developing novel tests and actively attacking Torbutton with the +goal of finding vulnerabilities in either it or the Mozilla components, +interfaces and settings upon which it relies. + + </p><div class="sect2" title="5.1. Single state testing"><div class="titlepage"><div><div><h3 class="title"><a id="SingleStateTesting"></a>5.1. Single state testing</h3></div></div></div><p> + +Torbutton is a complicated piece of software. During development, changes to +one component can affect a whole slough of unrelated features. A number of +aggregated test suites exist that can be used to test for regressions in +Torbutton and to help aid in the development of Torbutton-like addons and +other privacy modifications of other browsers. Some of these test suites exist +as a single automated page, while others are a series of pages you must visit +individually. They are provided here for reference and future regression +testing, and also in the hope that some brave soul will one day decide to +combine them into a comprehensive automated test suite. + + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://decloak.net/" target="_top">Decloak.net</a><p> + +Decloak.net is the canonical source of plugin and external-application based +proxy-bypass exploits. It is a fully automated test suite maintained by <a class="ulink" href="http://digitaloffense.net/" target="_top">HD Moore</a> as a service for people to +use to test their anonymity systems. + + </p></li><li class="listitem"><a class="ulink" href="http://deanonymizer.com/" target="_top">Deanonymizer.com</a><p> + +Deanonymizer.com is another automated test suite that tests for proxy bypass +and other information disclosure vulnerabilities. It is maintained by Kyle +Williams, the author of <a class="ulink" href="http://www.janusvm.com/" target="_top">JanusVM</a> +and <a class="ulink" href="http://www.januspa.com/" target="_top">JanusPA</a>. + + </p></li><li class="listitem"><a class="ulink" href="https://www.jondos.de/en/anontest" target="_top">JonDos +AnonTest</a><p> + +The <a class="ulink" href="https://www.jondos.de" target="_top">JonDos people</a> also provide an +anonymity tester. It is more focused on HTTP headers than plugin bypass, and +points out a couple of headers Torbutton could do a better job with +obfuscating. + + </p></li><li class="listitem"><a class="ulink" href="http://browserspy.dk" target="_top">Browserspy.dk</a><p> + +Browserspy.dk provides a tremendous collection of browser fingerprinting and +general privacy tests. Unfortunately they are only available one page at a +time, and there is not really solid feedback on good vs bad behavior in +the test results. + + </p></li><li class="listitem"><a class="ulink" href="http://analyze.privacy.net/" target="_top">Privacy +Analyzer</a><p> + +The Privacy Analyzer provides a dump of all sorts of browser attributes and +settings that it detects, including some information on your origin IP +address. Its page layout and lack of good vs bad test result feedback makes it +not as useful as a user-facing testing tool, but it does provide some +interesting checks in a single page. + + </p></li><li class="listitem"><a class="ulink" href="http://ha.ckers.org/mr-t/" target="_top">Mr. T</a><p> + +Mr. T is a collection of browser fingerprinting and deanonymization exploits +discovered by the <a class="ulink" href="http://ha.ckers.org" target="_top">ha.ckers.org</a> crew +and others. It is also not as user friendly as some of the above tests, but it +is a useful collection. + + </p></li><li class="listitem">Gregory Fleischer's <a class="ulink" href="http://pseudo-flaw.net/content/tor/torbutton/" target="_top">Torbutton</a> and +<a class="ulink" href="http://pseudo-flaw.net/content/defcon/dc-17-demos/d.html" target="_top">Defcon +17</a> Test Cases + <p> + +Gregory Fleischer has been hacking and testing Firefox and Torbutton privacy +issues for the past 2 years. He has an excellent collection of all his test +cases that can be used for regression testing. In his Defcon work, he +demonstrates ways to infer Firefox version based on arcane browser properties. +We are still trying to determine the best way to address some of those test +cases. + + </p></li><li class="listitem"><a class="ulink" href="https://torcheck.xenobite.eu/index.php" target="_top">Xenobite's +TorCheck Page</a><p> + +This page checks to ensure you are using a valid Tor exit node and checks for +some basic browser properties related to privacy. It is not very fine-grained +or complete, but it is automated and could be turned into something useful +with a bit of work. + + </p></li></ol></div><p> + </p></div></div></div></body></html>