- tor-commits - lists.torproject.org

[obfsproxy/master] Add obfsproxy architecture draft.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 2a65bc2ac1a6257351291afc86fb95fd8bc1e480 Author: George Kadianakis <desnacked(a)gmail.com> Date: Tue Dec 13 14:44:11 2011 +0100 Add obfsproxy architecture draft. --- doc/obfsproxy_architecture.txt | 186 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 186 insertions(+), 0 deletions(-) diff --git a/doc/obfsproxy_architecture.txt b/doc/obfsproxy_architecture.txt new file mode 100644 index 0000000..05ee5eb --- /dev/null +++ b/doc/obfsproxy_architecture.txt @@ -0,0 +1,186 @@ +architecture + + : Top Level View + +obfsproxy is a pluggable transports proxy written in C. It's compliant +to the pluggable transports specification [0], and its modular +architecture allows it to support multiple pluggable transports. + +# It supports two modes of operation, the 'external proxy' mode and the +# 'managed proxy' mode. When used as an 'external proxy', the user +# configures obfsproxy using the command-line. When used as a 'managed +# proxy', obfsproxy can be configured by another application using the +# managed proxy configuration protocol defined in the pluggable +# transports specification [0]. + + : Modularity + +obfsproxy uses callbacks and object-oriented programming principles to +achieve modularity. This way, a developer who is interested in writing +a pluggable transport doesn't need to know obfsproxy's code inside +out. + +- Callbacks + + obfsproxy provides a set of callbacks that the plugin writer can use + to execute his transport's code, in an event-driven programming + fashion. + + As a basic example, there is a callback triggering when obfsproxy + receives network data. The plugin writer uses that callback to + retrieve and process data according to his pluggable transport + protocol. + +- OOP + + obfsproxy provides a set of base classes, representing networking + concepts, that the developer can inherit and populate with his + transport's data. + + As an example, the 'conn_t' structure represents a bidirectional + network connection between two peers. The pluggable transport writer + can inherit 'conn_t' and save his transport's state for that + connection to the new struct. + +Developers that make good use of obfsproxy's callbacks and OOP, should +be able to implement most pluggable transports. + + : Codebase tour + +This section does a short introduction into some areas of obfsproxy's +code. + +- Networking subsystem + +This section explains the networking concepts and terminology of +obfsproxy. The relevant code can be found in src/network.c. + +A 'connection' is a bidirectional communications channel, usually +backed by a network socket. For example, the communication channel +between tor and obfsproxy is a 'connection'. + +A 'circuit' is a pair of connections, referred to as the 'upstream' +and 'downstream' connections. The upstream connection of a circuit +communicates in cleartext with the higher-level program that wishes to +make use of our obfuscation service. The downstream connection +commmunicates in an obfuscated fashion with the remote peer that the +higher-level client wishes to contact. + +The diagram below might help demonstrate the relationship between +connections and circuits: + + downstream + + 'circuit_t C' 'conn_t CD' 'conn_t SD' 'circuit_t S' + +-----------+ +-----------+ + upstream ----|obfsproxy c|-------------|obfsproxy s|---- upstream + | +-----------+ +-----------+ | + 'conn_t CU'| |'conn_t SU' + +------------+ +--------------+ + | Tor Client | | Tor Bridge | + +------------+ +--------------+ + +In the above diagram, "obfsproxy c" is the client-side obfsproxy, and +"obfsproxy s" is the server-side obfsproxy. "conn_t CU" is the +Client's Upstream connection, the communication channel between tor +and obfsproxy. "conn_t CD" is the Client's Downstream connection, the +communication channel between obfsproxy and the remote peer. These two +connections form "circuit_t C". + +A 'listener' is a listening socket bound to a particular obfuscation +protocol. Connecting to a listener creates one connection of a +circuit, and causes this program to initiate the other connection +(possibly after receiving in-band instructions about where to connect +to). A listener is said to be a 'client' listener if connecting to it +creates the upstream connection, and a 'server' listener if connecting +to it creates the downstream connection. + +There are two kinds of client listeners: a 'simple' client listener +always connects to the same remote peer every time it needs to +initiate a downstream connection; a 'socks' client listener can be +told to connect to an arbitrary remote peer using the SOCKS protocol +(version 4 or 5). + +- Protocol subsystem + +Pluggable transports are called 'protocols' in obfsproxy +code. Protocol-specific code can be found in src/protocols/. + +src/protocol.c acts as an intermediary between generic obfsproxy code +and protocol-specific code. It wraps protocol-specific functions for +use by the rest of obfsproxy, and provides various protocol-related +functions. + +All supported protocols are registered to obfsproxy by adding them to +the supported_protocols[] array in src/protocol.c. + +- Cryptography subsystem + +The primary goal of pluggable transports is to obfuscate network +traffic. This means that most transports will need to use +cryptography. + +obfsproxy provides a cryptography subsystem for transports that need +it; the code can be found in src/crypt.c. It supports various +cryptographic operations, like hashing, symmetric encryption and +random-number generation. + + : Extending obfsproxy + +- Adding pluggable transports + +Ideally, this is the only thing you will ever want to add to +obfsproxy: your pluggable transport. A low-level guide on how to add +your own pluggable transport can be found in doc/HACKING. This is a +high level overview: + + * Write your pluggable transport, by writing code for the callback + events in protocol.c:protocol_vtable and by subclassing the base + classes of network.h and protocol.h. Look at doc/HACKING and at the + code of existing transports in src/protocols/. + + * Register your transport to the protocol subsystem by adding it to + the supported_protocols list in src/protocol.c. + + * Add all new files to the Makefile. + +- Extending callbacks + +obfsproxy's modularity is based on callbacks, and even though the +defaults should satisfy the needs of many plugin writers, it's +possible that some plugin writers will need to extend obfsproxy to +write their own callbacks. + +As an example, think of a plugin that needs to send fake data in the +absense of network activity: the current obfsproxy doesn't have a +callback for this scenario. The plugin writer would have to dive into +the networking subsystem of obfsproxy, write the callback triggering +code, register the new callback and finally write the code that +executes when the callback triggers. + +Depending on the scenario's complexity this might be a difficult task, +but there is not much that obfsproxy can do, since it's not possible +to have callbacks for any potentially useful scenario. + +- Extending crypto + +The current cryptography subsystem is made to order for the current +transports, and might not be sufficient for all transports. If a +transport needs more crypto, the plugin writer can add his own +cryptography functions to src/crypt.c. + +- Extending architecture logic + +obfsproxy tries to keep obfsproxy code and protocol-specific code as +disconnected as possible. This means that protocol-specific code +should know as little as possible about generic code internals, and +generic code should know nothing about protocol-specific code except +from what's exported through the protocol subsystem (src/protocol.[ch]). + +Plugin writers should not use their protocol-specific functions in +generic code, and should find a way to complete their task in the most +protocol-agnostic way possible. This helps keep both parts of the code +clean. + +[0]: +https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt

1 0

[obfsproxy/master] Replace old threat model doc. with a new one.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit d3afe7490775312101ede5879a8ebb75f995f59b Author: George Kadianakis <desnacked(a)gmail.com> Date: Tue Dec 13 14:39:22 2011 +0100 Replace old threat model doc. with a new one. --- doc/THREAT_MODEL | 19 ---------------- doc/obfs2_threat_model.txt | 50 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 19 deletions(-) diff --git a/doc/THREAT_MODEL b/doc/THREAT_MODEL deleted file mode 100644 index d973317..0000000 --- a/doc/THREAT_MODEL +++ /dev/null @@ -1,19 +0,0 @@ -obfs2 was created to work on top of the Tor protocol (and specifically -it's TLS handshake phase). Do not use obfs2 to obfuscate other -protocols, unless you are super-sure of what you are doing. - -A list follows, of known attacks that obfs2 protects or does not -protect against. obfs2 does not protect you against unknown attacks. - -Attacks obfs2 protects against: -* Non-intelligent DPI boxes censoring based on TLS content patterns. -* In the case of a shared secret, it also protects against intelligent DPI boxes. - -Attacks obfs2 does not protect against: -* Any distinguisher based on the Tor protocol. This includes timing, packet - size and replay attacks. -* Any distinguisher based on packet entropy. -* In the case of obfs2 without a shared secret, obfs2 does not protect - against an intelligent DPI box; a DPI box that simply deobfuscates - the obfs2 protocol (for those not familiar with the protocol: this - is quite easy.). diff --git a/doc/obfs2_threat_model.txt b/doc/obfs2_threat_model.txt new file mode 100644 index 0000000..08385ae --- /dev/null +++ b/doc/obfs2_threat_model.txt @@ -0,0 +1,50 @@ +threat model: + + Adversary capabilities: + +The adversary controls the infrastructure of the network within her +jurisdiction, and she can potentially monitor, block, alter, and +inject trafﬁc anywhere within this region. + +The censor also holds a blacklist of network protocols, which she is +interested in blocking. + + Adversary attacks: + +The censor passively monitors traffic and looks for content +signatures, in an attempt to distinguish network protocols. Upon +detecting a blacklisted protocol, the censor blocks the connection. + + Goals of obfs2: + +obfs2 attempts to counter the above attack by removing content +signatures from network traffic. obfs2 encrypts the traffic stream +with a stream cipher, which results in the traffic looking uniformly +random. + + Discussion: + +obfs2 shortcomings: + +obfs2 was designed as a pluggable transports proof-of-concept: it is +simple, useable and easily implementable. It does _not_ try to protect +against sophisticated adversaries: + +obfs2 does not try to protect against Tor protocol fingerprints, like +the packet size or packet timing. + +obfs2 does not try to protect against attackers capable of measuring +traffic entropy. + +obfs2 does not try to protect against Deep Packet Inspection machines +that expect the obfs2 protocol. Such machines can trivially retrieve +the decryption key off the traffic stream and use it to decrypt obfs2 +and detect the Tor protocol. + +In other words, obfs2 does not try to protect against anything other +than fingerprintable TLS content patterns. + +That said, obfs2 is not useless. It protects against many real-life +Tor traffic detection methods currentl deployed, since most of them +use static SSL handshake strings as signatures. +

1 0

[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