commit d8457b1822deba73b3f0c5e16666e664623b640b Author: Mike Perry <mikeperry-git@fscked.org> Date: Tue Oct 4 20:04:43 2011 -0700 Address comments from Georg Koppen of JonDos. --- docs/design/design.xml | 232 +++++++++++++++++++++++++++++------------------- 1 file changed, 142 insertions(+), 90 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 52e0999..9edea7e 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -14,16 +14,16 @@ <author> <firstname>Erinn</firstname><surname>Clark</surname> <affiliation> - <address><email>erinn_torproject\org</email></address> + <address><email>erinn#torproject org</email></address> </affiliation> </author> <author> <firstname>Steven</firstname><surname>Murdoch</surname> <affiliation> - <address><email>sjmurdoch#torproject\org</email></address> + <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Sep 29 2011</pubdate> + <pubdate>Oct 4 2011</pubdate> </articleinfo> <!-- @@ -40,14 +40,15 @@ This document describes the <link linkend="adversary">adversary model</link>, <link linkend="Implementation">implementation</link>, <link linkend="Packaging">packaging</link> and <link linkend="Testing">testing procedures</link> of the Tor Browser. It is -current as of Tor Browser 2.2.32-4. +current as of Tor Browser 2.2.33-3. </para> <para> 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. +against active network adversaries, in addition to the passive forensic local +adversary currently addressed by the major browsers. </para> <sect2 id="adversary"> @@ -340,12 +341,13 @@ adversary. - No filters --> + <sect1 id="DesignRequirements"> <title>Design Requirements and Philosophy</title> <para> The Tor Browser Design Requirements are meant to describe the properties of a -Private Browsing Mode that defends against both network and local adversaries. +Private Browsing Mode that defends against both network and forensic adversaries. </para> <para> @@ -353,17 +355,27 @@ Private Browsing Mode that defends against both network and local adversaries. There are two main categories of requirements: <link linkend="security">Security Requirements</link>, and <link linkend="privacy">Privacy Requirements</link>. 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. +minimum properties in order for a browser to be able to support Tor and +similar privacy proxies safely. Privacy requirements are the set of properties +that cause us to prefer one browser platform over another. + + </para> + <para> + +While we will endorse the use of browsers that meet the security requirements, +it is primarily the privacy requirements that cause us to maintain our own +browser distribution. </para> <para> -We will maintain an alternate distribution of the web client in order to -maintain and/or restore privacy properties to our users. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + <ulink url="https://www.ietf.org/rfc/rfc2119.txt">RFC 2119</ulink>. </para> + <sect2 id="security"> <title>Security Requirements</title> <para> @@ -388,17 +400,25 @@ from other browsers or other browsing modes, including shared state from plugins, machine identifiers, and TLS session state. </para></listitem> - <listitem><command>Disk Avoidance</command><para>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.</para></listitem> + <listitem><command>Disk Avoidance</command><para> - <listitem><command>Application Data Isolation</command><para>The browser -MUST NOT write or cause the operating system to -write <emphasis>any information</emphasis> to disk outside of the application -directory. All exceptions and shortcomings due to operating system behavior -MUST BE documented. +The browser MUST NOT write any information that is derived from or that +reveals browsing activity to the disk, or store it in memory beyond the +duration of one browsing session, unless the user has explicitly opted to +store their browsing history information to disk. + +</para></listitem> + + <listitem><command>Application Data Isolation</command><para> + +The components involved in providing private browsing MUST BE self-contained, +or MUST provide a mechanism for rapid, complete removal of all evidence of the +use of the mode. In other words, the browser MUST NOT write or cause the +operating system to write <emphasis>any information</emphasis> about the use +of private browsing to disk outside of the application's control. The user +must be able to ensure that secure removal of the software is sufficient to +remove evidence of the use of the software. All exceptions and shortcomings +due to operating system behavior MUST BE wiped by an uninstaller. </para></listitem> <listitem><command>Update Safety</command><para>The browser SHOULD NOT perform unsafe updates or upgrades.</para></listitem> @@ -417,12 +437,23 @@ to prefer one platform over another. </para> + <para> + +For the purposes of the unlinkability requirements of this section as well as +the descriptions in the <link linkend="Implementation">implementation +section</link>, a <command>url bar origin</command> means at least the +second-level DNS name. For example, for mail.google.com, the origin would be +google.com. Implementations MAY, at their option, restrict the url bar origin +to be the entire fully qualified domain name + + </para> + <orderedlist> <listitem><command>Cross-Domain Identifier Unlinkability</command> <para> -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 +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin 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. @@ -432,8 +463,8 @@ substantial way. <listitem><command>Cross-Domain Fingerprinting Unlinkability</command> <para> -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 +User activity on one url bar origin MUST NOT be linkable to their activity in +any other url bar origin by any third party. This property specifically applies to linkability from fingerprinting browser behavior. </para> @@ -441,9 +472,10 @@ linkability from fingerprinting browser behavior. <listitem><command>Long-Term Unlinkability</command> <para> -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. +The browser SHOULD provide an obvious, easy way to remove all of their +authentication tokens and browser state and obtain a fresh identity. +Additionally, the browser SHOULD clear linkable state by default automatically +upon browser restart, except at user option. </para> </listitem> @@ -528,10 +560,10 @@ system-wide addons or plugins. Instead of global browser privacy options, privacy decisions should be made <ulink url="https://wiki.mozilla.org/Privacy/Features/Site-based_data_management_UI">per -top-level url-bar domain</ulink> to eliminate the possibility of linkability +url bar origin</ulink> 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 +allowing that plugin object for that url bar origin only. The same goes for exemptions to third party cookie policy, geo-location, and any other privacy permissions. </para> @@ -732,15 +764,14 @@ safely remove the bundle without leaving other traces of Tor usage on their computer. </para> - <para>XXX: sjmurdoch, Erinn: explain what magic we do to satisfy this, + <para>FIXME: sjmurdoch, Erinn: explain what magic we do to satisfy this, and/or what additional work or auditing needs to be done. </para> </sect2> -<!-- XXX: Write me... +<!-- FIXME: Write me... <sect2 id="update-safety"> <title>Update Safety</title> - <para> -XXX: Write me.. + <para>FIXME: Write me.. </para> </sect2> --> @@ -765,13 +796,12 @@ consent. 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 +state and permissions become associated with the url bar origin, 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. +the url bar origin for which browser state exists, possibly with a +context-menu option to drill down into specific types of state or permissions. +An example of this simplifcation can be seen in Figure 1. </para> <figure><title>Improving the Privacy UI</title> @@ -783,7 +813,7 @@ Figure 1. <caption> <para/> 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 +of how isolating identifiers to the URL bar origin 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, @@ -796,11 +826,11 @@ site. <listitem>Cookies <para><command>Design Goal:</command> -All cookies should be double-keyed to the top-level domain. There exists a -<ulink -url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla -bug</ulink> that contains a prototype patch, but it lacks UI, and does not -apply to modern Firefoxes. +All cookies should be double-keyed to the url bar origin and third-party +origin. There exists a <ulink +url="https://bugzilla.mozilla.org/show_bug.cgi?id=565965">Mozilla bug</ulink> +that contains a prototype patch, but it lacks UI, and does not apply to modern +Firefoxes. </para> <para><command>Implementation Status:</command> @@ -815,42 +845,50 @@ unlinkability trumps that desire. </listitem> <listitem>Cache <para> -Cache is isolated to the top-level url bar domain by using a technique -pioneered by Colin Jackson et al, via their work on <ulink + +Cache is isolated to the url bar origin by using a technique pioneered by +Colin Jackson et al, via their work on <ulink url="http://www.safecache.com/">SafeCache</ulink>. The technique re-uses the <ulink url="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel">nsICachingChannel.cacheKey</ulink> -attribute that Firefox uses internally to prevent improper caching of HTTP POST data. +attribute that Firefox uses internally to prevent improper caching and reuse +of HTTP POST data. + </para> <para> + However, to <ulink url="https://trac.torproject.org/projects/tor/ticket/3666">increase the security of the isolation</ulink> and to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and -unknown conflicts with OCSP</ulink>, we had to <ulink +url="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts +with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we +had to <ulink url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch">patch -Firefox to provide a cacheDomain cache attribute</ulink>. We use the full -url bar domain as input to this field. +Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully +qualified url bar domain as input to this field. + </para> <para> <!-- FIXME: This could use a few more specifics.. Maybe. The Chrome folks -won't care, but the Mozilla folks might. --> -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. +won't care, but the Mozilla folks might. --> 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 (to obtain the url bar FQDN) used to load the page, as +opposed to relying solely on the referer property. + </para> <para> + Therefore, <ulink url="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original -Stanford test -cases</ulink> are expected to fail. Functionality can still be verified by -navigating to <ulink url="about:cache">about:cache</ulink> 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. +Stanford test cases</ulink> are expected to fail. Functionality can still be +verified by navigating to <ulink url="about:cache">about:cache</ulink> 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 +FQDN that was used to source the third party element. + </para> </listitem> <listitem>HTTP Auth @@ -871,14 +909,14 @@ observer to modify it. <listitem>DOM Storage <para><command>Design Goal:</command> -DOM storage for third party domains MUST BE isolated to the url bar domain, +DOM storage for third party domains MUST BE isolated to the url bar origin, to prevent linkability between sites. </para> <para><command>Implementation Status:</command> 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. +origin, we entirely disable DOM storage as a stopgap to ensure unlinkability. </para> </listitem> @@ -890,9 +928,9 @@ arrive on the same TCP connection. </para> <para><command>Design Goal:</command> -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. +TLS session resumption IDs must be limited to the url bar origin. +HTTP Keep-Alive connections from a third party in one url bar origin must +not be reused for that same third party in another url bar origin. </para> <para><command>Implementation Status:</command> @@ -902,7 +940,28 @@ disable</ulink> TLS session resumption, and limit HTTP Keep-alive duration. </para> </listitem> - <listitem>window.name + + <listitem>User Confirmation for cross-domain redirects + <para> + + <!-- + +XXX: Cross-domain redirects should prompt. +https://trac.torproject.org/projects/tor/ticket/3600 + +XXX: + +Not concerned with explicit user interaction because it is assumed that +private browsing sessions will be relatively short-lived with frequent use of +the "New Identity" button. + +--> + </para> + <para><command>Design Goal:</command> + </para> + <para><command>Implementation Status:</command> + </para> + <listitem>window.name <para> <ulink @@ -949,7 +1008,7 @@ functionality. 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. <ulink +properties beyond any stored origin-related state. <ulink url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink> 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 @@ -1274,21 +1333,15 @@ 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. </para> - <para><command>Design Goal:</command> - -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. - - </para> </listitem> <listitem>Make Intermediate Cert Store memory-only <para> -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. +The intermediate certificate store records the intermediate SSL certificates +the browser has seen to date. Because these intermediate certificates are used +by a limited number of domains (and in some cases, only a single domain), +the intermediate certificate store can serve as a low-resolution record of +browsing history. </para> <!-- FIXME: Should this be a <note> tag too? --> @@ -1320,8 +1373,8 @@ security of cache isolation</ulink> and to <ulink url="https://trac.torproject.org/projects/tor/ticket/3754">solve strange and unknown conflicts with OCSP</ulink>, we had to <ulink url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src/current-patches/0005-Add-a-string-based-cacheKey.patch">patch -Firefox to provide a cacheDomain cache attribute</ulink>. We use the full -url bar domain as input to this field. +Firefox to provide a cacheDomain cache attribute</ulink>. We use the url bar +FQDN as input to this field. </para> </listitem> @@ -1392,7 +1445,7 @@ other site prefs?). </sect3> <sect3> <title>Excluded Addons</title> - <!-- XXX: Adblock, RequestPolicy, ShareMeNot, priv3 --> + <!-- FIXME: Adblock, RequestPolicy, ShareMeNot, priv3 --> </sect3> <sect3> <title>Dangerous Addons</title> @@ -1434,7 +1487,6 @@ 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. - <!-- XXX: ip-check.info? --> <orderedlist> <listitem><ulink url="http://decloak.net/">Decloak.net</ulink> <para> @@ -1456,11 +1508,11 @@ and <ulink url="http://www.januspa.com/">JanusPA</ulink>. </para> </listitem> - <listitem><ulink url="https://www.jondos.de/en/anontest">JonDos + <listitem><ulink url="https://ip-check.info">JonDos AnonTest</ulink> <para> -The <ulink url="https://www.jondos.de">JonDos people</ulink> also provide an +The <ulink url="https://anonymous-proxy-servers.net/">JonDos people</ulink> 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. @@ -1482,7 +1534,7 @@ Analyzer</ulink> <para> The Privacy Analyzer provides a dump of all sorts of browser attributes and -settings that it detects, including some information on your origin IP +settings that it detects, including some information on your original 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.