tor-commits April 2015

tor-commits@lists.torproject.org

19 participants
1110 discussions

[translation/bridgedb] Update translations for bridgedb
by translation＠torproject.org 30 Apr '15

30 Apr '15

commit b160e77f737e34b1fba7a0ba94941d3ca6111cf3 Author: Translation commit bot <translation(a)torproject.org> Date: Thu Apr 30 12:45:03 2015 +0000 Update translations for bridgedb --- sv/LC_MESSAGES/bridgedb.po | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/sv/LC_MESSAGES/bridgedb.po b/sv/LC_MESSAGES/bridgedb.po index 4dd9bdf..12e8451 100644 --- a/sv/LC_MESSAGES/bridgedb.po +++ b/sv/LC_MESSAGES/bridgedb.po @@ -6,6 +6,7 @@ # Anders Jensen-Urstad <anders(a)unix.se>, 2014 # Emil Johansson <emil.a.johansson(a)gmail.com>, 2015 # GabSeb, 2014 +# Peter Michanek <peter(a)michanek.se>, 2015 # Petomatick <petomatick(a)hotmail.com>, 2011 # ph AA, 2015 # phst <transifex(a)sturman.se>, 2014 @@ -15,8 +16,8 @@ msgid "" msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: 'https://trac.torproject.org/projects/tor/newticket?component=BridgeDB&keywo…'POT-Creation-Date: 2015-03-19 22:13+0000\n" -"PO-Revision-Date: 2015-04-19 08:23+0000\n" -"Last-Translator: runasand <runa.sandvik(a)gmail.com>\n" +"PO-Revision-Date: 2015-04-30 12:41+0000\n" +"Last-Translator: Peter Michanek <peter(a)michanek.se>\n" "Language-Team: Swedish (http://www.transifex.com/projects/p/torproject/language/sv/)\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" @@ -210,7 +211,7 @@ msgid "" "To enter bridges into Tor Browser, first go to the %s Tor Browser download\n" "page %s and then follow the instructions there for downloading and starting\n" "Tor Browser." -msgstr "" +msgstr "För att ange bryggor i Tor Borwser, gå till nedladdningssidan %s Tor Browser %s och följ instruktionerna för att ladda ner och starta Tor Browser." #. TRANSLATORS: Please DO NOT translate "Tor". #: lib/bridgedb/strings.py:126

1 0

[webwml/master] Add delcert.exe as signature removal tool
by gk＠torproject.org 30 Apr '15

30 Apr '15

commit b5a2ec64a830e9011f91dc1c33b755cb0e8f682f Author: Georg Koppen <gk(a)torproject.org> Date: Thu Apr 30 08:09:52 2015 +0000 Add delcert.exe as signature removal tool --- docs/en/verifying-signatures.wml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/verifying-signatures.wml b/docs/en/verifying-signatures.wml index f05b60e..64fc5e3 100644 --- a/docs/en/verifying-signatures.wml +++ b/docs/en/verifying-signatures.wml @@ -218,10 +218,10 @@ <li>You should see a message like "Good signature from <DEVELOPER NAME>". If you don't, there is a problem. Try these steps again.</li> <li>If you want to verify a Windows Tor Browser package you need to first - strip off the authenticode signature of it. One tool that can be used for - this purpose is <a - href="http:/osslsigncode.sourceforge.net">osslsigncode</a>. Assuming you - have built it on a Linux computer you can enter + strip off the authenticode signature of it. Tools that can be used for + this purpose are <a href="http://osslsigncode.sourceforge.net">osslsigncode</a> and + <a href="http://forum.xda-developers.com/showthread.php?t=416175">delcert.exe</a>. + Assuming you have built e.g. <tt>osslsigncode</tt> on a Linux computer you can enter <pre>/path/to/your/osslsigncode remove-signature \ /path/to/your/<TOR BROWSER FILE NAME>.exe <TOR BROWSER FILE NAME>.exe</pre></li> <li>Now you can take the sha256sum of the Tor Browser package. On

1 0

[bridgedb/develop] Document descriptor parameter in Bridge.updateFromNetworkStatus().
by isis＠torproject.org 30 Apr '15

30 Apr '15

commit 7bd8f90d91226fe046fea15fe128614d669cb505 Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Apr 30 05:54:51 2015 +0000 Document descriptor parameter in Bridge.updateFromNetworkStatus(). --- lib/bridgedb/bridges.py | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lib/bridgedb/bridges.py b/lib/bridgedb/bridges.py index 5c0afd8..93b9fe9 100644 --- a/lib/bridgedb/bridges.py +++ b/lib/bridgedb/bridges.py @@ -1381,10 +1381,11 @@ class Bridge(BridgeBackwardsCompatibility): def updateFromNetworkStatus(self, descriptor): """Update this bridge's attributes from a parsed networkstatus - descriptor. + document. - :type ns: :api:`stem.descriptors.router_status_entry.RouterStatusEntry` - :param ns: + :type descriptor: + :api:`stem.descriptors.router_status_entry.RouterStatusEntry` + :param descriptor: The networkstatus document for this bridge. """ self.descriptors['networkstatus'] = descriptor

1 0

[bridgedb/develop] Remove duplicate Bridge.Flags.update() during descriptor parsing.
by isis＠torproject.org 30 Apr '15

30 Apr '15

commit 69a44c5494d76a330df96dcfd72c8fefe2e76614 Author: Isis Lovecruft <isis(a)torproject.org> Date: Thu Apr 30 06:11:36 2015 +0000 Remove duplicate Bridge.Flags.update() during descriptor parsing. --- lib/bridgedb/Main.py | 1 - 1 file changed, 1 deletion(-) diff --git a/lib/bridgedb/Main.py b/lib/bridgedb/Main.py index 116f827..44413d2 100644 --- a/lib/bridgedb/Main.py +++ b/lib/bridgedb/Main.py @@ -121,7 +121,6 @@ def load(state, splitter, clear=False): for router in networkstatuses: bridge = Bridge() bridge.updateFromNetworkStatus(router) - bridge.flags.update(router.flags) try: bridge.assertOK()

1 0

[webwml/master] Update Tor Browser Design Doc for 4.5.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit 0ab80d6a0fcd16a3041c2204f0bbacd58a8ba8d1 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Apr 29 22:25:35 2015 -0700 Update Tor Browser Design Doc for 4.5. --- projects/torbrowser/design/index.html.en | 566 ++++++++++++++++++------------ 1 file changed, 339 insertions(+), 227 deletions(-) diff --git a/projects/torbrowser/design/index.html.en b/projects/torbrowser/design/index.html.en index e063944..51f5fc0 100644 --- a/projects/torbrowser/design/index.html.en +++ b/projects/torbrowser/design/index.html.en @@ -1,9 +1,9 @@ <?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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">November 6th, 2014</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp59720528">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</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. Secu rity 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="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isol ation">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp60597904">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp60632800">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp60636736">5.3. Anonymous Verification</a></span></dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Tran sparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp60669376">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp59720528"></a>1. Introduction</h2></div></div></div><p> +<!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.78.1" /></head><body><div class="article"><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="a ffiliation"><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">April 30th, 2015</p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#idp51709072">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#components">1.1. Browser Component Overview</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. Securi ty 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="#adversary">3. Adversary Model</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary-goals">3.1. Adversary Goals</a></span></dt><dt><span class="sect2"><a href="#adversary-positioning">3.2. Adversary Capabilities - Positioning</a></span></dt><dt><span class="sect2"><a href="#attacks">3.3. Adversary Capabilities - Attacks</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">4. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">4.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">4.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">4.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolat ion">4.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">4.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">4.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">4.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#other-security">4.8. Other Security Measures</a></span></dt></dl></dd><dt><span class="sect1"><a href="#BuildSecurity">5. Build Security and Package Integrity</a></span></dt><dd><dl><dt><span class="sect2"><a href="#idp54108896">5.1. Achieving Binary Reproducibility</a></span></dt><dt><span class="sect2"><a href="#idp54129600">5.2. Package Signatures and Verification</a></span></dt><dt><span class="sect2"><a href="#idp54134112">5.3. Anonymous Verification</a></span></dt><dt><span class="sect2"><a href="#update-safety">5.4. Update Safety</a></span> </dt></dl></dd><dt><span class="appendix"><a href="#Transparency">A. Towards Transparency in Navigation Tracking</a></span></dt><dd><dl><dt><span class="sect1"><a href="#deprecate">A.1. Deprecation Wishlist</a></span></dt><dt><span class="sect1"><a href="#idp54168528">A.2. Promising Standards</a></span></dt></dl></dd></dl></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp51709072"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="3. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, and <a class="link" href="#Implementation" title="4. Implementation">implementation</a> of the Tor Browser. It is current as of Tor Browser -4.5-alpha-1. +4.5. </p><p> @@ -12,14 +12,20 @@ describe a reference implementation of a Private Browsing Mode that defends against active network adversaries, in addition to the passive forensic local adversary currently addressed by the major browsers. + </p><p> + +For more practical information regarding Tor Browser development, please +consult the <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking" target="_top">Tor +Browser Hacking Guide</a>. + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="components"></a>1.1. Browser Component Overview</h3></div></div></div><p> The Tor Browser is based on <a class="ulink" href="https://www.mozilla.org/en-US/firefox/organizations/" target="_top">Mozilla's Extended Support Release (ESR) Firefox branch</a>. We have a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git" target="_top">series of patches</a> against this browser to enhance privacy and security. Browser behavior is -additionally augmented through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/master" target="_top">Torbutton +additionally augmented through the <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/" target="_top">Torbutton extension</a>, though we are in the process of moving this functionality -into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-3…" target="_top">change +into direct Firefox patches. We also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-…" target="_top">change a number of Firefox preferences</a> from their defaults. </p><p> @@ -33,14 +39,14 @@ Instantbird, and XULRunner. To help protect against potential Tor Exit Node eavesdroppers, we include <a class="ulink" href="https://www.eff.org/https-everywhere" target="_top">HTTPS-Everywhere</a>. To provide users with optional defense-in-depth against Javascript and other -potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/refs/hea…" target="_top">several +potential exploit vectors, we also include <a class="ulink" href="http://noscript.net/" target="_top">NoScript</a>. We also modify <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-D…" target="_top">several extension preferences</a> from their defaults. </p><p> To provide censorship circumvention in areas where the public Tor network is blocked either by IP, or by protocol fingerprint, we include several <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableT…" target="_top">Pluggable -Transports</a> in the distribution. As of this writing, we include <a class="ulink" href="https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:…" target="_top">Obfsproxy</a>, +Transports</a> in the distribution. As of this writing, we include <a class="ulink" href="https://gitweb.torproject.org/pluggable-transports/obfs4.git" target="_top">Obfs4proxy</a>, <a class="ulink" href="https://trac.torproject.org/projects/tor/wiki/doc/meek" target="_top">meek</a>, <a class="ulink" href="https://fteproxy.org/" target="_top">FTE</a>, and <a class="ulink" href="https://crypto.stanford.edu/flashproxy/" target="_top">FlashProxy</a>. @@ -418,8 +424,6 @@ interpreter speed</a>. In the future, new JavaScript features such as Timing</a> may leak an unknown amount of network timing related information. - - </p></li><li class="listitem"><span class="command"><strong>Inserting Plugins</strong></span><p> The Panopticlick project found that the mere list of installed plugins (in @@ -552,7 +556,7 @@ Proxy obedience is assured through the following: </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Firefox proxy settings, patches, and build flags <p> -Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-3…" target="_top">Firefox +Our <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-…" target="_top">Firefox preferences file</a> sets the Firefox proxy settings to use Tor directly as a SOCKS proxy. It sets <span class="command"><strong>network.proxy.socks_remote_dns</strong></span>, <span class="command"><strong>network.proxy.socks_version</strong></span>, @@ -568,9 +572,9 @@ as set the pref <span class="command"><strong>media.peerconnection.enabled</stro </p><p> We also patch Firefox in order to provide several defense-in-depth mechanisms -for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8527bec0ad59fb3d88…" target="_top">patch +for proxy safety. Notably, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patch the DNS service</a> to prevent any browser or addon DNS resolution, and we -also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/04c046e11f6622f44c…" target="_top">patch +also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patch OCSP and PKIX code</a> to prevent any use of the non-proxied command-line tool utility functions from being functional while linked in to the browser. In both cases, we could find no direct paths to these routines in the browser, @@ -578,7 +582,7 @@ but it seemed better safe than sorry. </p><p> -During every Extended Support Release transition, we perform <a class="ulink" href="https://gitweb.torproject.org/tor-browser-spec.git/tree/HEAD:/audits" target="_top">in-depth +During every Extended Support Release transition, we perform <a class="ulink" href="https://gitweb.torproject.org/tor-browser-spec.git/tree/audits" target="_top">in-depth code audits</a> to verify that there were no system calls or XPCOM activity in the source tree that did not use the browser proxy settings. </p><p> @@ -590,7 +594,7 @@ geolocation queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, WebSockets, and live bookmark updates. We have also verified that IPv6 connections are not attempted, through the proxy or otherwise (Tor does not yet support IPv6). We have also verified that external protocol helpers, such -as smb urls and other custom protocol handlers are all blocked. +as SMB URLs and other custom protocol handlers are all blocked. </p></li><li class="listitem">Disabling plugins @@ -610,8 +614,10 @@ restricted from automatic load through Firefox's click-to-play preference In addition, to reduce any unproxied activity by arbitrary plugins at load time, and to reduce the fingerprintability of the installed plugin list, we -also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/2ecf6c33618ecee554…" target="_top"> -prevent the load of any plugins except for Flash and Gnash</a>. +also patch the Firefox source code to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top"> +prevent the load of any plugins except for Flash and Gnash</a>. Even for +Flash and Gnash, we also patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent loading them into the +address space</a> until they are explicitly enabled. </p></li><li class="listitem">External App Blocking and Drag Event Filtering <p> @@ -619,7 +625,7 @@ prevent the load of any plugins except for Flash and Gnash</a>. External apps can be induced to load files that perform network activity. Unfortunately, there are cases where such apps can be launched automatically with little to no user input. In order to prevent this, Torbutton installs a -component to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…" target="_top"> +component to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/external-ap…" target="_top"> provide the user with a popup</a> whenever the browser attempts to launch a helper app. @@ -629,7 +635,7 @@ Additionally, modern desktops now pre-emptively fetch any URLs in Drag and Drop events as soon as the drag is initiated. This download happens independent of the browser's Tor settings, and can be triggered by something as simple as holding the mouse button down for slightly too long while -clicking on an image link. We filter drag and drop events events <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob_plain/HEAD:/src/components…" target="_top">from +clicking on an image link. We filter drag and drop events events <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/components/external-ap…" target="_top">from Torbutton</a> before the OS downloads the URLs the events contained. </p></li><li class="listitem">Disabling system extensions and clearing the addon whitelist @@ -654,24 +660,24 @@ system-wide extensions (through the use of disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60374176"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>4.3. Disk Avoidance</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp53861360"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> The User Agent 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. - </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60375536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp53862720"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> We achieve this goal through several mechanisms. First, we set the Firefox Private Browsing preference <span class="command"><strong>browser.privatebrowsing.autostart</strong></span>. In addition, four 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/tor-browser.git/commitdiff/4ebc3cda4b704c0149…" target="_top">prevent -the permissions manager from recording HTTPS STS state</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8904bfc10cd537bd35…" target="_top">prevent -intermediate SSL certificates from being recorded</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/86f6bc9dc28b6f8d7e…" target="_top">prevent +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent +the permissions manager from recording HTTPS STS state</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent +intermediate SSL certificates from being recorded</a>, <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent the clipboard cache from being written to disk for large pastes</a>, and -<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d5da6f8b7de089335e…" target="_top">prevent +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent the content preferences service from recording site zoom</a>. We also had to disable the media cache with the pref <span class="command"><strong>media.cache_size</strong></span>, to prevent HTML5 videos from being written to the OS temporary directory, @@ -734,7 +740,7 @@ the url bar origin for which browser state exists, possibly with a context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="idp60398240"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="idp53885184"></a><p class="title"><strong>Figure 1. Improving the Privacy UI</strong></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="NewCookieManager.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> This example UI is a mock-up of how isolating identifiers to the URL bar origin can simplify the privacy UI for all data - not just cookies. Once @@ -761,59 +767,35 @@ unlinkability trumps that desire. </p></li><li class="listitem">Cache <p> -Cache is isolated to the url bar origin by using a technique pioneered by -Colin Jackson et al, via their work on <a class="ulink" href="http://www.safecache.com/" target="_top">SafeCache</a>. The technique re-uses the -<a class="ulink" href="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel" target="_top">nsICachingChannel.cacheKey</a> -attribute that Firefox uses internally to prevent improper caching and reuse -of HTTP POST data. - - </p><p> - -However, to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3666" target="_top">increase the -security of the isolation</a> and to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3754" target="_top">solve conflicts -with OCSP relying the cacheKey property for reuse of POST requests</a>, we -had to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/18dfd3064aff23a402…" target="_top">patch -Firefox to provide a cacheDomain cache attribute</a>. We use the fully -qualified url bar domain as input to this field, to avoid the complexities -of heuristically determining the second-level DNS name. - - </p><p> - - Furthermore, we chose a different -isolation scheme than the Stanford implementation. First, we decoupled the -cache isolation from the third party cookie attribute. Second, we use several -mechanisms to attempt to determine the actual location attribute of the -top-level window (to obtain the url bar FQDN) used to load the page, as -opposed to relying solely on the Referer property. - - </p><p> - -Therefore, <a class="ulink" href="http://crypto.stanford.edu/sameorigin/safecachetest.html" target="_top">the original -Stanford test cases</a> are expected to fail. Functionality can still be -verified by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and -viewing the key used for each cache entry. Each third party element should -have an additional "domain=string" property prepended, which will list the -FQDN that was used to source the third party element. +In Firefox, there are actually two distinct caching mechanisms: One for +general content (HTML, Javascript, CSS), and one specifically for images. The +content cache is isolated to the URL bar domain by <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">altering +each cache key</a> to include an additional ID that includes the URL bar +domain. This functionality can be observed by navigating to <a class="ulink" href="about:cache" target="_top">about:cache</a> and viewing the key used for each cache +entry. Each third party element should have an additional "id=string" +property prepended, which will list the FQDN that was used to source the third +party element. </p><p> Additionally, because the image cache is a separate entity from the content -cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/114cd22282f8b3cd6e…" target="_top">isolate +cache, we had to patch Firefox to also <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">isolate this cache per url bar domain</a>. </p></li><li class="listitem">HTTP Auth <p> -HTTP authentication tokens are removed for third party elements using the -<a class="ulink" href="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers" target="_top">http-on-modify-request -observer</a> to remove the Authorization headers to prevent <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…" target="_top">silent -linkability between domains</a>. +HTTP Authorization headers can be used by Javascript to encode <a class="ulink" href="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…" target="_top">silent +third party tracking identifiers</a>. To prevent this, we remove HTTP +authentication tokens for third party elements through a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patch +to nsHTTPChannel</a>. + </p></li><li class="listitem">DOM Storage <p> DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a -<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/973468a07fb9e7d999…" target="_top">patch +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patch to Firefox</a>. </p></li><li class="listitem">Flash cookies @@ -830,37 +812,83 @@ We are currently <a class="ulink" href="https://trac.torproject.org/projects/tor difficulties</a> causing Flash player to use this settings file on Windows, so Flash remains difficult to enable. - </p></li><li class="listitem">SSL+TLS session resumption, HTTP Keep-Alive and SPDY + </p></li><li class="listitem">SSL+TLS session resumption <p><span class="command"><strong>Design Goal:</strong></span> 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. +bar origin. </p><p><span class="command"><strong>Implementation Status:</strong></span> We currently clear SSL Session IDs upon <a class="link" href="#new-identity" title="4.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/tor-browser.git/commitdiff/5524ae43780e473831…" target="_top">patch +IDs via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" 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">IP address, Tor Circuit, and HTTP Keep-Alive linkability + <p> + +IP addresses, Tor Circuits, and HTTP 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> + +This isolation functionality is provided by the combination of a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">Firefox +patch to allow SOCKS username and passwords</a>, as well as a Torbutton +component that <a class="ulink" href="" target="_top">sets +the SOCKS username and password for each request</a>. The Tor client has +logic to prevent connections with different SOCKS usernames and passwords from +using the same Tor Circuit, which provides us with IP address unlinkability. +Firefox has existing logic to ensure that connections with SOCKS proxy do not +re-use existing HTTP Keep Alive connections unless the proxy settings match. +We extended this logic to cover SOCKS username and password authentication, +providing us with HTTP Keep-Alive unlinkability. + + </p></li><li class="listitem">SharedWorkers + <p> + +<a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker" target="_top">SharedWorkers</a> +are a special form of Javascript Worker Threads that have a shared scope +between all threads from the same Javascript origin. + </p><p><span class="command"><strong>Design Goal:</strong></span> + +SharedWorker scope MUST be isolated to the URL bar domain. A SharedWorker +launched from a third party from one URL bar domain MUST NOT have access to +the objects created by that same third party loaded under another URL bar domain. -Because 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><p><span class="command"><strong>Implementation Status:</strong></span> + +For now, we disable SharedWorkers via the pref +<span class="command"><strong>dom.workers.sharedWorkers.enabled</strong></span>. + + </p></li><li class="listitem">blob: URIs (URL.createObjectURL) + <p> + +The <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL" target="_top">URL.createObjectURL</a> +API allows a site to load arbitrary content into a random UUID that is stored +in the user's browser, and this content can be accessed via a URL of the form +<span class="command"><strong>blob:UUID</strong></span> from any other content element anywhere on the +web. While this UUID value is neither under control of the site nor +predictable, it can still be used to tag a set of users that are of high +interest to an adversary. </p><p> -However, because SPDY can store identifiers and has extremely long keepalive -duration, it is disabled through the Firefox preference -<span class="command"><strong>network.http.spdy.enabled</strong></span>. + +URIs created with URL.createObjectURL MUST be limited in scope to the first +party URL bar domain that created them. We provide this isolation in Tor +Browser via a <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">direct +patch to Firefox</a>. + + </p></li><li class="listitem">SPDY + <p> + +Because SPDY can store identifiers, it is disabled through the +Firefox preference <span class="command"><strong>network.http.spdy.enabled</strong></span>. + </p></li><li class="listitem">Automated cross-origin redirects MUST NOT store identifiers <p><span class="command"><strong>Design Goal:</strong></span> @@ -932,65 +960,106 @@ the best approach. cleared by <a class="link" href="#new-identity" title="4.7. Long-Term Unlinkability via "New Identity" button">New Identity</a>, but we don't defend against the creation of these cookies between <span class="command"><strong>New Identity</strong></span> invocations. - </p></li><li class="listitem">Exit node usage - <p> - -All content elements associated with a given URL bar domain (including the -main page) are given a SOCKS username and password for this domain, which -causes Tor to isolate all of these requests on their own set of Tor circuits. - - </p></li></ol></div><p> + </p></li></ol></div><p> For more details on identifier linkability bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&am…" target="_top">tbb-linkability tag in our bugtracker</a> </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="fingerprinting-linkability"></a>4.6. Cross-Origin Fingerprinting Unlinkability</h3></div></div></div><p> -In order to properly address the fingerprinting adversary on a technical -level, we need a metric to measure linkability of the various browser -properties beyond any stored origin-related state. <a class="ulink" href="https://panopticlick.eff.org/about.php" target="_top">The Panopticlick Project</a> -by the EFF provides us with a prototype of such a metric. The researchers -conducted a survey of volunteers who were asked to visit an experiment page -that harvested many of the above components. They then computed the Shannon -Entropy of the resulting distribution of each of several key attributes to -determine how many bits of identifying information each attribute provided. - - </p><p> - -Unfortunately, there are limitations to the way the Panopticlick study was -conducted. Because the Panopticlick dataset is based on browser data spanning -a number of widely deployed browsers over a number of years, any -fingerprinting defenses attempted by browsers today are very likely to cause -Panopticlick to report an <span class="emphasis"><em>increase</em></span> in fingerprintability -and entropy, because those defenses will stand out in sharp contrast to -historical data. Moreover, because fingerprinting is a problem that -potentially touches every aspect of the browser, we do not believe it is -possible to solve cross-browser fingerprinting issues. We reduce the efforts -for fingerprinting resistance by only concerning ourselves with reducing the -fingerprintable differences <span class="emphasis"><em>among</em></span> Tor Browser users. +Browser fingerprinting is the act of inspecting browser behaviors and features in +an attempt to differentiate and track individual users. Fingerprinting attacks +are typically broken up into passive and active vectors. Passive +fingerprinting makes use of any information the browser provides automatically +to a website without any specific action on the part of the website. Active +fingerprinting makes use of any information that can be extracted from the +browser by some specific website action, usually involving Javascript. +Some definitions of browser fingerprinting also include supercookies and +cookie-like identifier storage, but we deal with those issues separately in +the <a class="link" href="#identifier-linkability" title="4.5. Cross-Origin Identifier Unlinkability">preceding section on identifier +linkability</a>. </p><p> -The unsolvable nature of the cross-browser fingerprinting problem also means -that the Panopticlick test website itself is not useful for evaluating the -actual effectiveness of our defenses, or the fingerprinting defenses of any -other web browser. We are interested in deploying an improved version of -Panopticlick that measures entropy and variance only among a specific user -agent population, but until then, intuition serves as a decent guide. -Essentially, anything that reveals custom user configuration, third party -software, highly variable hardware details, and external devices attached to -the users computer is likely to more fingerprintable than things like -operating system type and even processor speed. +For the most part, however, we do not differentiate between passive or active +fingerprinting sources, since many active fingerprinting mechanisms are very +rapid, and can be obfuscated or disguised as legitimate functionality. +Instead, we believe fingerprinting can only be rationally addressed if we +understand where the problem comes from, what sources of issues are the most +severe, and how to study the efficacy of defenses properly. + + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-scope"></a>Sources of Fingerprinting Issues</h4></div></div></div><p> + +All fingerprinting issues arise from one of four primary sources. In order +from most severe to least severe, these sources are: + + </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><span class="command"><strong>End-user Configuration Details</strong></span><p> + +End-user configuration details are by far the most severe threat to +fingerprinting, as they will quickly provide enough information to uniquely +identify a user. We believe it is essential to avoid exposing platform +configuration details to website content at all costs. We also discourage +excessive fine-grained customization of Tor Browser by minimizing and +aggregating user-facing privacy and security options, as well as by +discouraging the use of additional addons. When it is necessary to expose +configuration details in the course of providing functionality, we strive to +do so only on a per-site basis via site permissions, to avoid linkability. + + </p></li><li class="listitem"><span class="command"><strong>Device and Hardware Characteristics</strong></span><p> + +Device and hardware characteristics can be determined three ways: they can be +reported explicitly by the browser, they can be inferred through API behavior, +or they can be extracted through statistical measurements of system +performance. We are most concerned with the cases where this information is +either directly reported or can be determined via a single use of an API or +feature, and prefer to place such APIs either behind site permissions, or +disable them entirely. + </p><p> - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p> +On the other hand, because statistical inference of system performance +requires many iterations to achieve accuracy in the face of noise and +concurrent activity, we are less concerned with this mechanism of extracting +this information. We also expect that reducing the resolution of Javascript's +time sources will significantly increase the duration of execution required to +extract accurate results, and thus make statistical approaches both +unattractive and highly noticeable due to excessive resource consumption. + + </p></li><li class="listitem"><span class="command"><strong>Operating System Vendor and Version Differences</strong></span><p> + +Operating system vendor and version differences permeate many different +aspects of the browser. While it is possible to address these issues with some +effort, the relative lack of diversity in operating systems causes us to +primarily focus our efforts on passive operating system fingerprinting +mechanisms at this point in time. For the purposes of protecting user +anonymity, it is not strictly essential that the operating system be +completely concealed, though we recognize that it is useful to reduce this +differentiation ability where possible, especially for cases where the +specific version of a system can be inferred. + + </p></li><li class="listitem"><span class="command"><strong>Browser Vendor and Version Differences</strong></span><p> + +Due to vast differences in feature set and implementation behavior even +between different versions of the same browser, browser vendor and version +differences are simply not possible to conceal in any realistic way. It +is only possible to minimize the differences among different installations of +the same browser vendor and version. We make no effort to mimic any other +major browser vendor, and in fact most of our fingerprinting defenses serve to +differentiate Tor Browser users from normal Firefox users. Because of this, +any study that lumps browser vendor and version differences in to its analysis +of the fingerprintability of a population is largely useless for evaluating +either attacks or defenses. Unfortunately, this includes popular large-scale +studies such as <a class="ulink" href="https://panopticlick.eff.org/" target="_top">Panopticlick</a> and <a class="ulink" href="https://amiunique.org/" target="_top">Am I Unique</a>. + + </p></li></ol></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="fingerprinting-defenses"></a>Fingerprinting defenses in the Tor Browser</h4></div></div></div><p> The following defenses are listed roughly in order of most severe -fingerprinting threat first. This ordering is based on the above intuition that -user configurable aspects of the computer are the most severe source of -fingerprintability, though we are in need of updated measurements to determine -this with certainty. +fingerprinting threat first. This ordering is based on the above intuition +that user configurable aspects of the computer are the most severe source of +fingerprintability, followed by device characteristics and hardware, and then +finally operating system vendor and version information. </p><p> -Where our actual implementation differs from -an ideal solution, we separately describe our <span class="command"><strong>Design Goal</strong></span> -and our <span class="command"><strong>Implementation Status</strong></span>. + +Where our actual implementation differs from an ideal solution, we separately +describe our <span class="command"><strong>Design Goal</strong></span> and our <span class="command"><strong>Implementation +Status</strong></span>. </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem">Plugins <p> @@ -1017,8 +1086,9 @@ Currently, we entirely disable all plugins in Tor Browser. However, as a compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin -available, the rest are <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/1ef32dcf0cc64876f5…" target="_top">entirely -blocked from loading by a Firefox patch</a>. We also set the Firefox +available, the rest are entirely +blocked from loading by the Firefox patches mentioned in the <a class="link" href="#proxy-obedience" title="4.1. Proxy Obedience">Proxy Obedience +section</a>. We also set the Firefox preference <span class="command"><strong>plugin.expose_full_path</strong></span> to false, to avoid leaking plugin installation information. @@ -1041,13 +1111,12 @@ image can be used almost identically to a tracking cookie by the web server. In some sense, the canvas can be seen as the union of many other fingerprinting vectors. If WebGL is normalized through software rendering, system colors were standardized, and the browser shipped a fixed collection of -fonts (see later points in this list), it might not be necessary -to create a canvas permission. However, until then, to reduce the threat from -this vector, we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e6…" target="_top">prompt -before returning valid image data</a> to the Canvas APIs, and for <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6…" target="_top">access -to isPointInPath and related functions</a>. If the user hasn't previously -allowed the site in the URL bar to access Canvas image data, pure white image -data is returned to the Javascript APIs. +fonts (see later points in this list), it might not be necessary to create a +canvas permission. However, until then, to reduce the threat from this vector, +we have patched Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prompt +before returning valid image data</a> to the Canvas APIs. If the user +hasn't previously allowed the site in the URL bar to access Canvas image data, +pure white image data is returned to the Javascript APIs. </p><p> </p></li><li class="listitem">Open TCP Port Fingerprinting @@ -1055,22 +1124,25 @@ data is returned to the Javascript APIs. In Firefox, by using either WebSockets or XHR, it is possible for remote content to <a class="ulink" href="http://www.andlabs.org/tools/jsrecon.html" target="_top">enumerate -the list of TCP ports open on 127.0.0.1</a>. In other browsers, this can -be accomplished by DOM events on image or script tags. This open vs filtered -vs closed port list can provide a very unique fingerprint of a machine, -because it essentially enables the detection of many different popular third -party applications and optional system services (Skype, Bitcoin, Bittorrent -and other P2P software, SSH ports, SMB and related LAN services, CUPS and -printer daemon config ports, mail servers, and so on). It is also possible to -determine when ports are closed versus filtered/blocked (and thus probe -custom firewall configuration). - - </p><p>In Tor Browser, we prevent access to -127.0.0.1/localhost by ensuring that even these requests are still sent by -Firefox to our SOCKS proxy (ie we set +the list of TCP ports open on 127.0.0.1</a>, as well as on any other +machines on the local network. In other browsers, this can be accomplished by +DOM events on image or script tags. This open vs filtered vs closed port list +can provide a very unique fingerprint of a machine, because it essentially +enables the detection of many different popular third party applications and +optional system services (Skype, Bitcoin, Bittorrent and other P2P software, +SSH ports, SMB and related LAN services, CUPS and printer daemon config ports, +mail servers, and so on). It is also possible to determine when ports are +closed versus filtered/blocked (and thus probe custom firewall configuration). + + </p><p> + +In Tor Browser, we prevent access to 127.0.0.1/localhost by ensuring that even +these requests are still sent by Firefox to our SOCKS proxy (ie we set <span class="command"><strong>network.proxy.no_proxies_on</strong></span> to the empty string). The local Tor client then rejects them, since it is configured to proxy for internal IP -addresses by default. +addresses by default. Access to the local network is forbidden via the same +mechanism. + </p></li><li class="listitem">Invasive Authentication Mechanisms (NTLM and SPNEGO) <p> @@ -1127,7 +1199,7 @@ considerably larger than the combination of the Droid, Nanum, and Lohit fonts. In the meantime while we investigate shipping our own fonts, we disable plugins, which prevents font name enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of fonts that can -be used in a document <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/d515c79ffd115b132c…" target="_top">with +be used in a document <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">with a Firefox patch</a>. We create two prefs, <span class="command"><strong>browser.display.max_font_attempts</strong></span> and <span class="command"><strong>browser.display.max_font_count</strong></span> for this purpose. Once these @@ -1170,18 +1242,22 @@ this scheme. </p><p><span class="command"><strong>Implementation Status:</strong></span> - -We have implemented the above strategy using a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…" target="_top">resize -new windows based on desktop resolution</a>. Additionally, we patch -Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8fc2421becd0ab0cfb…" target="_top">for -window.screen</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/81e7fc3a10d27b1d8f…" target="_top">patch -DOM events to return content window relative points</a>. We also force +We automatically resize new browser windows to a 200x100 pixel multiple using +a window observer to <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutt…" target="_top">resize +new windows based on desktop resolution</a>. To minimize the effect of the +long tail of large monitor sizes, we also cap the the window size at 1000 +pixels in each direction. Additionally, we patch +Firefox to use the client content window size <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">for +window.screen</a>, and to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">report +a window.devicePixelRatio of 1.0</a>. Similarly, we <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patch +DOM events to return content window relative points</a>. We also + +We also force popups to open in new tabs (via <span class="command"><strong>browser.link.open_newwindow.restriction</strong></span>), to avoid full-screen popups inferring information about the browser resolution. In -addition, we prevent auto-maximizing on browser start, and are investigating a -user-friendly way of informing users that maximized windows are detrimental -to privacy in this mode. +addition, we prevent auto-maximizing on browser start, and inform users that +maximized windows are detrimental to privacy in this mode. </p></li><li class="listitem">Display Media information <p> @@ -1204,10 +1280,10 @@ details such as screen orientation or type. </p><p><span class="command"><strong>Implementation Status:</strong></span> We patch -Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/30dc2c4290698af81c…" target="_top">report -a fixed set of system colors to content window CSS</a>, and <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/8f6e979d30598569de…" target="_top">prevent -detection of font smoothing on Mac OS X</a>. We also always -<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9e…" target="_top">report +Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">report +a fixed set of system colors to content window CSS</a>, and <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">prevent +detection of font smoothing on OSX</a>. We also always +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">report landscape-primary</a> for the screen orientation. </p></li><li class="listitem">WebGL @@ -1249,7 +1325,7 @@ these headers should remain identical across the population even when updated. 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/tor-browser.git/commitdiff/95cd0e8071aa1fe3f4…" target="_top">remove +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" 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">Locale Fingerprinting <p> @@ -1263,7 +1339,7 @@ completeness, we attempt to maintain this property. We set the fallback character set to set to windows-1252 for all locales, via <span class="command"><strong>intl.charset.default</strong></span>. We also patch Firefox to allow us to -<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/fe42a78575df7f460f…" target="_top">instruct +<a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">instruct the JS engine</a> to use en-US as its internal C locale for all Date, Math, and exception handling. @@ -1320,10 +1396,12 @@ large number of people. </p><p><span class="command"><strong>Implementation Status:</strong></span> -Currently, the only mitigation against performance fingerprinting is to +Currently, the our mitigation against performance fingerprinting is to disable <a class="ulink" href="http://www.w3.org/TR/navigation-timing/" target="_top">Navigation Timing</a> through the Firefox preference -<span class="command"><strong>dom.enable_performance</strong></span>. +<span class="command"><strong>dom.enable_performance</strong></span>, and to disable the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#Gecko-spe…" target="_top">Mozilla +Video Statistics</a> API extensions via the preference +<span class="command"><strong>media.video_stats.enabled</strong></span>. </p></li><li class="listitem">Keystroke Fingerprinting <p> @@ -1347,8 +1425,8 @@ characteristics of the operating system type may leak into content, and the comparatively low contribution of OS to overall entropy. In particular, there are likely to be many ways to measure the differences in widget size, scrollbar size, and other rendered details on a page. Also, directly exported -OS routines, such as the Math library, expose differences in their -implementations due to these results. +OS routines (such as those from the standard C math library) expose +differences in their implementations through their return values. </p><p><span class="command"><strong>Design Goal:</strong></span> @@ -1362,26 +1440,27 @@ tag on our bug tracker</a>. </p><p><span class="command"><strong>Implementation Status:</strong></span> -At least two HTML5 features have different implementation status across the -major OS vendors: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery -API</a> and the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network -Connection API</a>. We disable these APIs through the Firefox preferences -<span class="command"><strong>dom.battery.enabled</strong></span> and -<span class="command"><strong>dom.network.enabled</strong></span>. +At least three HTML5 features have different implementation status across the +major OS vendors and/or the underlying hardware: the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery" target="_top">Battery +API</a>, the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection" target="_top">Network +Connection API</a>, and the <a class="ulink" href="https://wiki.mozilla.org/Sensor_API" target="_top">Sensor API</a>. We disable these APIs through the Firefox preferences +<span class="command"><strong>dom.battery.enabled</strong></span>, +<span class="command"><strong>dom.network.enabled</strong></span>, and +<span class="command"><strong>device.sensors.enabled</strong></span>. - </p></li></ol></div></div><p> + </p></li></ol></div><p> For more details on fingerprinting bugs and enhancements, see the <a class="ulink" href="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…" target="_top">tbb-fingerprinting tag in our bug tracker</a> - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> + </p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>4.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. This context menu option is active if Torbutton can read the environment variables $TOR_CONTROL_PASSWD and $TOR_CONTROL_PORT. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60545136"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp54050880"></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"><div class="titlepage"><div><div><h4 class="title"><a id="idp60546384"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp54052128"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> First, Torbutton disables Javascript in all open tabs and windows by using both the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIDocSh…" target="_top">browser.docShell.allowJavascript</a> @@ -1409,8 +1488,13 @@ After the state is cleared, we then close all remaining HTTP keep-alive connections and then send the NEWNYM signal to the Tor control port to cause a new circuit to be created. </p><p> + Finally, a fresh browser window is opened, and the current browser window is -closed (this does not spawn a new Firefox process, only a new window). +closed (this does not spawn a new Firefox process, only a new window). Upon +the close of the final window, an unload handler is fired to invoke the <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Inter…" target="_top">garbage +collector</a>, which has the effect of immediately purging any blob:UUID +URLs that were created by website content via <a class="ulink" href="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL" target="_top">URL.createObjectURL</a>. + </p></blockquote></div><div class="blockquote"><blockquote class="blockquote"> If the user chose to "protect" any cookies by using the Torbutton Cookie Protections UI, those cookies are not cleared as part of the above. @@ -1423,45 +1507,58 @@ privacy and security issues. </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a id="security-slider"></a><span class="command"><strong>Security Slider</strong></span><p> In order to provide vulnerability surface reduction for users that need high -security, we have implemented a "Security Slider" that essentially represents a -tradeoff between usability and security. Using metrics collected from -Mozilla's bug tracker, we analyzed the vulnerability counts of core components, -and used <a class="ulink" href="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…" target="_top">information +security, we have implemented a "Security Slider" to allow users to make a +tradeoff between usability and security while minimizing the total number of +choices (to reduce fingerprinting). Using metrics collected from +Mozilla's bug tracker, we analyzed the vulnerability counts of core +components, and used <a class="ulink" href="https://github.com/iSECPartners/publications/tree/master/reports/Tor%20Brow…" target="_top">information gathered from a study performed by iSec Partners</a> to inform which features should be disabled at which security levels. </p><p> -The Security Slider consists of four positions. At the lowest security level -(the default), we disable -<span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span> for Latin locales, as -well as <span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span>. At the -medium-low level, we disable most Javascript JIT and related optimizations -(<span class="command"><strong>javascript.options.ion.content</strong></span>, -<span class="command"><strong>javascript.options.typeinference</strong></span>, -<span class="command"><strong>javascript.options.asmjs</strong></span>). We also make HTML5 media -click-to-play (<span class="command"><strong>noscript.forbidMedia</strong></span>), and disable WebAudio -(<span class="command"><strong>media.webaudio.enabled</strong></span>). At the medium-high level, we -disable the baseline JIT -(<span class="command"><strong>javascript.options.baselinejit.content</strong></span>), disable -Javascript entirely all elements that are loaded when the URL bar is not -HTTPS (<span class="command"><strong>noscript.globalHttpsWhitelist</strong></span>), and fully disable -graphite font rendering for all locales -(<span class="command"><strong>gfx.font_rendering.graphite.enable</strong></span>). At the highest level, -Javascript is fully disabled (<span class="command"><strong>noscript.global</strong></span>), as well as -all non-WebM HTML5 codecs (<span class="command"><strong>media.ogg.enabled</strong></span>, -<span class="command"><strong>media.opus.enabled</strong></span>, <span class="command"><strong>media.opus.enabled</strong></span>, -<span class="command"><strong>media.DirectShow.enabled</strong></span>, -<span class="command"><strong>media.wave.enabled</strong></span>, and -<span class="command"><strong>media.apple.mp3.enabled</strong></span>). - - </p></li><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p> +The Security Slider consists of four positions: + + </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><span class="command"><strong>Low</strong></span><p> + +At this security level, the preferences are the Tor Browser defaults. + + </p></li><li class="listitem"><span class="command"><strong>Medium-Low</strong></span><p> + +At this security level, we disable the ION JIT +(<span class="command"><strong>javascript.options.ion.content</strong></span>), TypeInference JIT +(<span class="command"><strong>javascript.options.typeinference</strong></span>), ASM.JS +(<span class="command"><strong>javascript.options.asmjs</strong></span>), WebAudio +(<span class="command"><strong>media.webaudio.enabled</strong></span>), MathML +(<span class="command"><strong>mathml.disabled</strong></span>), block remote JAR files +(<span class="command"><strong>network.jar.block-remote-files</strong></span>), and make HTML5 audio and +video click-to-play via NoScript (<span class="command"><strong>noscript.forbidMedia</strong></span>). + + </p></li><li class="listitem"><span class="command"><strong>Medium-High</strong></span><p> + +This security level inherits the preferences from the Medium-Low level, and +additionally disables the baseline JIT +(<span class="command"><strong>javascript.options.baselinejit.content</strong></span>), disables graphite +font rendering (<span class="command"><strong>gfx.font_rendering.graphite.enabled</strong></span>), and +only allows Javascript to run if it is loaded over HTTPS and the URL bar is +HTTPS (by setting <span class="command"><strong>noscript.global</strong></span> to false and +<span class="command"><strong>noscript.globalHttpsWhitelist</strong></span> to true). + + </p></li><li class="listitem"><span class="command"><strong>High</strong></span><p> + +This security level inherits the preferences from the Medium-Low and +Medium-High levels, and additionally disables remote fonts +(<span class="command"><strong>noscript.forbidFonts</strong></span>), completely disables Javascript (by +unsetting <span class="command"><strong>noscript.globalHttpsWhitelist</strong></span>), and disables SVG +images (<span class="command"><strong>svg.in-content.enabled</strong></span>). + + </p></li></ul></div></li><li class="listitem"><a id="traffic-fingerprinting-defenses"></a><span class="command"><strong>Website Traffic Fingerprinting Defenses</strong></span><p> <a class="link" href="#website-traffic-fingerprinting">Website Traffic Fingerprinting</a> is a statistical attack to attempt to recognize specific encrypted website activity. - </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60574784"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> + </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp54085840"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> We want to deploy a mechanism that reduces the accuracy of <a class="ulink" href="https://en.wikipedia.org/wiki/Feature_selection" target="_top">useful features</a> available for classification. This mechanism would either impact the true and false @@ -1483,8 +1580,8 @@ Congestion-Sensitive BUFLO</a>. It may be also possible to <a class="ulink" href defenses</a> such that they only use existing spare Guard bandwidth capacity in the Tor network, making them also effectively no-overhead. - </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp60581680"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> -Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…" target="_top">randomize + </p></blockquote></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="idp54092736"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"><p> +Currently, we patch Firefox to <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">randomize pipeline order and depth</a>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively @@ -1493,7 +1590,7 @@ off and reduce or eliminate the pipeline if this happens. These shortcomings and fallback behaviors are the primary reason that Google developed SPDY as opposed simply extending HTTP to improve pipelining. It turns out that we could actually deploy exit-side proxies that allow us to -<a class="ulink" href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-us…" target="_top">use +<a class="ulink" href="https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-using-sp…" target="_top">use SPDY from the client to the exit node</a>. This would make our defense not only free, but one that actually <span class="emphasis"><em>improves</em></span> performance. @@ -1535,7 +1632,7 @@ date. </p><p> -We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commitdiff/777695d09e3cff4c79…" target="_top">patched +We also make use of the in-browser Mozilla updater, and have <a class="ulink" href="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…" target="_top">patched the updater</a> to avoid sending OS and Kernel version information as part of its update pings. @@ -1548,7 +1645,7 @@ contend with. For this reason, we have deployed a build system that allows anyone to use our source code to reproduce byte-for-byte identical binary packages to the ones that we distribute. - </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60597904"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> + </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp54108896"></a>5.1. Achieving Binary Reproducibility</h3></div></div></div><p> The GNU toolchain has been working on providing reproducible builds for some time, however a large software project such as Firefox typically ends up @@ -1598,9 +1695,9 @@ The fix for this is to perform an additional sorting step on the input list for archives, but care must be taken to instruct libc and other sorting routines to use a fixed locale to determine lexicographic ordering, or machines with different locale settings will produce different sort results. We chose the -'C' locale for this purpose. We created wrapper scripts for <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">tar</a>, -<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">zip</a>, -and <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">DMG</a> +'C' locale for this purpose. We created wrapper scripts for <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…" target="_top">tar</a>, +<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…" target="_top">zip</a>, +and <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…" target="_top">DMG</a> to aid in reproducible archive creation. </p></li><li class="listitem">Uninitialized memory in toolchain/archivers @@ -1609,7 +1706,7 @@ to aid in reproducible archive creation. We ran into difficulties with both binutils and the DMG archive script using uninitialized memory in certain data structures that ended up written to disk. Our binutils fixes were merged upstream, but the DMG archive fix remains an -<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">independent +<a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/p…" target="_top">independent patch</a>. </p></li><li class="listitem">Fine-grained timestamps and timezone leaks @@ -1618,7 +1715,7 @@ patch</a>. The standard way of controlling timestamps in Gitian is to use libfaketime, which hooks time-related library calls to provide a fixed timestamp. However, due to our use of wine to run py2exe for python-based pluggable transports, -pyc timestamps had to be address with an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…" target="_top">helper +pyc timestamps had to be address with an additional <a class="ulink" href="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…" target="_top">helper script</a>. The timezone leaks were addressed by setting the <span class="command"><strong>TZ</strong></span> environment variable to UTC in our descriptors. @@ -1665,7 +1762,7 @@ unitialized memory</a> that only appear in LXC mode, as well as <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/12240" target="_top">oddities related to time-based dependency tracking</a> that only appear in LXC containers. - </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60632800"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> + </p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp54129600"></a>5.2. Package Signatures and Verification</h3></div></div></div><p> The build process produces a single sha256sums.txt file that contains a sorted list of the SHA-256 hashes of every package produced for that build version. Each @@ -1693,13 +1790,12 @@ consensus, and encoding the package hashes in the Bitcoin blockchain. </p><p> -At the time of this writing, we do not yet support native code signing for Mac -OS or Windows. Because these signatures are embedded in the actual packages, -and by their nature are based on non-public key material, providing native -code-signed packages while still preserving ease of reproducibility -verification has not yet been achieved. +The Windows releases are also signed by a hardware token provided by Digicert. +In order to verify package integrity, the signature must be stripped off using +the osslsigncode tool, as described on the <a class="ulink" href="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificat…" target="_top">Signature +Verification</a> page. - </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp60636736"></a>5.3. Anonymous Verification</h3></div></div></div><p> + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="idp54134112"></a>5.3. Anonymous Verification</h3></div></div></div><p> Due to the fact that bit-identical packages can be produced by anyone, the security of this build system extends beyond the security of the official @@ -1718,6 +1814,22 @@ the public builders/signers, hopefully using a pseudonym or our anonymous bug tracker account, to avoid revealing the fact that they are a build verifier. + </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="update-safety"></a>5.4. Update Safety</h3></div></div></div><p> + +We make use of the Firefox updater in order to provide automatic updates to +users. We make use of certificate pinning to ensure that update checks +be tampered with, and we sign the individual MAR update files with an offline +signing key. + + </p><p> + +The Firefox updater also has code to ensure that it can reliably access the +update server to prevent availability attacks, and complains to the user of 48 +hours go by without a successful response from the server. Additionally, we +use Tor's SOCKS username and password isolation to ensure that every new +request to the updater traverses a separate circuit, to avoid holdback attacks +by exit nodes. + </p></div></div><div class="appendix"><h2 class="title" style="clear: both"><a id="Transparency"></a>A. Towards Transparency in Navigation Tracking</h2><p> The <a class="link" href="#privacy" title="2.2. Privacy Requirements">privacy properties</a> of Tor Browser are based @@ -1815,7 +1927,7 @@ possible for us to <a class="ulink" href="https://trac.torproject.org/projects/t ourselves</a>, as they are comparatively rare and can be handled with site permissions. - </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp60669376"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> + </p></li></ol></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="idp54168528"></a>A.2. Promising Standards</h2></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><a class="ulink" href="http://web-send.org" target="_top">Web-Send Introducer</a><p> Web-Send is a browser-based link sharing and federated login widget that is designed to operate without relying on third-party tracking or abusing other @@ -1831,4 +1943,4 @@ not directly provide the link sharing capabilities that Web-Send does, it is a better solution to the privacy issues associated with federated login than Web-Send is. - </p></li></ol></div></div></div></div></body></html> + </p></li></ol></div></div></div></div></body></html> \ No newline at end of file

1 0

[tor-browser-spec/master] Add 4.5 TODOs; Fix gitweb links; Remove Cruft.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit 8d336aa7bf850567cc0b6f686421682f16ba0d0c Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Tue Apr 28 21:25:46 2015 -0700 Add 4.5 TODOs; Fix gitweb links; Remove Cruft. --- design-doc/design.xml | 449 ++++++++----------------------------------------- 1 file changed, 73 insertions(+), 376 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 16007f3..91d64cc 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -23,14 +23,9 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>November 6th, 2014</pubdate> + <pubdate>April 30th, 2015</pubdate> </articleinfo> - - <sect1> <title>Introduction</title> <para> @@ -40,7 +35,7 @@ This document describes the <link linkend="adversary">adversary model</link>, linkend="Implementation">implementation</link>  of the Tor Browser. It is current as of Tor Browser -4.5-alpha-1. +4.5. </para> <para> @@ -51,6 +46,8 @@ against active network adversaries, in addition to the passive forensic local adversary currently addressed by the major browsers. </para> + + <sect2 id="components"> <title>Browser Component Overview</title> <para> @@ -61,10 +58,10 @@ Support Release (ESR) Firefox branch</ulink>. We have a <ulink url="https://gitweb.torproject.org/tor-browser.git">series of patches</ulink> against this browser to enhance privacy and security. Browser behavior is additionally augmented through the <ulink -url="https://gitweb.torproject.org/torbutton.git/tree/master">Torbutton +url="https://gitweb.torproject.org/torbutton.git/tree/">Torbutton extension</ulink>, though we are in the process of moving this functionality into direct Firefox patches. We also <ulink -url="https://gitweb.torproject.org/tor-browser.git/blob/refs/heads/tor-browser-3…">change +url="https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/000-…">change a number of Firefox preferences</ulink> from their defaults. </para> @@ -83,7 +80,7 @@ To help protect against potential Tor Exit Node eavesdroppers, we include provide users with optional defense-in-depth against Javascript and other potential exploit vectors, we also include <ulink url="http://noscript.net/">NoScript</ulink>. We also modify <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/refs/hea…">several +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundle-D…">several extension preferences</ulink> from their defaults. </para> @@ -93,7 +90,7 @@ To provide censorship circumvention in areas where the public Tor network is blocked either by IP, or by protocol fingerprint, we include several <ulink url="https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableT…">Pluggable Transports</ulink> in the distribution. As of this writing, we include <ulink -url="https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/blob/HEAD:…">Obfsproxy</ulink>, +url="https://gitweb.torproject.org/pluggable-transports/obfs4.git">Obfs4proxy</ulink>, <ulink url="https://trac.torproject.org/projects/tor/wiki/doc/meek">meek</ulink>, <ulink url="https://fteproxy.org/">FTE</ulink>, and <ulink @@ -215,7 +212,8 @@ it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap. </para></listitem> - + +  + <listitem>Cookies <para><command>Design Goal:</command> @@ -1183,6 +1186,7 @@ unlinkability trumps that desire. <listitem>Cache <para> + Cache is isolated to the url bar origin by using a technique pioneered by Colin Jackson et al, via their work on <ulink url="http://www.safecache.com/">SafeCache</ulink>. The technique re-uses the @@ -1232,7 +1236,7 @@ FQDN that was used to source the third party element. Additionally, because the image cache is a separate entity from the content cache, we had to patch Firefox to also <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/114cd22282f8b3cd6e…">isolate +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">isolate this cache per url bar domain</ulink>. </para> @@ -1241,6 +1245,7 @@ this cache per url bar domain</ulink>. <para> HTTP authentication tokens are removed for third party elements using the + <ulink url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request observer</ulink> to remove the Authorization headers to prevent <ulink @@ -1254,7 +1259,7 @@ linkability between domains</ulink>. DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/973468a07fb9e7d999…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch to Firefox</ulink>. </para> @@ -1281,6 +1286,7 @@ file on Windows, so Flash remains difficult to enable. <listitem>SSL+TLS session resumption, HTTP Keep-Alive and SPDY <para><command>Design Goal:</command> + 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. @@ -1292,7 +1298,7 @@ We currently clear SSL Session IDs upon <link linkend="new-identity">New Identity</link>, we disable TLS Session Tickets via the Firefox Pref <command>security.enable_tls_session_tickets</command>. We disable SSL Session IDs via a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/5524ae43780e473831…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch to Firefox</ulink>. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable <ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS @@ -1422,6 +1428,7 @@ url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&am <title>Cross-Origin Fingerprinting Unlinkability</title> <para> + In order to properly address the fingerprinting adversary on a technical level, we need a metric to measure linkability of the various browser properties beyond any stored origin-related state. <ulink @@ -1482,6 +1489,9 @@ and our <command>Implementation Status</command>. </para> <orderedlist> + + + <listitem>Plugins <para> @@ -1510,9 +1520,10 @@ Currently, we entirely disable all plugins in Tor Browser. However, as a compromise due to the popularity of Flash, we allow users to re-enable Flash, and flash objects are blocked behind a click-to-play barrier that is available only after the user has specifically enabled plugins. Flash is the only plugin -available, the rest are <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/1ef32dcf0cc64876f5…">entirely -blocked from loading by a Firefox patch</ulink>. We also set the Firefox +available, the rest are entirely +blocked from loading by the Firefox patches mentioned in the <link +linkend="proxy-obedience">Proxy Obedience +section</link>. We also set the Firefox preference <command>plugin.expose_full_path</command> to false, to avoid leaking plugin installation information. @@ -1540,15 +1551,13 @@ image can be used almost identically to a tracking cookie by the web server. In some sense, the canvas can be seen as the union of many other fingerprinting vectors. If WebGL is normalized through software rendering, system colors were standardized, and the browser shipped a fixed collection of -fonts (see later points in this list), it might not be necessary -to create a canvas permission. However, until then, to reduce the threat from -this vector, we have patched Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/3b53f525cfb68880e6…">prompt -before returning valid image data</ulink> to the Canvas APIs, and for <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/fb9f463fe3a69499d6…">access -to isPointInPath and related functions</ulink>. If the user hasn't previously -allowed the site in the URL bar to access Canvas image data, pure white image -data is returned to the Javascript APIs. +fonts (see later points in this list), it might not be necessary to create a +canvas permission. However, until then, to reduce the threat from this vector, +we have patched Firefox to <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prompt +before returning valid image data</ulink> to the Canvas APIs. If the user +hasn't previously allowed the site in the URL bar to access Canvas image data, +pure white image data is returned to the Javascript APIs. </para> <para> @@ -1647,7 +1656,7 @@ In the meantime while we investigate shipping our own fonts, we disable plugins, which prevents font name enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of fonts that can be used in a document <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/d515c79ffd115b132c…">with +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">with a Firefox patch</ulink>. We create two prefs, <command>browser.display.max_font_attempts</command> and <command>browser.display.max_font_count</command> for this purpose. Once these @@ -1665,6 +1674,7 @@ font (in any order), we use that font instead of any of the named local fonts. </para> </listitem> <listitem>Monitor, Widget, and OS Desktop Resolution + <para> Both CSS and Javascript have access to a lot of information about the screen @@ -1696,15 +1706,15 @@ this scheme. </para> <para><command>Implementation Status:</command> - + We have implemented the above strategy using a window observer to <ulink -url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize +url="https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutt…">resize new windows based on desktop resolution</ulink>. Additionally, we patch Firefox to use the client content window size <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/8fc2421becd0ab0cfb…">for +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">for window.screen</ulink>. Similarly, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/81e7fc3a10d27b1d8f…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch DOM events to return content window relative points</ulink>. We also force popups to open in new tabs (via <command>browser.link.open_newwindow.restriction</command>), to avoid @@ -1741,12 +1751,12 @@ details such as screen orientation or type. We patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/30dc2c4290698af81c…">report +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report a fixed set of system colors to content window CSS</ulink>, and <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/8f6e979d30598569de…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent detection of font smoothing on OSX</ulink>. We also always <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/09561f0e5452305b9e…">report +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report landscape-primary</ulink> for the screen orientation. </para> @@ -1797,7 +1807,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 <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/95cd0e8071aa1fe3f4…">remove +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">remove content script access</ulink> to Components.interfaces, which <ulink url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> @@ -1814,10 +1824,11 @@ completeness, we attempt to maintain this property. </para> <para><command>Implementation Status:</command> + We set the fallback character set to set to windows-1252 for all locales, via <command>intl.charset.default</command>. We also patch Firefox to allow us to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/fe42a78575df7f460f…">instruct +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">instruct the JS engine</ulink> to use en-US as its internal C locale for all Date, Math, and exception handling. @@ -1977,6 +1988,7 @@ All linkable identifiers and browser state MUST be cleared by this feature. <title>Implementation Status:</title> <blockquote> <para> + First, Torbutton disables Javascript in all open tabs and windows by using both the <ulink @@ -2063,6 +2075,8 @@ features should be disabled at which security levels. </para> <para> + + The Security Slider consists of four positions. At the lowest security level (the default), we disable <command>gfx.font_rendering.graphite.enabled</command> for Latin locales, as @@ -2135,7 +2149,7 @@ network, making them also effectively no-overhead. <blockquote> <para> Currently, we patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/27ef32d509ed1c9eeb…">randomize +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">randomize pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively @@ -2145,7 +2159,7 @@ shortcomings and fallback behaviors are the primary reason that Google developed SPDY as opposed simply extending HTTP to improve pipelining. It turns out that we could actually deploy exit-side proxies that allow us to <ulink -url="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-us…">use +url="https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-using-sp…">use SPDY from the client to the exit node</ulink>. This would make our defense not only free, but one that actually <emphasis>improves</emphasis> performance. @@ -2200,7 +2214,7 @@ date. <para> We also make use of the in-browser Mozilla updater, and have <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/777695d09e3cff4c79…">patched +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patched the updater</ulink> to avoid sending OS and Kernel version information as part of its update pings. @@ -2209,325 +2223,6 @@ of its update pings. </orderedlist> </sect2> - - </sect1>  In the age of state-sponsored malware, <ulink url="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…">we @@ -2629,11 +2325,11 @@ for archives, but care must be taken to instruct libc and other sorting routines to use a fixed locale to determine lexicographic ordering, or machines with different locale settings will produce different sort results. We chose the 'C' locale for this purpose. We created wrapper scripts for <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…">tar</ulink>, +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…">tar</ulink>, <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…">zip</ulink>, +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…">zip</ulink>, and <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…">DMG</ulink> +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…">DMG</ulink> to aid in reproducible archive creation. </para> @@ -2646,7 +2342,7 @@ We ran into difficulties with both binutils and the DMG archive script using uninitialized memory in certain data structures that ended up written to disk. Our binutils fixes were merged upstream, but the DMG archive fix remains an <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…">independent +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/p…">independent patch</ulink>. </para> @@ -2658,7 +2354,7 @@ The standard way of controlling timestamps in Gitian is to use libfaketime, which hooks time-related library calls to provide a fixed timestamp. However, due to our use of wine to run py2exe for python-based pluggable transports, pyc timestamps had to be address with an additional <ulink -url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi…">helper +url="https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/gitian/b…">helper script</ulink>. The timezone leaks were addressed by setting the <command>TZ</command> environment variable to UTC in our descriptors. @@ -2717,6 +2413,7 @@ time-based dependency tracking</ulink> that only appear in LXC containers. </sect2> <sect2> + <title>Package Signatures and Verification</title> <para>

1 0

[tor-browser-spec/master] Update identifier linkability section.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit 45aac71b4d114ca9e03e49a9c12fdb7cb11320ec Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Apr 29 02:27:05 2015 -0700 Update identifier linkability section. --- design-doc/design.xml | 126 ++++++++++++++++++++++++++++++++++++------------- 1 file changed, 93 insertions(+), 33 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 91d64cc..5a7ee28 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -47,7 +47,15 @@ adversary currently addressed by the major browsers. </para> - + <para> + +For more practical information regarding Tor Browser development, please +consult the <ulink +url="https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking">Tor +Browser Hacking Guide</ulink>. + + </para> + <sect2 id="components"> <title>Browser Component Overview</title> <para> @@ -213,13 +221,17 @@ ephemeral-keyed encrypted swap. </para></listitem> - - </orderedlist> </sect2> @@ -1161,8 +1173,6 @@ form history, login values, and so on within a context menu for each site. </caption> </figure> <orderedlist> - - <listitem>Cookies <para><command>Design Goal:</command> @@ -1283,13 +1293,11 @@ file on Windows, so Flash remains difficult to enable. </para> </listitem> - <listitem>SSL+TLS session resumption, HTTP Keep-Alive and SPDY + <listitem>SSL+TLS session resumption <para><command>Design Goal:</command> - 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. +bar origin. </para> <para><command>Implementation Status:</command> @@ -1305,20 +1313,82 @@ these performance optimizations, we also enable False Start</ulink> via the Firefox Pref <command>security.ssl.enable_false_start</command>. </para> - <para> + </listitem> + <listitem>IP address, Tor Circuit, and HTTP Keep-Alive linkability + <para> + +IP addresses, Tor Circuits, and HTTP connections from a third party in one URL +bar origin MUST NOT be reused for that same third party in another URL bar +origin. + </para> + <para> + +This isolation functionality is provided by the combination of a <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">Firefox +patch to allow SOCKS username and passwords</ulink>, as well as a Torbutton +component that <ulink +linkend="https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isol…">sets +the SOCKS username and password for each request</ulink>. The Tor client has +logic to prevent connections with different SOCKS usernames and passwords from +using the same Tor Circuit, which provides us with IP address unlinkability. +Firefox has existing logic to ensure that connections with SOCKS proxy do not +re-use existing HTTP Keep Alive connections unless the proxy settings match. +We extended this logic to cover SOCKS username and password authentication, +providing us with HTTP Keep-Alive unlinkability. + + </para> + </listitem> + <listitem>SharedWorkers + <para> + +<ulink +url="https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker">SharedWorkers</ulink> +are a special form of Javascript Worker Threads that have a shared scope +between all threads from the same Javascript origin. + </para> + <para><command>Design Goal:</command> + +SharedWorker scope MUST be isolated to the URL bar domain. A SharedWorker +launched from a third party from one URL bar domain MUST NOT have access to +the objects created by that same third party loaded under another URL bar domain. + + </para> + <para><command>Implementation Status:</command> + +For now, we disable SharedWorkers via the pref +<command>dom.workers.sharedWorkers.enabled</command>. + + </para> + </listitem> + <listitem>blob: URIs (URL.createObjectURL) + <para> + +The <ulink +url="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL">URL.createObjectURL</ulink> +API allows a site to load arbitrary content into a random UUID that is stored +in the user's browser, and this content can be accessed via a URL of the form +<command>blob:UUID</command> from any other content element anywhere on the +web. While this UUID value is neither under control of the site nor +predictable, it can still be used to tag a set of users that are of high +interest to an adversary. + + </para> + <para> -Because 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 -<command>network.http.keep-alive.timeout</command>. +URIs created with URL.createObjectURI MUST be limited in scope to the first +party URL bar domain that created them. We provide this isolation in Tor +Browser via a <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">direct +patch to Firefox</ulink>. </para> + </listitem> + <listitem>SPDY <para> -However, because SPDY can store identifiers and has extremely long keepalive -duration, it is disabled through the Firefox preference -<command>network.http.spdy.enabled</command>. + +Because SPDY can store identifiers, it is disabled through the +Firefox preference <command>network.http.spdy.enabled</command>. + </para> </listitem> <listitem>Automated cross-origin redirects MUST NOT store identifiers @@ -1409,15 +1479,6 @@ defend against the creation of these cookies between <command>New Identity</command> invocations. </para> </listitem> - <listitem>Exit node usage - <para> - -All content elements associated with a given URL bar domain (including the -main page) are given a SOCKS username and password for this domain, which -causes Tor to isolate all of these requests on their own set of Tor circuits. - - </para> - </listitem> </orderedlist> <para> For more details on identifier linkability bugs and enhancements, see the <ulink @@ -1489,7 +1550,6 @@ and our <command>Implementation Status</command>. </para> <orderedlist> -   <listitem>Plugins

1 0

[tor-browser-spec/master] The version file no longer needs to be updated immediately.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit b9b1014d531c793f7779b524240b1ef62dc72a1a Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Apr 29 22:02:40 2015 -0700 The version file no longer needs to be updated immediately. --- processes/ReleaseProcess | 1 - 1 file changed, 1 deletion(-) diff --git a/processes/ReleaseProcess b/processes/ReleaseProcess index f742047..925f3ce 100644 --- a/processes/ReleaseProcess +++ b/processes/ReleaseProcess @@ -103,7 +103,6 @@ static-update-component dist.torproject.org #. Update website's torbrowser versions file in the website git -# NOTE: This *must* be done immediately after the previous step! cd webwml torsocks git pull origin # Update `version-win32-stable` as well if we include a new stable tor

1 0

[tor-browser-spec/master] Update fingerprinting section and rework its introduction.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit 8bb3bb891c08073c8e1ec73682ca269bda47e3b9 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Apr 29 15:14:00 2015 -0700 Update fingerprinting section and rework its introduction. --- design-doc/design.xml | 377 ++++++++++++++++++++++++++++--------------------- 1 file changed, 218 insertions(+), 159 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 5a7ee28..5c16ce8 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -220,7 +220,8 @@ it out of scope, and/or leave it to the operating system/platform to implement ephemeral-keyed encrypted swap. </para></listitem> - + + </orderedlist> @@ -723,8 +725,6 @@ interpreter speed</ulink>. In the future, new JavaScript features such as Timing</ulink> may leak an unknown amount of network timing related information. - - </para> </listitem> @@ -923,10 +923,10 @@ as set the pref <command>media.peerconnection.enabled</command> to false. We also patch Firefox in order to provide several defense-in-depth mechanisms for proxy safety. Notably, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch the DNS service</ulink> to prevent any browser or addon DNS resolution, and we also <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch OCSP and PKIX code</ulink> to prevent any use of the non-proxied command-line tool utility functions from being functional while linked in to the browser. In both cases, we could find no direct paths to these routines in the browser, @@ -978,10 +978,10 @@ restricted from automatic load through Firefox's click-to-play preference In addition, to reduce any unproxied activity by arbitrary plugins at load time, and to reduce the fingerprintability of the installed plugin list, we also patch the Firefox source code to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…"> +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…"> prevent the load of any plugins except for Flash and Gnash</ulink>. Even for Flash and Gnash, we also patch Firefox to <ulink url= -"https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent loading them into the +"https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent loading them into the address space</ulink> until they are explicitly enabled. </para> @@ -1062,14 +1062,14 @@ Private Browsing preference Private Browsing Mode is enabled. We need to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent the permissions manager from recording HTTPS STS state</ulink>, <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent intermediate SSL certificates from being recorded</ulink>, <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent the clipboard cache from being written to disk for large pastes</ulink>, and <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent the content preferences service from recording site zoom</ulink>. We also had to disable the media cache with the pref <command>media.cache_size</command>, to prevent HTML5 videos from being written to the OS temporary directory, @@ -1196,57 +1196,23 @@ unlinkability trumps that desire. <listitem>Cache <para> - -Cache is isolated to the url bar origin by using a technique pioneered by -Colin Jackson et al, via their work on <ulink -url="http://www.safecache.com/">SafeCache</ulink>. The technique re-uses the -<ulink -url="https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsICachingChannel">nsICachingChannel.cacheKey</ulink> -attribute that Firefox uses internally to prevent improper caching and reuse -of HTTP POST data. - - </para> - <para> - -However, to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3666">increase the -security of the isolation</ulink> and to <ulink -url="https://trac.torproject.org/projects/tor/ticket/3754">solve conflicts -with OCSP relying the cacheKey property for reuse of POST requests</ulink>, we -had to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commitdiff/18dfd3064aff23a402…">patch -Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully -qualified url bar domain as input to this field, to avoid the complexities -of heuristically determining the second-level DNS name. - - </para> - <para> - - Furthermore, we chose a different -isolation scheme than the Stanford implementation. First, we decoupled the -cache isolation from the third party cookie attribute. Second, we use several -mechanisms to attempt to determine the actual location attribute of the -top-level window (to obtain the url bar FQDN) used to load the page, as -opposed to relying solely on the Referer property. - - </para> - <para> - -Therefore, <ulink -url="http://crypto.stanford.edu/sameorigin/safecachetest.html">the original -Stanford test cases</ulink> are expected to fail. Functionality can still be -verified by navigating to <ulink url="about:cache">about:cache</ulink> and -viewing the key used for each cache entry. Each third party element should -have an additional "domain=string" property prepended, which will list the -FQDN that was used to source the third party element. +In Firefox, there are actually two distinct caching mechanisms: One for +general content (HTML, Javascript, CSS), and one specifically for images. The +content cache is isolated to the URL bar domain by <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">altering +each cache key</ulink> to include an additional ID that includes the URL bar +domain. This functionality can be observed by navigating to <ulink +url="about:cache">about:cache</ulink> and viewing the key used for each cache +entry. Each third party element should have an additional "id=string" +property prepended, which will list the FQDN that was used to source the third +party element. </para> <para> Additionally, because the image cache is a separate entity from the content cache, we had to patch Firefox to also <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">isolate +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">isolate this cache per url bar domain</ulink>. </para> @@ -1254,13 +1220,13 @@ this cache per url bar domain</ulink>. <listitem>HTTP Auth <para> -HTTP authentication tokens are removed for third party elements using the - -<ulink -url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">http-on-modify-request -observer</ulink> to remove the Authorization headers to prevent <ulink +HTTP Authorization headers can be used by Javascript to encode <ulink url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…">silent -linkability between domains</ulink>. +third party tracking identifiers</ulink>. To prevent this, we remove HTTP +authentication tokens for third party elements through a <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +to nsHTTPChannel</ulink>. + </para> </listitem> <listitem>DOM Storage @@ -1269,7 +1235,7 @@ linkability between domains</ulink>. DOM storage for third party domains MUST be isolated to the url bar origin, to prevent linkability between sites. This functionality is provided through a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch to Firefox</ulink>. </para> @@ -1306,7 +1272,7 @@ We currently clear SSL Session IDs upon <link linkend="new-identity">New Identity</link>, we disable TLS Session Tickets via the Firefox Pref <command>security.enable_tls_session_tickets</command>. We disable SSL Session IDs via a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch to Firefox</ulink>. To compensate for the increased round trip latency from disabling these performance optimizations, we also enable <ulink url="https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00">TLS @@ -1324,7 +1290,7 @@ origin. <para> This isolation functionality is provided by the combination of a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">Firefox +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">Firefox patch to allow SOCKS username and passwords</ulink>, as well as a Torbutton component that <ulink linkend="https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isol…">sets @@ -1378,7 +1344,7 @@ interest to an adversary. URIs created with URL.createObjectURI MUST be limited in scope to the first party URL bar domain that created them. We provide this isolation in Tor Browser via a <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">direct +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">direct patch to Firefox</ulink>. </para> @@ -1487,71 +1453,136 @@ url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-linkability&am </sect2> <sect2 id="fingerprinting-linkability"> <title>Cross-Origin Fingerprinting Unlinkability</title> + <para> - -In order to properly address the fingerprinting adversary on a technical -level, we need a metric to measure linkability of the various browser -properties beyond any stored origin-related state. <ulink -url="https://panopticlick.eff.org/about.php">The Panopticlick Project</ulink> -by the EFF provides us with a prototype of such a metric. The researchers -conducted a survey of volunteers who were asked to visit an experiment page -that harvested many of the above components. They then computed the Shannon -Entropy of the resulting distribution of each of several key attributes to -determine how many bits of identifying information each attribute provided. +Browser fingerprinting is the act of inspecting browser behaviors and features in +an attempt to differentiate and track individual users. Fingerprinting attacks +are typically broken up into passive and active vectors. Passive +fingerprinting makes use of any information the browser provides automatically +to a website without any specific action on the part of the website. Active +fingerprinting makes use of any information that can be extracted from the +browser by some specific website action, usually involving Javascript. +Some definitions of browser fingerprinting also include supercookies and +cookie-like identifier storage, but we deal with those issues separately in +the <link linkend="identifier-linkability">preceeding section on identifier +linkability</link>. </para> - <para> + <para> -Unfortunately, there are limitations to the way the Panopticlick study was -conducted. Because the Panopticlick dataset is based on browser data spanning -a number of widely deployed browsers over a number of years, any -fingerprinting defenses attempted by browsers today are very likely to cause -Panopticlick to report an <emphasis>increase</emphasis> in fingerprintability -and entropy, because those defenses will stand out in sharp contrast to -historical data. Moreover, because fingerprinting is a problem that -potentially touches every aspect of the browser, we do not believe it is -possible to solve cross-browser fingerprinting issues. We reduce the efforts -for fingerprinting resistance by only concerning ourselves with reducing the -fingerprintable differences <emphasis>among</emphasis> Tor Browser users. +For the most part, however, we do not differentiate between passive or active +fingerprinting sources, since many active fingerprinting mechanisms are very +rapid, and can be obfuscated or disguised as legitimate functionality. +Instead, we believe fingerprinting can only be rationally addressed if we +understand where the problem comes from, what sources of issues are the most +severe, and how to study the efficacy of defenses properly. - </para> - <para> + </para> -The unsolvable nature of the cross-browser fingerprinting problem also means -that the Panopticlick test website itself is not useful for evaluating the -actual effectiveness of our defenses, or the fingerprinting defenses of any -other web browser. We are interested in deploying an improved version of -Panopticlick that measures entropy and variance only among a specific user -agent population, but until then, intuition serves as a decent guide. -Essentially, anything that reveals custom user configuration, third party -software, highly variable hardware details, and external devices attached to -the users computer is likely to more fingerprintable than things like -operating system type and even processor speed. + <sect3 id="fingerprinting-scope"> + <title>Sources of Fingerprinting Issues</title> + <para> - </para> - +All fingerprinting issues arise from one of four primary sources. In order +from most severe to least severe, these sources are: + + </para> + <orderedlist> + <listitem><command>End-user Configuration Details</command> + <para> + +End-user configuration details are by far the most severe threat to +fingerprinting, as they will quickly provide enough information to uniquely +identify a user. We believe it is essential to avoid exposing platform +configuration details to website content at all costs. We also discourage +excessive fine-grained customization of Tor Browser by minimizing and +aggregating user-facing privacy and security options, as well as by +discouraging the use of additional addons. When it is necessary to expose +configuration details in the course of providing functionality, we strive to +do so only on a per-site basis via site permissions, to avoid linkability. + + </para> + </listitem> + <listitem><command>Device and Hardware Characteristics</command> + <para> + +Device and hardware characteristics can be determined three ways: they can be +reported explicitly by the browser, they can be inferred through API behavior, +or they can be extracted through statistical measurements of system +performance. We are most concerned with the cases where this information is +either directly reported or can be determined via a single use of an API or +feature, and prefer to place such APIs either behind site permissions, or +disable them entirely. + </para> + <para> + +On the other hand, because statistical inference of system performance +requires many iterations to achieve accuracy in the face of noise and +concurrent activity, we are less concerned with this mechanism of extracting +this information. We also expect that reducing the resolution of Javascript's +time sources will significantly increase the duration of execution required to +extract accurate results, and thus make statistical approaches both +unattractive and highly noticable due to execessive resource consumption. + + </para> + </listitem> + <listitem><command>Operating System Vendor and Version Differences</command> + <para> + +Operating system vendor and version differences permiate many different +aspects of the browser. While it is possible to address these issues with some +effort, the relative lack of diversity in operating systems causes us to +primarily focus our efforts on passive operating system fingerprinting +mechanisms at this point in time. For the purposes of protecting user +anonymity, it is not strictly essential that the operating system be +completely concealed, though we recognize that it is useful to reduce this +differentiation ability where possible, especially for cases where the +specific version of a system can be inferred. + + </para> + </listitem> + <listitem><command>Browser Vendor and Version Differences</command> + <para> + +Due to vast differences in feature set and implementation behavior even +between different versions of the same browser, browser vendor and version +differences are simply not possible to conceal in any realistic way. It +is only possible to minimize the differences among different installations of +the same browser vendor and version. We make no effort to mimick any other +major browser vendor, and in fact most of our fingerprinting defenses serve to +differentiate Tor Browser users from normal Firefox users. Because of this, +any study that lumps browser vendor and version differences in to its analysis +of the fingerprintability of a population is largely useless for evaluating +either attacks or defenses. Unfortunately, this includes popular large-scale +studies such as <ulink +url="https://panopticlick.eff.org/">Panopticlick</ulink> and <ulink +url="https://amiunique.org/">Am I Unique</ulink>. + + </para> + </listitem> + </orderedlist> + </sect3> <sect3 id="fingerprinting-defenses"> <title>Fingerprinting defenses in the Tor Browser</title> <para> The following defenses are listed roughly in order of most severe -fingerprinting threat first. This ordering is based on the above intuition that -user configurable aspects of the computer are the most severe source of -fingerprintability, though we are in need of updated measurements to determine -this with certainty. +fingerprinting threat first. This ordering is based on the above intuition +that user configurable aspects of the computer are the most severe source of +fingerprintability, followed by device characteristics and hardware, and then +finally operating system vendor and version information. </para> <para> -Where our actual implementation differs from -an ideal solution, we separately describe our <command>Design Goal</command> -and our <command>Implementation Status</command>. + +Where our actual implementation differs from an ideal solution, we separately +describe our <command>Design Goal</command> and our <command>Implementation +Status</command>. </para> <orderedlist> - - <listitem>Plugins <para> @@ -1614,7 +1645,7 @@ system colors were standardized, and the browser shipped a fixed collection of fonts (see later points in this list), it might not be necessary to create a canvas permission. However, until then, to reduce the threat from this vector, we have patched Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prompt +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prompt before returning valid image data</ulink> to the Canvas APIs. If the user hasn't previously allowed the site in the URL bar to access Canvas image data, pure white image data is returned to the Javascript APIs. @@ -1628,24 +1659,27 @@ pure white image data is returned to the Javascript APIs. In Firefox, by using either WebSockets or XHR, it is possible for remote content to <ulink url="http://www.andlabs.org/tools/jsrecon.html">enumerate -the list of TCP ports open on 127.0.0.1</ulink>. In other browsers, this can -be accomplished by DOM events on image or script tags. This open vs filtered -vs closed port list can provide a very unique fingerprint of a machine, -because it essentially enables the detection of many different popular third -party applications and optional system services (Skype, Bitcoin, Bittorrent -and other P2P software, SSH ports, SMB and related LAN services, CUPS and -printer daemon config ports, mail servers, and so on). It is also possible to -determine when ports are closed versus filtered/blocked (and thus probe -custom firewall configuration). +the list of TCP ports open on 127.0.0.1</ulink>, as well as on any other +machines on the local network. In other browsers, this can be accomplished by +DOM events on image or script tags. This open vs filtered vs closed port list +can provide a very unique fingerprint of a machine, because it essentially +enables the detection of many different popular third party applications and +optional system services (Skype, Bitcoin, Bittorrent and other P2P software, +SSH ports, SMB and related LAN services, CUPS and printer daemon config ports, +mail servers, and so on). It is also possible to determine when ports are +closed versus filtered/blocked (and thus probe custom firewall configuration). </para> - <para>In Tor Browser, we prevent access to -127.0.0.1/localhost by ensuring that even these requests are still sent by -Firefox to our SOCKS proxy (ie we set + <para> + +In Tor Browser, we prevent access to 127.0.0.1/localhost by ensuring that even +these requests are still sent by Firefox to our SOCKS proxy (ie we set <command>network.proxy.no_proxies_on</command> to the empty string). The local Tor client then rejects them, since it is configured to proxy for internal IP -addresses by default. +addresses by default. Access to the local network is forbidden via the same +mechanism. + </para> </listitem> @@ -1716,7 +1750,7 @@ In the meantime while we investigate shipping our own fonts, we disable plugins, which prevents font name enumeration. Additionally, we limit both the number of font queries from CSS, as well as the total number of fonts that can be used in a document <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">with +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">with a Firefox patch</ulink>. We create two prefs, <command>browser.display.max_font_attempts</command> and <command>browser.display.max_font_count</command> for this purpose. Once these @@ -1734,7 +1768,6 @@ font (in any order), we use that font instead of any of the named local fonts. </para> </listitem> <listitem>Monitor, Widget, and OS Desktop Resolution - <para> Both CSS and Javascript have access to a lot of information about the screen @@ -1766,22 +1799,27 @@ this scheme. </para> <para><command>Implementation Status:</command> - -We have implemented the above strategy using a window observer to <ulink +We automatically resize new browser windows to a 200x100 pixel multiple using +a window observer to <ulink url="https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutt…">resize -new windows based on desktop resolution</ulink>. Additionally, we patch +new windows based on desktop resolution</ulink>. To minimize the effect of the +long tail of large monitor sizes, we also cap the the window size at 1000 +pixels in each direction. Additionally, we patch Firefox to use the client content window size <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">for -window.screen</ulink>. Similarly, we <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch -DOM events to return content window relative points</ulink>. We also force +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">for +window.screen</ulink>, and to <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report +a window.devicePixelRatio of 1.0</ulink>. Similarly, we <ulink +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patch +DOM events to return content window relative points</ulink>. We also + +We also force popups to open in new tabs (via <command>browser.link.open_newwindow.restriction</command>), to avoid full-screen popups inferring information about the browser resolution. In -addition, we prevent auto-maximizing on browser start, and are investigating a -user-friendly way of informing users that maximized windows are detrimental -to privacy in this mode. +addition, we prevent auto-maximizing on browser start, and inform users that +maximized windows are detrimental to privacy in this mode. </para> </listitem> @@ -1811,12 +1849,12 @@ details such as screen orientation or type. We patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report a fixed set of system colors to content window CSS</ulink>, and <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">prevent detection of font smoothing on OSX</ulink>. We also always <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">report landscape-primary</ulink> for the screen orientation. </para> @@ -1867,7 +1905,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 <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">remove +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">remove content script access</ulink> to Components.interfaces, which <ulink url="http://pseudo-flaw.net/tor/torbutton/fingerprint-firefox.html">can be used</ulink> to fingerprint OS, platform, and Firefox minor version. </para> @@ -1884,11 +1922,10 @@ completeness, we attempt to maintain this property. </para> <para><command>Implementation Status:</command> - We set the fallback character set to set to windows-1252 for all locales, via <command>intl.charset.default</command>. We also patch Firefox to allow us to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">instruct +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">instruct the JS engine</ulink> to use en-US as its internal C locale for all Date, Math, and exception handling. @@ -1956,10 +1993,13 @@ large number of people. </para> <para><command>Implementation Status:</command> -Currently, the only mitigation against performance fingerprinting is to +Currently, the our mitigation against performance fingerprinting is to disable <ulink url="http://www.w3.org/TR/navigation-timing/">Navigation Timing</ulink> through the Firefox preference -<command>dom.enable_performance</command>. +<command>dom.enable_performance</command>, and to disable the <ulink +url="https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement#Gecko-spe…">Mozilla +Video Statistics</ulink> API extensions via the preference +<command>media.video_stats.enabled</command>. </para> </listitem> @@ -1989,8 +2029,8 @@ characteristics of the operating system type may leak into content, and the comparatively low contribution of OS to overall entropy. In particular, there are likely to be many ways to measure the differences in widget size, scrollbar size, and other rendered details on a page. Also, directly exported -OS routines, such as the Math library, expose differences in their -implementations due to these results. +OS routines (such as those from the standard C math library) expose +differences in their implementations through their return values. </para> <para><command>Design Goal:</command> @@ -2007,23 +2047,36 @@ tag on our bug tracker</ulink>. </para> <para><command>Implementation Status:</command> -At least two HTML5 features have different implementation status across the -major OS vendors: the <ulink +At least three HTML5 features have different implementation status across the +major OS vendors and/or the underlying hardware: the <ulink url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.battery">Battery -API</ulink> and the <ulink +API</ulink>, the <ulink url="https://developer.mozilla.org/en-US/docs/DOM/window.navigator.connection">Network -Connection API</ulink>. We disable these APIs through the Firefox preferences -<command>dom.battery.enabled</command> and -<command>dom.network.enabled</command>. +Connection API</ulink>, and the <ulink +url="https://wiki.mozilla.org/Sensor_API">Sensor API</ulink>. We disable these APIs through the Firefox preferences +<command>dom.battery.enabled</command>, +<command>dom.network.enabled</command>, and +<command>device.sensors.enabled</command>. </para> </listitem> </orderedlist> - </sect3> <para> For more details on fingerprinting bugs and enhancements, see the <ulink url="https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting…">tbb-fingerprinting tag in our bug tracker</ulink> - </para> + </para> + </sect3> + + </sect2> <sect2 id="new-identity"> <title>Long-Term Unlinkability via "New Identity" button</title> @@ -2048,7 +2101,6 @@ All linkable identifiers and browser state MUST be cleared by this feature. <title>Implementation Status:</title> <blockquote> <para> - First, Torbutton disables Javascript in all open tabs and windows by using both the <ulink @@ -2083,8 +2135,15 @@ connections and then send the NEWNYM signal to the Tor control port to cause a new circuit to be created. </para> <para> + Finally, a fresh browser window is opened, and the current browser window is -closed (this does not spawn a new Firefox process, only a new window). +closed (this does not spawn a new Firefox process, only a new window). Upon +the close of the final window, an unload handler is fired to invoke the <ulink +url="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Inter…">garbage +collector</ulink>, which has the effect of immediately purging any blob:UUID +urls that were created by website content via <ulink +url="https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL">URL.createObjectURL</ulink>. + </para> </blockquote> <blockquote> @@ -2209,7 +2268,7 @@ network, making them also effectively no-overhead. <blockquote> <para> Currently, we patch Firefox to <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">randomize +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">randomize pipeline order and depth</ulink>. Unfortunately, pipelining is very fragile. Many sites do not support it, and even sites that advertise support for pipelining may simply return error codes for successive requests, effectively @@ -2274,7 +2333,7 @@ date. <para> We also make use of the in-browser Mozilla updater, and have <ulink -url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patched +url="https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-31.6.0e…">patched the updater</ulink> to avoid sending OS and Kernel version information as part of its update pings.

1 0

[tor-browser-spec/master] Add update security info.
by mikeperry＠torproject.org 30 Apr '15

30 Apr '15

commit 351f4868291f16da605191c6f0597b632277d841 Author: Mike Perry <mikeperry-git(a)torproject.org> Date: Wed Apr 29 20:55:25 2015 -0700 Add update security info. --- design-doc/design.xml | 55 +++++++++++++++++++++++++------------------------ 1 file changed, 28 insertions(+), 27 deletions(-) diff --git a/design-doc/design.xml b/design-doc/design.xml index 5c16ce8..90f8032 100644 --- a/design-doc/design.xml +++ b/design-doc/design.xml @@ -221,19 +221,6 @@ ephemeral-keyed encrypted swap. </para></listitem> - - </orderedlist> </sect2> @@ -1121,13 +1108,6 @@ $HOME environment variable to be the TBB extraction directory. </para> </sect2> - <sect2 id="identifier-linkability"> <title>Cross-Origin Identifier Unlinkability</title> <para> @@ -2367,7 +2347,6 @@ of its update pings. <sect1 id="BuildSecurity"> <title>Build Security and Package Integrity</title> <para> - In the age of state-sponsored malware, <ulink url="https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and…">we @@ -2532,7 +2511,6 @@ time-based dependency tracking</ulink> that only appear in LXC containers. </sect2> <sect2> - <title>Package Signatures and Verification</title> <para> @@ -2565,11 +2543,11 @@ consensus, and encoding the package hashes in the Bitcoin blockchain. </para> <para> -At the time of this writing, we do not yet support native code signing for Mac -OS or Windows. Because these signatures are embedded in the actual packages, -and by their nature are based on non-public key material, providing native -code-signed packages while still preserving ease of reproducibility -verification has not yet been achieved. +The Windows releases are also signed by a hardware token provided by Digicert. +In order to verify package integrity, the signature must be sripped off using +the osslsigncode tool, as described on the <ulink +url="https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificat…">Signature +Vericication</ulink> page. </para> </sect2> @@ -2598,6 +2576,29 @@ verifier. </para> </sect2> + <sect2 id="update-safety"> + <title>Update Safety</title> + <para> + +We make use of the Firefox updater in order to provide automatic updates to +users. We make use of certificate pinning to ensure that update checks +be tampered with, and we sign the individual MAR update files with an offline +signing key. + + </para> + <para> + +The Firefox updater also has code to ensure that it can reliably access the +update server to prevent availability attacks, and complains to the user of 48 +hours go by without a successful response from the server. Additionally, we +use Tor's SOCKS username and password isolation to ensure that every new +request to the updater traverses a separate circuit, to avoid holdback attacks +by exit nodes. + + </para> + </sect2> + + </sect1> <!-- <sect2 id="components">

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits April 2015