Mike Perry commited on 2011-12-17 05:14:56
Zeige 1 geänderte Dateien mit 74 Einfügungen und 68 Löschungen.
... | ... |
@@ -1,12 +1,12 @@ |
1 | 1 |
<?xml version="1.0" encoding="UTF-8"?> |
2 | 2 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
3 |
-<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. Privacy 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. Click-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id3042393"></a>1. Introduction</h2></div></div></div><p> |
|
3 |
+<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. Privacy 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. Click-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2785164"></a>1. Introduction</h2></div></div></div><p> |
|
4 | 4 |
|
5 | 5 |
This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, |
6 | 6 |
<a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, |
7 | 7 |
<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 |
8 | 8 |
procedures</a> of the Tor Browser. It is |
9 |
-current as of Tor Browser 2.2.33-3. |
|
9 |
+current as of Tor Browser 2.2.35-1 and Torbutton 1.4.5. |
|
10 | 10 |
|
11 | 11 |
</p><p> |
12 | 12 |
|
... | ... |
@@ -148,7 +148,7 @@ about the useragent. |
148 | 148 |
|
149 | 149 |
Also, Javascript can be used to query the user's timezone via the |
150 | 150 |
<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 |
151 |
-reveal information about the video cart in use, and high precision timing |
|
151 |
+reveal information about the video card in use, and high precision timing |
|
152 | 152 |
information can be used to <a class="ulink" href="http://w2spconf.com/2011/papers/jspriv.pdf" target="_top">fingerprint the CPU and |
153 | 153 |
interpreter speed</a>. In the future, new JavaScript features such as |
154 | 154 |
<a class="ulink" href="http://w3c-test.org/webperf/specs/ResourceTiming/" target="_top">Resource |
... | ... |
@@ -201,7 +201,7 @@ adversaries. |
201 | 201 |
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 |
202 | 202 |
minimum properties in order for a browser to be able to support Tor and |
203 | 203 |
similar privacy proxies safely. Privacy requirements are the set of properties |
204 |
-that cause us to prefer one browser platform over another. |
|
204 |
+that cause us to prefer one browser over another. |
|
205 | 205 |
|
206 | 206 |
</p><p> |
207 | 207 |
|
... | ... |
@@ -221,8 +221,8 @@ browser distribution. |
221 | 221 |
The security requirements are primarily concerned with ensuring the safe use |
222 | 222 |
of Tor. Violations in these properties typically result in serious risk for |
223 | 223 |
the user in terms of immediate deanonymization and/or observability. With |
224 |
-respect to platform support, security requirements are the minimum properties |
|
225 |
-in order for Tor to support the use of a web client platform. |
|
224 |
+respect to browser support, security requirements are the minimum properties |
|
225 |
+in order for Tor to support the use of a particular browser. |
|
226 | 226 |
|
227 | 227 |
</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 |
228 | 228 |
Obedience</strong></span></a><p>The browser |
... | ... |
@@ -246,19 +246,20 @@ or MUST provide a mechanism for rapid, complete removal of all evidence of the |
246 | 246 |
use of the mode. In other words, the browser MUST NOT write or cause the |
247 | 247 |
operating system to write <span class="emphasis"><em>any information</em></span> about the use |
248 | 248 |
of private browsing to disk outside of the application's control. The user |
249 |
-must be able to ensure that secure removal of the software is sufficient to |
|
249 |
+must be able to ensure that secure deletion of the software is sufficient to |
|
250 | 250 |
remove evidence of the use of the software. All exceptions and shortcomings |
251 | 251 |
due to operating system behavior MUST be wiped by an uninstaller. However, due |
252 | 252 |
to permissions issues with access to swap, implementations MAY choose to leave |
253 |
-it out of scope, and/or leave it to the user to implement encrypted swap. |
|
253 |
+it out of scope, and/or leave it to the Operating System/platform to implement |
|
254 |
+ephemeral-keyed encrypted swap. |
|
254 | 255 |
|
255 | 256 |
</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> |
256 | 257 |
|
257 | 258 |
The privacy requirements are primarily concerned with reducing linkability: |
258 | 259 |
the ability for a user's activity on one site to be linked with their activity |
259 | 260 |
on another site without their knowledge or explicit consent. With respect to |
260 |
-platform support, privacy requirements are the set of properties that cause us |
|
261 |
-to prefer one platform over another. |
|
261 |
+browser support, privacy requirements are the set of properties that cause us |
|
262 |
+to prefer one browser over another. |
|
262 | 263 |
|
263 | 264 |
</p><p> |
264 | 265 |
|
... | ... |
@@ -277,7 +278,7 @@ any other url bar origin by any third party automatically or without user |
277 | 278 |
interaction or approval. This requirement specifically applies to linkability |
278 | 279 |
from stored browser identifiers, authentication tokens, and shared state. The |
279 | 280 |
requirement does not apply to linkable information the user manually submits |
280 |
-to sites, or due information submitted during manual link traversal. This |
|
281 |
+to sites, or due to information submitted during manual link traversal. This |
|
281 | 282 |
functionality SHOULD NOT interfere with federated login in a substantial way. |
282 | 283 |
|
283 | 284 |
</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 @@ to reduce linkability. |
347 | 348 |
failure of Torbutton</a> was (and still is) the options panel. Each option |
348 | 349 |
that detectably alters browser behavior can be used as a fingerprinting tool. |
349 | 350 |
Similarly, all extensions <a class="ulink" href="http://blog.chromium.org/2010/06/extensions-in-incognito.html" target="_top">SHOULD be |
350 |
-disabled in the mode</a> except as an opt-in basis. We should not load |
|
351 |
+disabled in the mode</a> except as an opt-in basis. We SHOULD NOT load |
|
351 | 352 |
system-wide addons or plugins. |
352 | 353 |
|
353 | 354 |
</p><p> |
... | ... |
@@ -365,15 +366,16 @@ permissions can be written to disk. Otherwise, they should remain memory-only. |
365 | 366 |
</p></li><li class="listitem"><span class="command"><strong>No filters</strong></span><p> |
366 | 367 |
|
367 | 368 |
Filter-based addons such as <a class="ulink" href="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/" target="_top">AdBlock |
368 |
-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 |
|
369 |
+Plus</a>, <a class="ulink" href="http://requestpolicy.com/" target="_top">Request Policy</a>, |
|
370 |
+<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 |
|
369 | 371 |
avoided. We believe that these addons do not add any real privacy to a proper |
370 | 372 |
<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 |
371 | 373 |
prevented from tracking users between sites by the implementation. |
372 | 374 |
Filter-based addons can also introduce strange breakage and cause usability |
373 | 375 |
nightmares, and will also fail to do their job if an adversary simply |
374 | 376 |
registers a new domain or creates a new url path. Worse still, the unique |
375 |
-filter sets that each user creates or installs will provide a wealth |
|
376 |
-of fingerprinting targets. |
|
377 |
+filter sets that each user creates or installs will provide a wealth of |
|
378 |
+fingerprinting targets. |
|
377 | 379 |
|
378 | 380 |
</p><p> |
379 | 381 |
|
... | ... |
@@ -390,7 +392,7 @@ so is not recommended, as it will alter the browser request fingerprint. |
390 | 392 |
We believe that if we do not stay current with the support of new web |
391 | 393 |
technologies, we cannot hope to substantially influence or be involved in |
392 | 394 |
their proper deployment or privacy realization. However, we will likely disable |
393 |
-certain new features (where possible) pending analysis and audit. |
|
395 |
+high-risk features pending analysis, audit, and mitigation. |
|
394 | 396 |
</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> |
395 | 397 |
|
396 | 398 |
The Implementation section is divided into subsections, each of which |
... | ... |
@@ -462,17 +464,22 @@ component to |
462 | 464 |
<a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components/external-app-blocker.js" target="_top"> |
463 | 465 |
provide the user with a popup</a> whenever the browser attempts to |
464 | 466 |
launch a helper app. |
467 |
+ |
|
468 |
+Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is |
|
469 |
+filtered by this component. Unity was pre-fetching URLs without using the |
|
470 |
+browser's proxy settings during a drag action, even if the drop was ultimately |
|
471 |
+canceled by the user. |
|
465 | 472 |
</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> |
466 | 473 |
Tor Browser State is separated from existing browser state through use of a |
467 | 474 |
custom Firefox profile. Furthermore, plugins are disabled, which prevents |
468 | 475 |
Flash cookies from leaking from a pre-existing Flash directory. |
469 |
- </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"> |
|
476 |
+ </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"> |
|
470 | 477 |
Tor Browser MUST (at user option) prevent all disk records of browser activity. |
471 | 478 |
The user should be able to optionally enable URL history and other history |
472 | 479 |
features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the |
473 | 480 |
preferences interface</a>, we will likely just enable Private Browsing |
474 | 481 |
mode by default to handle this goal. |
475 |
- </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"> |
|
482 |
+ </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"> |
|
476 | 483 |
For now, Tor Browser blocks write access to the disk through Torbutton |
477 | 484 |
using several Firefox preferences. |
478 | 485 |
|
... | ... |
@@ -537,7 +544,7 @@ the url bar origin for which browser state exists, possibly with a |
537 | 544 |
context-menu option to drill down into specific types of state or permissions. |
538 | 545 |
An example of this simplification can be seen in Figure 1. |
539 | 546 |
|
540 |
- </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> |
|
547 |
+ </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> |
|
541 | 548 |
|
542 | 549 |
On the left is the standard Firefox cookie manager. On the right is a mock-up |
543 | 550 |
of how isolating identifiers to the URL bar origin might simplify the privacy |
... | ... |
@@ -632,56 +639,50 @@ settings manager</a>. |
632 | 639 |
|
633 | 640 |
We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3974" target="_top">having |
634 | 641 |
difficulties</a> causing Flash player to use this settings |
635 |
-file on Windows. |
|
642 |
+file on Windows, so Flash remains difficult to enable. |
|
636 | 643 |
|
637 |
- </p></li><li class="listitem">TLS session resumption and HTTP Keep-Alive |
|
638 |
- <p> |
|
639 |
-TLS session resumption and HTTP Keep-Alive MUST NOT allow third party origins |
|
640 |
-to track users via either TLS session IDs, or the fact that different requests |
|
641 |
-arrive on the same TCP connection. |
|
642 |
- </p><p><span class="command"><strong>Design Goal:</strong></span> |
|
644 |
+ </p></li><li class="listitem">SSL+TLS session resumption and HTTP Keep-Alive |
|
645 |
+ <p><span class="command"><strong>Design Goal:</strong></span> |
|
643 | 646 |
|
644 |
-TLS session resumption IDs MUST be limited to the url bar origin. |
|
645 |
-HTTP Keep-Alive connections from a third party in one url bar origin must |
|
646 |
-not be reused for that same third party in another url bar origin. |
|
647 |
+TLS session resumption tickets and SSL Session IDs MUST be limited to the url |
|
648 |
+bar origin. HTTP Keep-Alive connections from a third party in one url bar |
|
649 |
+origin MUST NOT be reused for that same third party in another url bar origin. |
|
647 | 650 |
|
648 | 651 |
</p><p><span class="command"><strong>Implementation Status:</strong></span> |
649 | 652 |
|
650 |
-We currently clear TLS Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New |
|
651 |
-Identity</a>, but we have no origin restriction implementation as of yet. |
|
652 |
-We plan to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4099" target="_top">disable TLS session |
|
653 |
-resumption</a>, and limit HTTP Keep-alive duration as stopgaps to limit |
|
654 |
-linkability until we can implement <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/4100" target="_top">true origin |
|
655 |
-isolation</a> (the latter we feel will be fairly tricky). |
|
653 |
+We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New |
|
654 |
+Identity</a>, we disable TLS Session Tickets via the Firefox Pref |
|
655 |
+<span class="command"><strong>security.enable_tls_session_tickets</strong></span>. We disable SSL Session |
|
656 |
+IDs via a <a class="ulink" href="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/firefox/0010-Disable-SSL-Session-ID-tracking.patch" target="_top">patch |
|
657 |
+to Firefox</a>. To compensate for the increased round trip latency from disabling |
|
658 |
+these performance optimizations, we also enable |
|
659 |
+<a class="ulink" href="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00" target="_top">TLS |
|
660 |
+False Start</a> via the Firefox Pref |
|
661 |
+<span class="command"><strong>security.ssl.enable_false_start</strong></span>. |
|
662 |
+ </p><p> |
|
663 |
+ |
|
664 |
+Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive |
|
665 |
+web apps, and because of the difficulties of conveying urlbar origin |
|
666 |
+information down into the Firefox HTTP layer, as a compromise we currently |
|
667 |
+merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured |
|
668 |
+from the last packet read on the connection) using the Firefox preference |
|
669 |
+<span class="command"><strong>network.http.keep-alive.timeout</strong></span>. |
|
656 | 670 |
|
657 |
- </p></li><li class="listitem">User confirmation for cross-origin redirects |
|
671 |
+ </p></li><li class="listitem">Automated cross-origin redirects MUST NOT store identifiers |
|
658 | 672 |
<p><span class="command"><strong>Design Goal:</strong></span> |
659 | 673 |
|
660 | 674 |
To prevent attacks aimed at subverting the Cross-Origin Identifier |
661 | 675 |
Unlinkability <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy requirement</a>, the browser |
662 |
-MUST prompt the user before following redirects that would cause the user to |
|
663 |
-automatically navigate between two different url bar origins. The prompt |
|
664 |
-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 |
|
665 |
-created by the redirect. |
|
676 |
+MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) |
|
677 |
+for cross-origin redirect intermediaries that do not prompt for user input. |
|
678 |
+For example, if a user clicks on a bit.ly url that redirects to a |
|
679 |
+doubleclick.net url that finally redirects to a cnn.com url, only cookies from |
|
680 |
+cnn.com should be retained after the redirect chain completes. |
|
666 | 681 |
|
667 | 682 |
</p><p> |
668 | 683 |
|
669 |
-To reduce the occurrence of warning fatigue, these warning messages MAY be limited |
|
670 |
-to automated redirect cycles only. For example, the automated redirect |
|
671 |
-sequence <span class="command"><strong>User Click -> t.co -> bit.ly -> cnn.com</strong></span> can be |
|
672 |
-assumed to be benign, but the redirect sequence <span class="command"><strong>User Click -> t.co -> |
|
673 |
-bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</strong></span> is |
|
674 |
-clearly due to tracking. Non-automated redirect cycles that require |
|
675 |
-user input at some step (such as federated login systems) need not be |
|
676 |
-interrupted by the UI. |
|
677 |
- |
|
678 |
- </p><p> |
|
679 |
- |
|
680 |
-We are not concerned with linkability due to explicit user action (either by |
|
681 |
-accepting cross-origin redirects, or by clicking normal links) because it is |
|
682 |
-assumed that private browsing sessions will be relatively short-lived, |
|
683 |
-especially with frequent use of the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New |
|
684 |
-Identity</a> button. |
|
684 |
+Non-automated redirect chains that require user input at some step (such as |
|
685 |
+federated login systems) SHOULD still allow identifiers to persist. |
|
685 | 686 |
|
686 | 687 |
</p><p><span class="command"><strong>Implementation status:</strong></span> |
687 | 688 |
|
... | ... |
@@ -961,24 +962,29 @@ Currently we simply disable WebGL. |
961 | 962 |
</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> |
962 | 963 |
In order to avoid long-term linkability, we provide a "New Identity" context |
963 | 964 |
menu option in Torbutton. |
964 |
- </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"> |
|
965 |
+ </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"> |
|
965 | 966 |
|
966 | 967 |
All linkable identifiers and browser state MUST be cleared by this feature. |
967 | 968 |
|
968 |
- </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"> |
|
969 |
- |
|
970 |
- First, Torbutton disables all open tabs and windows via nsIContentPolicy |
|
971 |
-blocking, and then closes each tab and window. The extra step for blocking |
|
972 |
-tabs is done as a precaution to ensure that any asynchronous Javascript is in |
|
973 |
-fact properly disabled. After closing all of the windows, we then clear the |
|
974 |
-following state: OCSP (by toggling security.OCSP.enabled), cache, |
|
975 |
-site-specific zoom and content preferences, Cookies, DOM storage, safe |
|
976 |
-browsing key, the Google wifi geolocation token (if exists), HTTP auth, SSL |
|
977 |
-Session IDs, HSTS state, and the last opened URL field (via the pref |
|
969 |
+ </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"> |
|
970 |
+ |
|
971 |
+First, Torbutton disables all open tabs and windows by tagging them and |
|
972 |
+blocking them via the nsIContentPolicy, and then closes each tab and |
|
973 |
+window. The extra step for blocking tabs is done as a precaution to ensure |
|
974 |
+that any asynchronous Javascript is in fact properly disabled. After closing |
|
975 |
+all of the windows, we then clear the following state: OCSP (by toggling |
|
976 |
+security.OCSP.enabled), cache, site-specific zoom and content preferences, |
|
977 |
+Cookies, DOM storage, safe browsing key, the Google wifi geolocation token (if |
|
978 |
+exists), HTTP auth, SSL Session IDs, HSTS state, close all remaining HTTP |
|
979 |
+keep-alive connections, and clear the last opened URL field (via the pref |
|
978 | 980 |
general.open_location.last_url). After clearing the browser state, we then |
979 | 981 |
send the NEWNYM signal to the Tor control port to cause a new circuit to be |
980 | 982 |
created. |
981 | 983 |
|
984 |
+ </blockquote></div><div class="blockquote"><blockquote class="blockquote"> |
|
985 |
+Additionally, the user is allowed to "protect" cookies of their choosing from |
|
986 |
+deletion during New Identity by using the Torbutton Cookie Protections UI to |
|
987 |
+protect the cookies they would like to keep across New Identity invocations. |
|
982 | 988 |
</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> |
983 | 989 |
Some content types are too invasive and/or too opaque for us to properly |
984 | 990 |
eliminate their linkability properties. For these content types, we use |
... | ... |
@@ -1064,7 +1070,7 @@ ruin our day, and censorship filters). Hence we rolled our own. |
1064 | 1070 |
This patch prevents random URLs from being inserted into content-prefs.sqllite in |
1065 | 1071 |
the profile directory as content prefs change (includes site-zoom and perhaps |
1066 | 1072 |
other site prefs?). |
1067 |
- </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 class="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> |
|
1073 |
+ </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 class="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> |
|
1068 | 1074 |
|
1069 | 1075 |
The purpose of this section is to cover all the known ways that Tor browser |
1070 | 1076 |
security can be subverted from a penetration testing perspective. The hope |
1071 | 1077 |