tor-commits December 2011

tor-commits@lists.torproject.org

17 participants
533 discussions

[tor/master] Doxygenize the file-level documentation of transports.c.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 6d35f08e014cc750239b77e41aa8de9460c615bd Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Dec 16 11:01:56 2011 +0100 Doxygenize the file-level documentation of transports.c. --- src/or/transports.c | 155 +++++++++++++++++++++++++-------------------------- 1 files changed, 77 insertions(+), 78 deletions(-) diff --git a/src/or/transports.c b/src/or/transports.c index 06bc039..6ee4878 100644 --- a/src/or/transports.c +++ b/src/or/transports.c @@ -4,6 +4,83 @@ /** * \file transports.c * \brief Pluggable Transports related code. + * + * \details + * Each managed proxy is represented by a <b>managed_proxy_t</b>. + * Each managed proxy can support multiple transports. + * Each managed proxy gets configured through a multistep process. + * + * ::managed_proxy_list contains all the managed proxies this tor + * instance is supporting. + * In the ::managed_proxy_list there are ::unconfigured_proxies_n + * managed proxies that are still unconfigured. + * + * In every run_scheduled_event() tick, we attempt to launch and then + * configure the unconfiged managed proxies, using the configuration + * protocol defined in the 180_pluggable_transport.txt proposal. A + * managed proxy might need several ticks to get fully configured. + * + * When a managed proxy is fully configured, we register all its + * transports to the circuitbuild.c subsystem. At that point the + * transports are owned by the circuitbuild.c subsystem. + * + * When a managed proxy fails to follow the 180 configuration + * protocol, it gets marked as broken and gets destroyed. + * + * <b>In a little more detail:</b> + * + * While we are serially parsing torrc, we store all the transports + * that a proxy should spawn in its <em>transports_to_launch</em> + * element. + * + * When we finish reading the torrc, we spawn the managed proxy and + * expect {S,C}METHOD lines from its output. We add transports + * described by METHOD lines to its <em>transports</em> element, as + * transport_t structs. + * + * When the managed proxy stops spitting METHOD lines (signified by a + * '{S,C}METHODS DONE' message) we register all the transports + * collected to the circuitbuild.c subsystem. At this point, the + * pointers to transport_t can be transformed into dangling pointers + * at any point by the circuitbuild.c subsystem, and so we replace all + * transport_t pointers with strings describing the transport names. + * We can still go from a transport name to a transport_t using the + * fact that each transport name uniquely identifies a transport_t. + * + * <b>In even more detail, this is what happens when a SIGHUP + * occurs:</b> + * + * We immediately destroy all unconfigured proxies (We shouldn't have + * unconfigured proxies in the first place, except when SIGHUP rings + * immediately after tor is launched.). + * + * We mark all managed proxies and transports to signify that they + * must be removed if they don't contribute by the new torrc + * (we mark using the <b>marked_for_removal</b> element). + * We also mark all managed proxies to signify that they might need to + * be restarted so that they end up supporting all the transports the + * new torrc wants them to support (using the <b>got_hup</b> element). + * We also clear their <b>transports_to_launch</b> list so that we can + * put there the transports we need to launch according to the new + * torrc. + * + * We then start parsing torrc again. + * + * Everytime we encounter a transport line using a known pre-SIGHUP + * managed proxy, we cleanse that proxy from the removal mark. + * We also mark it as unconfigured so that on the next scheduled + * events tick, we investigate whether we need to restart the proxy + * so that it also spawns the new transports. + * If the post-SIGHUP <b>transports_to_launch</b> list is identical to + * the pre-SIGHUP one, it means that no changes were introduced to + * this proxy during the SIGHUP and no restart has to take place. + * + * During the post-SIGHUP torrc parsing, we unmark all transports + * spawned by managed proxies that we find in our torrc. + * We do that so that if we don't need to restart a managed proxy, we + * can continue using its old transports normally. + * If we end up restarting the proxy, we destroy and unregister all + * old transports from the circuitbuild.c subsystem. **/ #define PT_PRIVATE @@ -64,84 +141,6 @@ static smartlist_t *managed_proxy_list = NULL; /** Number of still unconfigured proxies. */ static int unconfigured_proxies_n = 0; -/** "The main idea is:" - - Each managed proxy is represented by a 'managed_proxy_t'. - Each managed proxy can support multiple transports. - Each managed proxy gets configured through a multistep process. - - 'managed_proxy_list' contains all the managed proxies this tor - instance is supporting. - In the 'managed_proxy_list' there are 'unconfigured_proxies_n' - managed proxies that are still unconfigured. - - In every run_scheduled_event() tick, we attempt to launch and then - configure the unconfiged managed proxies, using the configuration - protocol defined in the 180_pluggable_transport.txt proposal. A - managed proxy might need several ticks to get fully configured. - - When a managed proxy is fully configured, we register all its - transports to the circuitbuild.c subsystem. At that point the - transports are owned by the circuitbuild.c subsystem. - - When a managed proxy fails to follow the 180 configuration - protocol, it gets marked as broken and gets destroyed. - - "In a little more technical detail:" - - While we are serially parsing torrc, we store all the transports - that a proxy should spawn in its 'transports_to_launch' element. - - When we finish reading the torrc, we spawn the managed proxy and - expect {S,C}METHOD lines from its output. We add transports - described by METHOD lines to its 'transports' element, as - 'transport_t' structs. - - When the managed proxy stops spitting METHOD lines (signified by a - '{S,C}METHODS DONE' message) we register all the transports - collected to the circuitbuild.c subsystem. At this point, the - 'transport_t's can be transformed into dangling pointers at any - point by the circuitbuild.c subsystem, and so we replace all - 'transport_t's with strings describing the transport names. We - can still go from a transport name to a 'transport_t' using the - fact that transport names uniquely identify 'transport_t's. - - "In even more technical detail I shall describe what happens when - the SIGHUP bell tolls:" - - We immediately destroy all unconfigured proxies (We shouldn't have - unconfigured proxies in the first place, except when SIGHUP rings - immediately after tor is launched.). - - We mark all managed proxies and transports to signify that they - must be removed if they don't contribute by the new torrc - (marked_for_removal). - We also mark all managed proxies to signify that they might need - to be restarted so that they end up supporting all the transports - the new torrc wants them to support (got_hup). - We also clear their 'transports_to_launch' list so that we can put - there the transports we need to launch according to the new torrc. - - We then start parsing torrc again. - - Everytime we encounter a transport line using a known pre-SIGHUP - managed proxy, we cleanse that proxy from the removal mark. - - We also mark it as unconfigured so that on the next scheduled - events tick, we investigate whether we need to restart the proxy - so that it also spawns the new transports. - If the post-SIGHUP 'transports_to_launch' list is identical to the - pre-SIGHUP one, it means that no changes were introduced to this - proxy during the SIGHUP and no restart has to take place. - - During the post-SIGHUP torrc parsing, we unmark all transports - spawned by managed proxies that we find in our torrc. - We do that so that if we don't need to restart a managed proxy, we - can continue using its old transports normally. - If we end up restarting the proxy, we destroy and unregister all - old transports from the circuitbuild.c subsystem. -*/ - /** Return true if there are still unconfigured managed proxies. */ int pt_proxies_configuration_pending(void)

1 0

[tor/master] Merge remote-tracking branch 'asn-mytor/bug4726'
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 37504b5efae2e1423ec09eae6fc6d1e229987e3d Merge: 597e428 6d35f08 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sat Dec 17 12:49:15 2011 -0500 Merge remote-tracking branch 'asn-mytor/bug4726' src/or/transports.c | 155 +++++++++++++++++++++++++-------------------------- 1 files changed, 77 insertions(+), 78 deletions(-)

1 0

[tor/master] And a changes file for bug#4733
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 597e428df6fc973fa009cb67b3cced7b1e2c9bf9 Author: Peter Palfrader <peter(a)palfrader.org> Date: Sat Dec 17 11:30:30 2011 +0100 And a changes file for bug#4733 --- changes/bug4733 | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/changes/bug4733 b/changes/bug4733 new file mode 100644 index 0000000..672cfbc --- /dev/null +++ b/changes/bug4733 @@ -0,0 +1,6 @@ + o Minor fix: + test_util_spawn_background_ok() hardcoded the expected value + for ENOENT to 2. This isn't portable as error numbers are + platform specific, and particularly the hurd has ENOENT at + 0x40000002. Construct expected string at runtime, using the + correct value for ENOENT (closes: #4733). Bugfix on 0.2.3.1-alpha.

1 0

[tor/master] test_util_spawn_background_ok: fix expectation
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit f6b19ac79c348f732eb08405367d7a434f8d8f08 Author: Peter Palfrader <peter(a)palfrader.org> Date: Sat Dec 17 11:22:31 2011 +0100 test_util_spawn_background_ok: fix expectation test_util_spawn_background_ok() hardcoded the expected value for ENOENT to 2. This isn't portable as error numbers are platform specific, and particularly the hurd has ENOENT at 0x40000002. Construct expected string at runtime, using the correct value for ENOENT (closes: #4733). --- src/test/test_util.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/test/test_util.c b/src/test/test_util.c index f9b57d6..389e0a0 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1460,17 +1460,13 @@ test_util_spawn_background_ok(void *ptr) static void test_util_spawn_background_fail(void *ptr) { -#ifdef MS_WINDOWS const char *argv[] = {BUILDDIR "/src/test/no-such-file", "--test", NULL}; - const char *expected_out = "ERR: Failed to spawn background process " - "- code 9/2\n"; const char *expected_err = ""; + char expected_out[1024]; + char code[32]; +#ifdef MS_WINDOWS const int expected_status = PROCESS_STATUS_ERROR; #else - const char *argv[] = {BUILDDIR "/src/test/no-such-file", "--test", NULL}; - const char *expected_out = "ERR: Failed to spawn background process " - "- code 9/2\n"; - const char *expected_err = ""; /* TODO: Once we can signal failure to exec, set this to be * PROCESS_STATUS_ERROR */ const int expected_status = PROCESS_STATUS_RUNNING; @@ -1478,6 +1474,11 @@ test_util_spawn_background_fail(void *ptr) (void)ptr; + tor_snprintf(code, sizeof(code), "%x/%x", + 9 /* CHILD_STATE_FAILEXEC */ , ENOENT); + tor_snprintf(expected_out, sizeof(expected_out), + "ERR: Failed to spawn background process - code %12s\n", code); + run_util_spawn_background(argv, expected_out, expected_err, 255, expected_status); }

1 0

r25263: {website} Update TBB design doc. (website/trunk/projects/torbrowser/design)
by Mike Perry 17 Dec '11

17 Dec '11

Author: mikeperry Date: 2011-12-17 04:41:37 +0000 (Sat, 17 Dec 2011) New Revision: 25263 Modified: website/trunk/projects/torbrowser/design/index.html.en Log: Update TBB design doc. Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2011-12-17 04:14:56 UTC (rev 25262) +++ website/trunk/projects/torbrowser/design/index.html.en 2011-12-17 04:41:37 UTC (rev 25263) @@ -1,6 +1,6 @@ <?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">Dec 16 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2785164">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. Pr ivacy 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-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin 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. Cli ck-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="id2785164"></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>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">Dec 16 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2532509">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. Pr ivacy 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-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin 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. Cli ck-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="id2532509"></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>, @@ -447,7 +447,7 @@ 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="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">prevent the load of any plugins except +also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" target="_top">prevent the load of any plugins except for Flash and Gnash</a>. </p><p> @@ -473,13 +473,13 @@ 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="id2817563"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </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="id2564908"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> Tor Browser MUST (at user option) 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="id2815614"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2562959"></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. @@ -501,11 +501,11 @@ 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…" target="_top">prevent +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" 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…" target="_top">prevent +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" 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…" target="_top">prevent +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" 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 @@ -544,7 +544,7 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="id2799780"></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> + </p><div class="figure"><a id="id2547125"></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 origin might simplify the privacy @@ -584,7 +584,7 @@ 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 conflicts with OCSP relying the cacheKey property for reuse of POST requests</a>, we -had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…" target="_top">patch +had to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" target="_top">patch Firefox to provide a cacheDomain cache attribute</a>. We use the fully qualified url bar domain as input to this field. @@ -612,7 +612,7 @@ 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…" 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…" target="_top">patch +linkability between domains</a>. We also needed to <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" target="_top">patch Firefox to cause the headers to get added early enough</a> to allow the observer to modify it. @@ -849,7 +849,7 @@ 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…" target="_top">remove +<a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" 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> @@ -962,11 +962,11 @@ </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="id2802993"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2550338"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2782032"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2529377"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> First, Torbutton disables all open tabs and windows by tagging them and blocking them via the nsIContentPolicy, and then closes each tab and @@ -996,8 +996,7 @@ 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…" target="_top">current-patches -directory of the torbrowser git repository</a>. They are: +The set of patches we have against Firefox can be found in the <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.2:/src/current-pa…" 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> @@ -1070,8 +1069,34 @@ 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="id2776736"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2776743"></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="id2776760"></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> + </p></li><li class="listitem">Make Tor Browser exit when not launched from Vidalia + <p> +It turns out that on Windows 7 and later systems, the Taskbar attempts to +automatically learn the most frequent apps used by the user, and it recognizes +Tor Browser as a seperate app from Vidalia. This can cause users to try to +launch Tor Brower without Vidalia or a Tor instance running. Worse, the Tor +Browser will automatically find their default Firefox profile, and properly +connect directly without using Tor. This patch is a simple hack to cause Tor +Browser to immediately exit in this case. + + </p></li><li class="listitem">Disable SSL Session ID tracking + <p> + +This patch is a simple 1-line hack to prevent SSL connections from caching +(and then later transmitting) their Session IDs. There was no preference to +govern this behavior, so we had to hack it by altering the SSL new connection +defaults. + + </p></li><li class="listitem">Provide an observer event to close persistent connections + <p> + +This patch creates an observer event in the HTTP connection manager to close +all keep-alive connections that still happen to be open. This event is emitted +by the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New Identity</a> button. + + </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="id2524128"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2524142"></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="id2524152"></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"

1 0

r25262: {website} Update design doc. (website/trunk/projects/torbrowser/design)
by Mike Perry 17 Dec '11

17 Dec '11

Author: mikeperry Date: 2011-12-17 04:14:56 +0000 (Sat, 17 Dec 2011) New Revision: 25262 Modified: website/trunk/projects/torbrowser/design/index.html.en Log: Update design doc. Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2011-12-16 17:58:41 UTC (rev 25261) +++ website/trunk/projects/torbrowser/design/index.html.en 2011-12-17 04:14:56 UTC (rev 25262) @@ -1,12 +1,12 @@ <?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">Oct 19 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id3042393">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. Pr ivacy 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-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin 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. Cli ck-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="id3042393"></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>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">Dec 16 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2785164">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. Pr ivacy 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-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin 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. Cli ck-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="id2785164"></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.33-3. +current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5. </p><p> @@ -148,7 +148,7 @@ Also, Javascript can be used to query the user's timezone via the <code class="function">Date()</code> object, <a class="ulink" href="https://www.khronos.org/registry/webgl/specs/1.0/#5.13" target="_top">WebGL</a> can -reveal information about the video cart in use, and high precision timing +reveal information about the video card in use, and high precision timing information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU and interpreter speed</a>. In the future, new JavaScript features such as <a class="ulink" href="http://w3c-test.org/webperf/specs/ResourceTiming/" target="_top">Resource @@ -201,7 +201,7 @@ 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 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. +that cause us to prefer one browser over another. </p><p> @@ -221,8 +221,8 @@ 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. With -respect to platform support, security requirements are the minimum properties -in order for Tor to support the use of a web client platform. +respect to browser support, security requirements are the minimum properties +in order for Tor to support the use of a particular browser. </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="link" href="#proxy-obedience" title="3.1. Proxy Obedience"><span class="command"><strong>Proxy Obedience</strong></span></a><p>The browser @@ -246,19 +246,20 @@ use of the mode. In other words, the browser MUST NOT write or cause the operating system to write <span class="emphasis"><em>any information</em></span> 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 +must be able to ensure that secure deletion 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. However, due to permissions issues with access to swap, implementations MAY choose to leave -it out of scope, and/or leave it to the user to implement encrypted swap. +it out of scope, and/or leave it to the Operating System/platform to implement +ephemeral-keyed encrypted swap. </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. With respect to -platform support, privacy requirements are the set of properties that cause us -to prefer one platform over another. +browser support, privacy requirements are the set of properties that cause us +to prefer one browser over another. </p><p> @@ -277,7 +278,7 @@ interaction or approval. This requirement specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. The requirement does not apply to linkable information the user manually submits -to sites, or due information submitted during manual link traversal. This +to sites, or due to information submitted during manual link traversal. This functionality SHOULD NOT interfere with federated login in a substantial way. </p></li><li class="listitem"><a class="link" href="#fingerprinting-linkability" title="3.6. Cross-Origin Fingerprinting Unlinkability"><span class="command"><strong>Cross-Origin @@ -347,7 +348,7 @@ 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 +disabled in the mode</a> except as an opt-in basis. We SHOULD NOT load system-wide addons or plugins. </p><p> @@ -365,15 +366,16 @@ </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 +Plus</a>, <a class="ulink" href="http://requestpolicy.com/" target="_top">Request Policy</a>, +<a class="ulink" href="http://www.ghostery.com/about" target="_top">Ghostery</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 creates or installs will provide a wealth -of fingerprinting targets. +filter sets that each user creates or installs will provide a wealth of +fingerprinting targets. </p><p> @@ -390,7 +392,7 @@ 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. +high-risk features pending analysis, audit, and mitigation. </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> The Implementation section is divided into subsections, each of which @@ -462,17 +464,22 @@ <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…" target="_top"> provide the user with a popup</a> whenever the browser attempts to launch a helper app. + +Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is +filtered by this component. Unity was pre-fetching URLs without using the +browser's proxy settings during a drag action, even if the drop was ultimately +canceled by the user. </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="id3048300"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </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="id2817563"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> Tor Browser MUST (at user option) 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="id3052558"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2815614"></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. @@ -537,7 +544,7 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="id3051496"></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> + </p><div class="figure"><a id="id2799780"></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 origin might simplify the privacy @@ -632,56 +639,50 @@ We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">having difficulties</a> causing Flash player to use this settings -file on Windows. +file on Windows, so Flash remains difficult to enable. - </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> + </p></li><li class="listitem">SSL+TLS session resumption and HTTP Keep-Alive + <p><span class="command"><strong>Design Goal:</strong></span> -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. +TLS session resumption tickets and SSL Session 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. </p><p><span class="command"><strong>Implementation Status:</strong></span> -We currently clear TLS Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New -Identity</a>, but we have no origin restriction implementation as of yet. -We plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">disable TLS session -resumption</a>, and limit HTTP Keep-alive duration as stopgaps to limit -linkability until we can implement <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4100" target="_top">true origin -isolation</a> (the latter we feel will be fairly tricky). +We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New +Identity</a>, we disable TLS Session Tickets via the Firefox Pref +<span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session +IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…" target="_top">patch +to Firefox</a>. To compensate for the increased round trip latency from disabling +these performance optimizations, we also enable +<a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS +False Start</a> via the Firefox Pref +<span class="command"><strong>security.ssl.enable_false_start</strong></span>. + </p><p> - </p></li><li class="listitem">User confirmation for cross-origin redirects +Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive +web apps, and because of the difficulties of conveying urlbar origin +information down into the Firefox HTTP layer, as a compromise we currently +merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured +from the last packet read on the connection) using the Firefox preference +<span class="command"><strong>network.http.keep-alive.timeout</strong></span>. + + </p></li><li class="listitem">Automated cross-origin redirects MUST NOT store identifiers <p><span class="command"><strong>Design Goal:</strong></span> To prevent attacks aimed at subverting the Cross-Origin Identifier Unlinkability <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirement</a>, the browser -MUST prompt the user before following redirects that would cause the user to -automatically navigate between two different url bar origins. The prompt -SHOULD inform the user about the ability to use <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New Identity</a> to clear the linked identifiers -created by the redirect. +MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) +for cross-origin redirect intermediaries that do not prompt for user input. +For example, if a user clicks on a bit.ly url that redirects to a +doubleclick.net url that finally redirects to a cnn.com url, only cookies from +cnn.com should be retained after the redirect chain completes. -</p><p> - -To reduce the occurrence of warning fatigue, these warning messages MAY be limited -to automated redirect cycles only. For example, the automated redirect -sequence <span class="command"><strong>User Click -> t.co -> bit.ly -> cnn.com</strong></span> can be -assumed to be benign, but the redirect sequence <span class="command"><strong>User Click -> t.co -> -bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</strong></span> is -clearly due to tracking. Non-automated redirect cycles that require -user input at some step (such as federated login systems) need not be -interrupted by the UI. - </p><p> -We are not concerned with linkability due to explicit user action (either by -accepting cross-origin redirects, or by clicking normal links) because it is -assumed that private browsing sessions will be relatively short-lived, -especially with frequent use of the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New -Identity</a> button. +Non-automated redirect chains that require user input at some step (such as +federated login systems) SHOULD still allow identifiers to persist. </p><p><span class="command"><strong>Implementation status:</strong></span> @@ -961,24 +962,29 @@ </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="id3068567"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2802993"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id3057460"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2782032"></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, HSTS state, and the last opened URL field (via the pref -general.open_location.last_url). After clearing the browser state, we then +First, Torbutton disables all open tabs and windows by tagging them and +blocking them via the nsIContentPolicy, 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, HSTS state, close all remaining HTTP +keep-alive connections, and clear 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 class="blockquote"><blockquote class="blockquote"> +Additionally, the user is allowed to "protect" cookies of their choosing from +deletion during New Identity by using the Torbutton Cookie Protections UI to +protect the cookies they would like to keep across New Identity invocations. </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 @@ -1064,7 +1070,7 @@ 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="id3033960"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id3033967"></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="id3033984"></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> + </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="id2776736"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2776743"></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="id2776760"></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

1 0

[torspec/master] add xxx-onion-nyms.txt to ideas/
by ioerror＠torproject.org 17 Dec '11

17 Dec '11

commit 06a4623955e4111553173c4d5210e55e8979e981 Author: Jacob Appelbaum <jacob(a)appelbaum.net> Date: Fri Dec 16 17:12:16 2011 -0800 add xxx-onion-nyms.txt to ideas/ --- proposals/ideas/xxx-onion-nyms.txt | 77 ++++++++++++++++++++++++++++++++++++ 1 files changed, 77 insertions(+), 0 deletions(-) diff --git a/proposals/ideas/xxx-onion-nyms.txt b/proposals/ideas/xxx-onion-nyms.txt new file mode 100644 index 0000000..e41ce3d --- /dev/null +++ b/proposals/ideas/xxx-onion-nyms.txt @@ -0,0 +1,77 @@ +Filename: xxx-onion-nyms.txt +Title: .onion nym system +Author: Arturo Filastò, Jacob Appelbaum +Created: 17 December 2011 +Status: Draft + +1. Intro and Motivation + + The main issue that prohibits the wide scale adoption of .onion addressing + is the fact that they are not human memorable. While Zooko's triangle says that + you can only have at most two of "memorable", "secure" and "global" it is + possible to build a simple nym mechanism that relies on the current .onion + addressing system. We define a basic registration system generally and also + it's particual application to the tor2web network. This is a very simple kind + of petname system for applications such as tor2web. + +2. Definitions + + These are the definitions of the actors involved in the process. + + Beppe - The owner of the Tor Hidden Service + User - A random user of Tor/tor2web + v2cbb2l4lsnpio4q.onion - The .onion address that Beppe is interested in registering + antani - The nym Beppe is interested in associating to v2cbb2l4lsnpio4q.onion + t2w - A tor2web node + + +3. Registration + + This is the process through which Beppe is able to make a registration for his chosen + nym. + +3.1 General implementation + + Beppe wishes to register "antani" to point to v2cbb2l4lsnpio4q.onion so he creates a + a TCP service listening on his .onion will respond with the string "reg antani" when + interrogated. The requester will make a lookup in his database to see if + "antani" is already registered. If it is not registered the "antani" <-> + v2cbb2l4lsnpio4q.onion mapping is created. A timestamp is added to the + database. + +3.2 Tor2web implementation + + Beppe creates a file called "onion.txt" containing the string "reg antani" and uploads + it to the root of his web server. When User visits v2cbb2l4lsnpio4q.tor2web.org the + t2w checks if his database contains a mapping with v2cbb2l4lsnpio4q.onion, if it does + not, it requests the http://v2cbb2l4lsnpio4q.onion/onion.txt file. + If the file exists t2w reads it and extracts the "antani" string. A lookup is made in + his database. If "antani" is not registered he creates a mapping between "antani" and + v2cbb2l4lsnpio4q.onion. A timestamp is added to the database. + +4. Expiration + + A nym will expire if either the HS goes offline for longer than a given time + threshold or if he explicitly requests removal of the association to that + particualr nym. This allows dynamic reallocation of nyms and avoids nym + squatting. + +4.1 Time delay + + We define the default tiem threshold to be 30 days since the last check. At + the time of expiry or anytime before, another request is made to either the TCP + service or for the "onion.txt" file. If the Hidden Service is offline or if + the requested mapping has changed the mapping is removed or modified. If the + onion.txt is unchanged, the nym remains valid and the database timestamp + entry is updated. + + 4.2 Release + + The HS can specify the "release" string to delete the entry from the nym database. + +5. Synchronization + + To keep the database of registered nyms up to date in for many t2w nodes, a synchronization + mechanism is required but currently out of scope for this document. + +

1 0

[tor/master] Merge remote-tracking branch 'origin/maint-0.2.2'
by nickm＠torproject.org 16 Dec '11

16 Dec '11

commit d37cb8f74aa741cebe0001a4b56bd2bae539e225 Merge: 9df0bf7 cefff11 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 16 17:50:54 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.2'

1 0

[tor/master] Merge remote-tracking branch 'sebastian/clang-3.0-fixes_022' into maint-0.2.2
by nickm＠torproject.org 16 Dec '11

16 Dec '11

commit cefff11950d0b80de02bc956d5eb21ceeb81260c Merge: 562c974 bcca541 Author: Nick Mathewson <nickm(a)torproject.org> Date: Fri Dec 16 17:49:41 2011 -0500 Merge remote-tracking branch 'sebastian/clang-3.0-fixes_022' into maint-0.2.2 changes/clang_30_options | 5 +++++ configure.in | 10 ++++------ 2 files changed, 9 insertions(+), 6 deletions(-)

1 0

[tor/maint-0.2.2] Build with warnings and clang 3.0
by nickm＠torproject.org 16 Dec '11

16 Dec '11

commit bcca541da9f60d95fe7f0f7b3aa6ef4a8251b1e2 Author: Sebastian Hahn <sebastian(a)torproject.org> Date: Mon Dec 12 15:36:08 2011 +0100 Build with warnings and clang 3.0 --enable-gcc-warnings enables two warnings that clang doesn't support, so the build fails. We had hoped clang 3.0 would add those, but it didn't, so let's just always disable those warnings when building with clang. We can still fix it later once they add support --- changes/clang_30_options | 5 +++++ configure.in | 10 ++++------ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/changes/clang_30_options b/changes/clang_30_options new file mode 100644 index 0000000..e8e34c8 --- /dev/null +++ b/changes/clang_30_options @@ -0,0 +1,5 @@ + o Code simplifications and refactoring: + - During configure, detect when we're building with clang version 3.0 or + lower and disable the -Wnormalized=id and -Woverride-init CFLAGS. + clang doesn't support them yet. + diff --git a/configure.in b/configure.in index a9339cc..424cccb 100644 --- a/configure.in +++ b/configure.in @@ -940,10 +940,10 @@ if test x$enable_gcc_warnings = xyes || test x$enable_gcc_warnings_advisory = xy #error #endif])], have_gcc43=yes, have_gcc43=no) - AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [ -#if !defined(__clang__) || (__clang_major__ > 2) || (__clang_major__ == 2 && __clang_minor__ > 9) +AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [ +#if !defined(__clang__) #error -#endif])], have_clang29orlower=yes, have_clang29orlower=no) +#endif])], have_clang=yes, have_clang=no) save_CFLAGS="$CFLAGS" CFLAGS="$CFLAGS -Wshorten-64-to-32" @@ -980,10 +980,8 @@ if test x$enable_gcc_warnings = xyes || test x$enable_gcc_warnings_advisory = xy # We used to use -Wstrict-overflow=5, but that breaks us heavily under 4.3. fi - if test x$have_gcc42 = xyes && test x$have_clang29orlower = xno; then + if test x$have_gcc42 = xyes && test x$have_clang = xno; then # These warnings break gcc 4.0.2 and clang, but work on gcc 4.2 - # We only disable these for clang 2.9 and lower, in case they are - # supported in later versions. CFLAGS="$CFLAGS -Wnormalized=id -Woverride-init" fi

1 0

← Newer
1
...
26
27
28
29
30
31
32
...
54
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits December 2011