April 2014 - tor-commits - lists.torproject.org

[tor-browser-spec/master] Add intro to implementation section.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit b405554d5a3987a679cc68aaa62156201da6d2f1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 18 21:38:32 2011 -0700 Add intro to implementation section. Also add some hyperlinks. --- docs/design/design.xml | 53 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 44 insertions(+), 9 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 000ad35..221d707 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Oct 11 2011</pubdate> + <pubdate>Oct 19 2011</pubdate> </articleinfo>  </orderedlist> + </sect2> <sect2 id="privacy"> @@ -443,7 +458,8 @@ to be the entire fully qualified domain name. </para> <orderedlist> - <listitem><command>Cross-Origin Identifier Unlinkability</command> + <listitem><link linkend="identifier-linkability"><command>Cross-Origin +Identifier Unlinkability</command></link> <para> User activity on one url bar origin MUST NOT be linkable to their activity in @@ -456,7 +472,8 @@ functionality SHOULD NOT interfere with federated login in a substantial way. </para> </listitem> - <listitem><command>Cross-Origin Fingerprinting Unlinkability</command> + <listitem><link linkend="fingerprinting-linkability"><command>Cross-Origin +Fingerprinting Unlinkability</command></link> <para> User activity on one url bar origin MUST NOT be linkable to their activity in @@ -465,7 +482,8 @@ linkability from fingerprinting browser behavior. </para> </listitem> - <listitem><command>Long-Term Unlinkability</command> + <listitem><link linkend="new-identity"><command>Long-Term +Unlinkability</command></link> <para> The browser SHOULD provide an obvious, easy way to remove all of its @@ -636,6 +654,23 @@ certain new features (where possible) pending analysis and audit. <sect1 id="Implementation"> <title>Implementation</title> <para> + +The Implementation section is divided into subsections, each of which +corresponds to a <link linkend="DesignRequirements">Design Requirement</link>. +Each subsection is divided into specific web technologies or properties. The +implementation is then described for that property. + + </para> + <para> + +In some cases, the implementation meets the design requirements in a non-ideal +way (for example, by disabling features). In rare cases, there may be no +implementation at all. Both of these cases are denoted by differentiating +between the <command>Design Goal</command> and the <command>Implementation +Status</command> for each property. Corresponding bugs in the <ulink +url="https://trac.torproject.org/projects/tor/report">Tor bug tracker</ulink> +are typically linked for these cases. + </para> <sect2 id="proxy-obedience"> <title>Proxy Obedience</title>

1 0

[tor-browser-spec/master] Clean up some wording.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 1d808a7da29843f94f2cc83f3406382b0ee6b2f8 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 19:19:08 2011 -0800 Clean up some wording. --- docs/design/design.xml | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 23ed31c..d8b62e2 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -350,7 +350,7 @@ linkend="security">Security Requirements</link>, and <link linkend="privacy">Privacy Requirements</link>. Security Requirements are the minimum properties in order for a browser to be able to support Tor and similar privacy proxies safely. Privacy requirements are the set of properties -that cause us to prefer one browser platform over another. +that cause us to prefer one browser over another. </para> <para> @@ -376,8 +376,8 @@ browser distribution. The security requirements are primarily concerned with ensuring the safe use of Tor. Violations in these properties typically result in serious risk for the user in terms of immediate deanonymization and/or observability. With -respect to platform support, security requirements are the minimum properties -in order for Tor to support the use of a web client platform. +respect to browser support, security requirements are the minimum properties +in order for Tor to support the use of a particular browser. </para> @@ -416,11 +416,12 @@ or MUST provide a mechanism for rapid, complete removal of all evidence of the use of the mode. In other words, the browser MUST NOT write or cause the operating system to write <emphasis>any information</emphasis> about the use of private browsing to disk outside of the application's control. The user -must be able to ensure that secure removal of the software is sufficient to +must be able to ensure that secure deletion of the software is sufficient to remove evidence of the use of the software. All exceptions and shortcomings due to operating system behavior MUST be wiped by an uninstaller. However, due to permissions issues with access to swap, implementations MAY choose to leave -it out of scope, and/or leave it to the user to implement encrypted swap. +it out of scope, and/or leave it to the Operating System/platform to implement +ephemeral-keyed encrypted swap. </para></listitem> @@ -441,8 +442,8 @@ Safety</command></link> The privacy requirements are primarily concerned with reducing linkability: the ability for a user's activity on one site to be linked with their activity on another site without their knowledge or explicit consent. With respect to -platform support, privacy requirements are the set of properties that cause us -to prefer one platform over another. +browser support, privacy requirements are the set of properties that cause us +to prefer one browser over another. </para> @@ -467,7 +468,7 @@ any other url bar origin by any third party automatically or without user interaction or approval. This requirement specifically applies to linkability from stored browser identifiers, authentication tokens, and shared state. The requirement does not apply to linkable information the user manually submits -to sites, or due information submitted during manual link traversal. This +to sites, or due to information submitted during manual link traversal. This functionality SHOULD NOT interfere with federated login in a substantial way. </para> @@ -566,7 +567,7 @@ failure of Torbutton</ulink> was (and still is) the options panel. Each option that detectably alters browser behavior can be used as a fingerprinting tool. Similarly, all extensions <ulink url="http://blog.chromium.org/2010/06/extensions-in-incognito.html">SHOULD be -disabled in the mode</ulink> except as an opt-in basis. We should not load +disabled in the mode</ulink> except as an opt-in basis. We SHOULD NOT load system-wide addons or plugins. </para> @@ -591,7 +592,8 @@ permissions can be written to disk. Otherwise, they should remain memory-only. Filter-based addons such as <ulink url="https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/">AdBlock -Plus</ulink>, <ulink url="">Request Policy</ulink>, <ulink +Plus</ulink>, <ulink url="http://requestpolicy.com/">Request Policy</ulink>, +<ulink url="http://www.ghostery.com/about">Ghostery</ulink>, <ulink url="http://priv3.icsi.berkeley.edu/">Priv3</ulink>, and <ulink url="http://sharemenot.cs.washington.edu/">Sharemenot</ulink> are to be avoided. We believe that these addons do not add any real privacy to a proper @@ -601,8 +603,8 @@ prevented from tracking users between sites by the implementation. Filter-based addons can also introduce strange breakage and cause usability nightmares, and will also fail to do their job if an adversary simply registers a new domain or creates a new url path. Worse still, the unique -filter sets that each user creates or installs will provide a wealth -of fingerprinting targets. +filter sets that each user creates or installs will provide a wealth of +fingerprinting targets. </para> <para> @@ -624,7 +626,7 @@ so is not recommended, as it will alter the browser request fingerprint. We believe that if we do not stay current with the support of new web technologies, we cannot hope to substantially influence or be involved in their proper deployment or privacy realization. However, we will likely disable -certain new features (where possible) pending analysis and audit. +high-risk features pending analysis, audit, and mitigation. </para> </listitem> </orderedlist>

1 0

[tor-browser-spec/master] List what proxy tests we've done.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit fd9148c88fd1756f71133d4cb243a48f15a3808b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Oct 11 15:06:24 2011 -0700 List what proxy tests we've done. --- docs/design/design.xml | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 6782dc9..000ad35 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Oct 7 2011</pubdate> + <pubdate>Oct 11 2011</pubdate> </articleinfo> <!-- @@ -651,6 +651,26 @@ SOCKS proxy. It sets <command>network.proxy.socks_remote_dns</command>, <command>network.proxy.socks_version</command>, and <command>network.proxy.socks_port</command>. </para> + <para> + +We have verified that these settings properly proxy HTTPS, OCSP, HTTP, FTP, +gopher (now defunct), DNS, SafeBrowsing Queries, all javascript activity, +including HTML5 audio and video objects, addon updates, wifi geolocation +queries, searchbox queries, XPCOM addon HTTPS/HTTP activity, 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 handers are all blocked. + + </para> + <para> + +Numerous other third parties have also reviewed and <link +linkend="SingleStateTesting">tested</link> the proxy settings +and have provided test cases based on their work. See in particular <ulink +url="http://decloak.net/">decloak.net</ulink>. + + </para> </listitem> <listitem>Disabling plugins

1 0

[tor-browser-spec/master] Redirects really should not be allowed to store identifiers.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit e0cd4019b2bc971b4d7564d11341a3edf6ef6b7b Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 19:35:04 2011 -0800 Redirects really should not be allowed to store identifiers. Not that it really matters at this point. Detecting redirects is a nightmare.. --- docs/design/design.xml | 35 +++++++++-------------------------- 1 file changed, 9 insertions(+), 26 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index d8b62e2..f034fb5 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1038,39 +1038,22 @@ from the last packet read on the connection) using the Firefox preference </para> </listitem> - <listitem>User confirmation for cross-origin redirects + <listitem>Automated cross-origin redirects MUST NOT store identifiers <para><command>Design Goal:</command> To prevent attacks aimed at subverting the Cross-Origin Identifier Unlinkability <link linkend="privacy">privacy requirement</link>, the browser -MUST prompt the user before following redirects that would cause the user to -automatically navigate between two different url bar origins. The prompt -SHOULD inform the user about the ability to use <link -linkend="new-identity">New Identity</link> to clear the linked identifiers -created by the redirect. - -</para> -XXX: Should redirects be allowed to set cookies? The *redirecting* domain -probably shouldn't, but the destination domain should. -<para> - -To reduce the occurrence of warning fatigue, these warning messages MAY be limited -to automated redirect cycles only. For example, the automated redirect -sequence <command>User Click -> t.co -> bit.ly -> cnn.com</command> can be -assumed to be benign, but the redirect sequence <command>User Click -> t.co -> -bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is -clearly due to tracking. Non-automated redirect cycles that require -user input at some step (such as federated login systems) need not be -interrupted by the UI, and SHOULD still allow identifiers to persist. +MUST NOT store any identifiers (cookies, cache, DOM storage, HTTP auth, etc) +for cross-origin redirect intermediaries that do not prompt for user input. +For example, if a user clicks on a bit.ly url that redirects to a +doubleclick.net url that finally redirects to a cnn.com url, only cookies from +cnn.com should be retained after the redirect chain completes. </para> - <para> + <para> -We are not concerned with linkability due to explicit user action (either by -accepting cross-origin redirects, or by clicking normal links) because it is -assumed that private browsing sessions will be relatively short-lived, -especially with frequent use of the <link linkend="new-identity">New -Identity</link> button. +Non-automated redirect chains that require user input at some step (such as +federated login systems) SHOULD still allow identifiers to persist. </para> <para><command>Implementation status:</command>

1 0

[tor-browser-spec/master] Update design doc for latest Torbutton and TBB patches.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 8fea738ab4a2049ee5b9260c716905c350183155 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 18:42:26 2011 -0800 Update design doc for latest Torbutton and TBB patches. Also address some comments from StrangeCharm and Georg Koppen. --- docs/design/design.xml | 89 +++++++++++++++++++++++++++--------------------- 1 file changed, 51 insertions(+), 38 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 7a819c2..23ed31c 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Oct 19 2011</pubdate> + <pubdate>Dec 16 2011</pubdate> </articleinfo>  +Additionally, due primarily to an issue with Ubuntu Unity, url-based drag and drop is +filtered by this component. Unity was pre-fetching URLs without using the +browser's proxy settings during a drag action, even if the drop was ultimately +canceled by the user. </para> </listitem> </orderedlist> @@ -995,33 +1000,39 @@ settings manager</ulink>. We are currently <ulink url="https://trac.torproject.org/projects/tor/ticket/3974">having difficulties</ulink> causing Flash player to use this settings -file on Windows. +file on Windows, so Flash remains difficult to enable. </para> </listitem> - <listitem>TLS session resumption and HTTP Keep-Alive - <para> -TLS session resumption and HTTP Keep-Alive MUST NOT allow third party origins -to track users via either TLS session IDs, or the fact that different requests -arrive on the same TCP connection. - </para> + <listitem>SSL+TLS session resumption and HTTP Keep-Alive <para><command>Design Goal:</command> -TLS session resumption IDs MUST be limited to the url bar origin. -HTTP Keep-Alive connections from a third party in one url bar origin MUST -NOT be reused for that same third party in another url bar origin. +TLS session resumption tickets and SSL Session IDs MUST be limited to the url +bar origin. HTTP Keep-Alive connections from a third party in one url bar +origin MUST NOT be reused for that same third party in another url bar origin. </para> <para><command>Implementation Status:</command> -We currently clear TLS Session IDs upon <link linkend="new-identity">New -Identity</link>, but we have no origin restriction implementation as of yet. -We plan to <ulink -url="https://trac.torproject.org/projects/tor/ticket/4099">disable TLS session -resumption</ulink>, and limit HTTP Keep-alive duration as stopgaps to limit -linkability until we can implement <ulink -url="https://trac.torproject.org/projects/tor/ticket/4100">true origin -isolation</ulink> (the latter we feel will be fairly tricky). +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/torbrowser.git/blob/maint-2.2:/src/current-pa…">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 +False Start</ulink> via the Firefox Pref +<command>security.ssl.enable_false_start</command>. + </para> + <para> + +Becuase of the extreme performance benefits of HTTP Keep-Alive for interactive +web apps, and because of the difficulties of conveying urlbar origin +information down into the Firefox HTTP layer, as a compromise we currently +merely reduce the HTTP Keep-Alive timeout to 20 seconds (which is measured +from the last packet read on the connection) using the Firefox preference +<command>network.http.keep-alive.timeout</command>. </para> </listitem> @@ -1034,9 +1045,11 @@ MUST prompt the user before following redirects that would cause the user to automatically navigate between two different url bar origins. The prompt SHOULD inform the user about the ability to use <link linkend="new-identity">New Identity</link> to clear the linked identifiers -created by the redirect. +created by the redirect. </para> +XXX: Should redirects be allowed to set cookies? The *redirecting* domain +probably shouldn't, but the destination domain should. <para> To reduce the occurrence of warning fatigue, these warning messages MAY be limited @@ -1046,7 +1059,7 @@ assumed to be benign, but the redirect sequence <command>User Click -> t.co -> bit.ly -> cnn.com -> 2o7.net -> scorecardresearch.net -> cnn.com</command> is clearly due to tracking. Non-automated redirect cycles that require user input at some step (such as federated login systems) need not be -interrupted by the UI. +interrupted by the UI, and SHOULD still allow identifiers to persist. </para> <para> @@ -1426,26 +1439,26 @@ All linkable identifiers and browser state MUST be cleared by this feature. <title>Implementation Status:</title> <blockquote> - First, Torbutton disables all open tabs and windows via nsIContentPolicy -blocking, and then closes each tab and window. The extra step for blocking -tabs is done as a precaution to ensure that any asynchronous Javascript is in -fact properly disabled. After closing all of the windows, we then clear the -following state: OCSP (by toggling security.OCSP.enabled), cache, -site-specific zoom and content preferences, Cookies, DOM storage, safe -browsing key, the Google wifi geolocation token (if exists), HTTP auth, SSL -Session IDs, HSTS state, and the last opened URL field (via the pref -general.open_location.last_url). After clearing the browser state, we then +First, Torbutton disables all open tabs and windows by tagging them and +blocking them via the nsIContentPolicy, and then closes each tab and +window. The extra step for blocking tabs is done as a precaution to ensure +that any asynchronous Javascript is in fact properly disabled. After closing +all of the windows, we then clear the following state: OCSP (by toggling +security.OCSP.enabled), cache, site-specific zoom and content preferences, +Cookies, DOM storage, safe browsing key, the Google wifi geolocation token (if +exists), HTTP auth, SSL Session IDs, HSTS state, close all remaining HTTP +keep-alive connections, and clear the last opened URL field (via the pref +general.open_location.last_url). After clearing the browser state, we then send the NEWNYM signal to the Tor control port to cause a new circuit to be created. </blockquote> + <blockquote> +Additionally, the user is allowed to "protect" cookies of their choosing from +deletion during New Identity by using the Torbutton Cookie Protections UI to +protect the cookies they would like to keep across New Identity invocations. + </blockquote> </sect3> - - </sect2> <sect2 id="click-to-play"> <title>Click-to-play for plugins and invasive content</title>

1 0

[tor-browser-spec/master] Describe new Firefox patches and update links.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 122128797f57ee3d77dda4e6ebcca0645a079d30 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Dec 16 20:40:26 2011 -0800 Describe new Firefox patches and update links. --- docs/design/design.xml | 50 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 41 insertions(+), 9 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index f034fb5..27c8769 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -727,7 +727,7 @@ supported mime types for all currently installed plugins. <para> In addition, to prevent any unproxied activity by plugins at load time, we also patch the Firefox source code to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent the load of any plugins except +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the load of any plugins except for Flash and Gnash</ulink>. </para> @@ -806,13 +806,13 @@ In addition, three Firefox patches are needed to prevent disk writes, even if Private Browsing Mode is enabled. We need to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the permissions manager from recording HTTPS STS state</ulink>, <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent intermediate SSL certificates from being recorded</ulink>, and <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">prevent +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">prevent the content preferences service from recording site zoom</ulink>. For more details on these patches, <link linkend="firefox-patches">see the @@ -930,7 +930,7 @@ 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/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">patch Firefox to provide a cacheDomain cache attribute</ulink>. We use the fully qualified url bar domain as input to this field. @@ -967,7 +967,7 @@ url="https://developer.mozilla.org/en/Setting_HTTP_request_headers#Observers">ht observer</ulink> to remove the Authorization headers to prevent <ulink url="http://jeremiahgrossman.blogspot.com/2007/04/tracking-users-without-cookies…">silent linkability between domains</ulink>. We also needed to <ulink -url="https://gitweb.torproject.org/torbrowser.git/blob/refs/heads/maint-2.2:/src…">patch +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">patch Firefox to cause the headers to get added early enough</ulink> to allow the observer to modify it. @@ -1263,7 +1263,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/torbrowser.git/blob/refs/heads/maint-2.2:/src…">remove +url="https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-pa…">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> @@ -1464,8 +1464,7 @@ audio and video objects. <title>Description of Firefox Patches</title> <para> The set of patches we have against Firefox can be found in the <ulink -url="https://gitweb.torproject.org/torbrowser.git/tree/refs/heads/maint-2.2:/src…">current-patches -directory of the torbrowser git repository</ulink>. They are: +url="https://gitweb.torproject.org/torbrowser.git/tree/maint-2.2:/src/current-pa…">current-patches directory of the torbrowser git repository</ulink>. They are: </para> <orderedlist> <listitem>Block Components.interfaces and Components.lookupMethod @@ -1566,6 +1565,39 @@ the profile directory as content prefs change (includes site-zoom and perhaps other site prefs?). </para> </listitem> + <listitem>Make Tor Browser exit when not launched from Vidalia + <para> + +It turns out that on Windows 7 and later systems, the Taskbar attempts to +automatically learn the most frequent apps used by the user, and it recognizes +Tor Browser as a seperate app from Vidalia. This can cause users to try to +launch Tor Brower without Vidalia or a Tor instance running. Worse, the Tor +Browser will automatically find their default Firefox profile, and properly +connect directly without using Tor. This patch is a simple hack to cause Tor +Browser to immediately exit in this case. + + </para> + </listitem> + <listitem>Disable SSL Session ID tracking + <para> + +This patch is a simple 1-line hack to prevent SSL connections from caching +(and then later transmitting) their Session IDs. There was no preference to +govern this behavior, so we had to hack it by altering the SSL new connection +defaults. + + </para> + </listitem> + <listitem>Provide an observer event to close persistent connections + <para> + +This patch creates an observer event in the HTTP connection manager to close +all keep-alive connections that still happen to be open. This event is emitted +by the <link linkend="new-identity">New Identity</link> button. + + </para> + </listitem> + </orderedlist> </sect2>

1 0

[tor-browser-spec/master] Correct a 2119 usage.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 2c429a540ffde740fd7da4ce608b2ba4a8eff982 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Fri Oct 21 13:41:43 2011 -0700 Correct a 2119 usage. --- docs/design/design.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 221d707..7a819c2 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1008,8 +1008,8 @@ arrive on the same TCP connection. <para><command>Design Goal:</command> TLS session resumption IDs MUST be limited to the url bar origin. -HTTP Keep-Alive connections from a third party in one url bar origin must -not be reused for that same third party in another url bar origin. +HTTP Keep-Alive connections from a third party in one url bar origin MUST +NOT be reused for that same third party in another url bar origin. </para> <para><command>Implementation Status:</command>

1 0

[tor-browser-spec/master] Describe CSS media query implementaion.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit fd12608603192797112c9956c2fad14744577063 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Dec 28 22:08:21 2011 -0600 Describe CSS media query implementaion. --- docs/design/design.xml | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index 27c8769..0a5df12 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -1296,11 +1296,18 @@ We have implemented the above strategy for Javascript using Torbutton's <ulink url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…">JavaScript hooks</ulink> as well as a window observer to <ulink url="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/t…">resize -new windows based on desktop resolution</ulink>. However, CSS Media Queries -still <ulink url="https://trac.torproject.org/projects/tor/ticket/2875">need -to be dealt with</ulink>. +new windows based on desktop resolution</ulink>. Additionally, we patch +Firefox to cause CSS Media Queries to use the client content window size +for all desktop size related media queries.  </para> + <para> + +As far as we know, this fully satisfies our design goals for desktop +resolution information. + + </para> + </listitem> <listitem>Timezone and clock offset <para><command>Design Goal:</command>

1 0

[tor-browser-spec/master] Bump date.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit 43a53f7cdbf1523c919fd8f581482627c9fad38c Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Wed Dec 28 22:22:08 2011 -0600 Bump date. --- docs/design/design.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/design.xml b/docs/design/design.xml index df15dbe..3677816 100644 --- a/docs/design/design.xml +++ b/docs/design/design.xml @@ -23,7 +23,7 @@ <address><email>sjmurdoch#torproject org</email></address> </affiliation> </author> - <pubdate>Dec 16 2011</pubdate> + <pubdate>Dec 28 2011</pubdate> </articleinfo> <!--

1 0

[tor-browser-spec/master] Add new and old Firefox code audit notes.
by mikeperry＠torproject.org 28 Apr '14

28 Apr '14

commit e4601b80e9215bbc2e7d449e4d5e7890f6b7246a Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Thu Feb 7 14:55:18 2013 -0800 Add new and old Firefox code audit notes. --- docs/audits/FF17_FEATURE_AUDIT | 19 ++++ docs/audits/FF17_NETWORK_AUDIT | 84 +++++++++++++++++ docs/audits/FF3.5_AUDIT | 195 ++++++++++++++++++++++++++++++++++++++++ docs/audits/FF4_AUDIT | 50 +++++++++++ 4 files changed, 348 insertions(+) diff --git a/docs/audits/FF17_FEATURE_AUDIT b/docs/audits/FF17_FEATURE_AUDIT new file mode 100644 index 0000000..b135c0a --- /dev/null +++ b/docs/audits/FF17_FEATURE_AUDIT @@ -0,0 +1,19 @@ +- Can calc() accept device-width/height? + - No. Numbers only. + - Can viewport/meta viewport accept them? + - nsContentUtils::GetViewportInfo() might be the only place.. + - nsContentUtils::ProcessViewportInfo() + - Viewport seems unused on all but mobile + - Maybe worth testing.. + +- currentColor: OK +- scrollMax: OK +- IdleAPI: FirefoxOS only, but still present w/ pref?? + - Throws "The operation is insecure" exception + - Disabled for content. WebApp only. + +- Web Activities + - Seems unfinished and unexported to content + +- RegisterContent/ProtocolHandler -> Third party supercookie?? + - asks for confirmation diff --git a/docs/audits/FF17_NETWORK_AUDIT b/docs/audits/FF17_NETWORK_AUDIT new file mode 100644 index 0000000..8ec25ba --- /dev/null +++ b/docs/audits/FF17_NETWORK_AUDIT @@ -0,0 +1,84 @@ + +Lowest level resolver calls: + - PR_GetHostByName + + ./profile/dirserviceprovider/src/nsProfileLock.cpp + + nsProfileLock::LockWithSymlink + + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c + - pkix_pl_Socket_CreateByHostAndPort() + - pkix_pl_Socket_CreateByName() + - ./security/nss/lib/certhigh/ocsp.c + - ocsp_ConnectToHost() + + ./security/nss/cmd/libpkix/pkix_pl/module/test_socket.c + + ./security/nss/cmd/vfyserv/vfyserv.c + - ./media/webrtc/trunk/src/modules/udp_transport/source/udp_transport_impl.cc (!!!) + --disable-webrtc!!! + + PR_GetAddrInfoByName + + ./security/nss/cmd/ssltap/ssltap.c + + ./security/nss/cmd/tstclnt/tstclnt.c + + ./security/nss/cmd/strsclnt/strsclnt.c + +Direct paths to DNS resolution: + + nsDNSService::Resolve + + nsDNSService::AsyncResolve + + nsHostResolver::ResolveHost + +Misc UDP (SOCK_DGRAM, PR_DESC_SOCKET_UDP): + + ./nsprpub/pr/src/io/prsocket.c + + PR_NewUDPSocket + + PR_OpenUDPSocket + + PR_Socket + + ./nsprpub/pr/src/pthreads/ptio.c + + ./netwerk/socket/nsUDPSocketProvider.cpp + +Misc TCP (SOCK_STREAM, PR_DESC_SOCKET_TCP): + + ./nsprpub/pr/src/pthreads/ptio.c + - ./nsprpub/pr/src/io/prsocket.c + - PR_NewTCPSocket + - PR_Socket + - PR_OpenTCPSocket + + ./nsprpub/pr/src/misc/prnetdb.c + + TCPSocket: + + ./security/manager/ssl/src/nsNSSIOLayer.cpp + + nsSSLIOLayerNewSocket() + + ./security/nss/lib/certhigh/ocsp.c + + ocsp_SendEncodedRequest + + ./security/nss/lib/libpkix/pkix_pl_nss/module/pkix_pl_socket.c + + pkix_pl_Socket_CreateClient + + pkix_pl_Socket_CreateServer + +Misc PR_Socket: + + ./nsprpub/pr/src/cplus/rcnetio.cpp + + RCNetStreamIO::RCNetStreamIO + +Misc XPCOM: + - *SocketProvider + + newSocket + + ./netwerk/base/src/nsSocketTransport2.cpp: + + addToSocket + + @mozilla.org/network/socket: + + createTransport() + + ./netwerk/protocol/http/nsHttpConnectionMgr.cpp + + ./netwerk/protocol/ftp/nsFtpConnectionThread.cpp: + + ./netwerk/protocol/ftp/nsFtpControlConnection.cpp: + + ./dom/network/src/TCPSocket.js + + open() + +Android may have DNS leaks.. + - ./mobile/android/base/httpclientandroidlib/impl/conn/DefaultClientConnectionOperator.java + +nsDNSService/nsPIDNSService/nsIDNSService + + calls nsHostResolver::ResolveHost + + used by: + + DNS prefetch (disabled) + + ./netwerk/base/src/nsIOService.cpp (offline mode only) + + ./netwerk/build/nsNetModule.cpp + + ./netwerk/protocol/websocket/WebSocketChannel.cpp + + ./netwerk/build/nsNetCID.h + + ./netwerk/socket/nsSOCKSIOLayer.cpp (proxy lookup only) + +netwerk/base/src/nsSocketTransport2.cpp + + nsSocketTransport::ResolveHost() has proper remote dns checks + + Resolution is done by using hostname as sockaddr + + PROXY_RESOLVES_HOST + + diff --git a/docs/audits/FF3.5_AUDIT b/docs/audits/FF3.5_AUDIT new file mode 100644 index 0000000..35a9fbf --- /dev/null +++ b/docs/audits/FF3.5_AUDIT @@ -0,0 +1,195 @@ +First pass: Quick Review of Firefox Features +- Video Tag + - Docs: + - https://developer.mozilla.org/En/HTML/Element/Audio + - https://developer.mozilla.org/En/HTML/Element/Video + - https://developer.mozilla.org/En/HTML/Element/Source + - https://developer.mozilla.org/En/Manipulating_video_using_canvas + - https://developer.mozilla.org/En/nsIDOMHTMLMediaElement + - https://developer.mozilla.org/En/Media_formats_supported_by_the_audio_and_v… + - http://en.flossmanuals.net/TheoraCookbook + - nsIContentPolicy is checked on load + - Uses NSIChannels for initial load + - Wrapped in nsHTMLMediaElement::mDecoder + - is nsOggDecoder() or nsWaveDecoder() + - liboggplay + - Governed by media.* prefs + - Preliminary audit shows they do not use the liboggplay tcp functions +- Geolocation + - Wifi: + - https://developer.mozilla.org/En/Monitoring_WiFi_access_points + - Requires security policy to allow. Then still prompted + - navigator.geolocation + - Governed by geo.enabled + - "2 week access token" is set + - geo.wifi.access_token.. Clearing is prob a good idea + - http://mxr.mozilla.org/mozilla1.9.1/source/dom/src/geolocation/NetworkGeolo… + - https://developer.mozilla.org/En/Using_geolocation +- DNS prefetching after toggle + - prefetch pref? Always disable for now? + - network.dns.disablePrefetch + - Also disabled in netwerk/dns/src/nsDNSService2.cpp when manual proxies + are set.. + - This should prevent prefetching of non-tor urls in tor mode.. + - But the reverse is unclear. + - DocShell attribute!!1 YAY + - http://www.oxymoronical.com/experiments/apidocs/interface/nsIDocShell + - "Takes effect for the NEXT document loaded...." + - Do we win this race? hrmm.. If we do, the tor->nontor direction + should also be safe. + - Content policy called? + - No. See content/html/content/src/nsHTMLDNSPrefetch.cpp +- Storage + - https://developer.mozilla.org/en/Storage + - "It is available to trusted callers, meaning extensions and Firefox + components only." +- New content policy + - Content Security Policy. Addon-only +- "Offline resources" + - https://developer.mozilla.org/en/Offline_resources_in_Firefox + - https://developer.mozilla.org/en/nsIApplicationCache + - browser.cache.offline.enable toggles + - browser.cache.disk.enable does not apply. Seperate "device". + - Does our normal cache clearing mechanism apply? + - We call nsICacheService.evictEntries() + - May need: nsOfflineCacheDevice::EvictEntries(NULL) + - Code is smart enough to behave cleanly if we simply set + browser.cache.offline.enable or enable private browsing. +- Mouse gesture and other new DOM events +- Fonts + - Remote fonts obey content policy. Good. + - XXX: Are they cached independent of regular cache? Prob not. + - Hrmm can probe for installed fonts: + http://remysharp.com/2008/07/08/how-to-detect-if-a-font-is-installed-only-u… + http://www.lalit.org/lab/javascript-css-font-detect + http://www.ajaxupdates.com/cssjavascript-font-detector/ + http://code.google.com/p/jquery-fontavailable/ +- Drag and drop + - https://developer.mozilla.org/En/DragDrop/Drag_and_Drop + - https://developer.mozilla.org/En/DragDrop/Drag_Operations + - https://developer.mozilla.org/En/DragDrop/Dragging_and_Dropping_Multiple_It… + - https://developer.mozilla.org/En/DragDrop/Recommended_Drag_Types + - https://developer.mozilla.org/En/DragDrop/DataTransfer + - Should be no different than normal url handling.. +- Local Storage + - https://developer.mozilla.org/en/DOM/Storage#localStorage + - Disabled by dom storage pref.. + - Private browsing mode has its own DB + - Memory only? + - Disk Avoidance of gStorage and local storage: + - mSessionOnly set via nsDOMStorage::CanUseStorage() + - Seems to be set to true if cookies are session-only or private + browsing mode + - Our cookies are NOT session-only with dual cookie jars + - but this is ok if we clear the session storage.. + - XXX: Technically clearing session storage may break + sites if cookies remain though + - nsDOMStoragePersistentDB not used if mSessionOnly + - Can clear with nsDOMStorage::ClearAll() or nsIDOMStorage2::clear()? + - These only work for a particular storage. There's both global now + and per-origin storage instances + - Each docshell has tons of storages for each origin contained in it + - Toggling dom.storage.enabled does not clear existing storage + - Oh HOT! cookie-changed to clear cookies clears all storages! + - happens for both ff3.0 and 3.5 in dom/src/storage/nsDOMStorage.cpp + - Conclusion: + - can safely enable dom storage + - May have minor buggy usability issues unless we preserve it + when user is preserving cookies.. + +Second Pass: Verification of all Torbutton Assumptions +- "Better privacy controls" + - Basically UI stuff for prefs we set already + - address bar search disable option is interesting, but not + torbutton's job to toggle. Users will hate us. +- Private browsing + - https://developer.mozilla.org/En/Supporting_private_browsing_mode + - We should consider an option (off by default) to enable PBM during + toggle + - It is a good idea because it will let our users use DOM storage + safely and also may cause their plugins and other addons to be + safe + - Doing it always will cause the user to lose fine-grained control + of many settings + - Also we'll need to prevent them from leaving without toggling tor + - Stuff the emit does (grep for NS_PRIVATE_BROWSING_SWITCH_TOPIC and + "private-browsing") + - XXX: clear mozilla.org/security/sdr;1. We should too! Wtf is it?? + - Neg. Best to let them handle this. Users will be annoyed + at having to re-enter their passwords.. + - They also clear the console service.. + - Recommend watching private-browsing-cancel-vote and blocking if + we are performing a db operation + - Maybe we want to block transitions during our toggle for safety + - XXX: They also clear general.open_location.last_url + - XXX: mozilla.org/permissionmanager + - XXX: mozilla.org/content-pref/service + - XXX: Sets browser.zoom.siteSpecific to false + - Interesting.. They clear their titles.. I wonder if some + window managers log titles.. But that level of surveillance is + unbeatable.. + - XXX: Unless there is some way for flash or script to read titles? + - They empty the clipboard.. + - Can js access the clipboard?? ... + - Yes, but needs special pref+confirmation box + - http://www.dynamic-tools.net/toolbox/copyToClipboard/ + - They clear cache.. + - Cookies: + - Use in-memory table that is different than their default + - This could fuck up our cookie storage options + - We could maybe prevent them from getting this + event by wrapping nsCookieService::Observe(). Lullz.. + - NavHistory: + - XXX: nsNavHistory::AutoCompleteFeedback() doesn't track + awesomebar choices for feedback.. Is this done on disk? + - Don't add history entries + - We should block this observe event too if we can.. + - The session store stops storing tabs + - We could block this observe + - XXX: They expunge private temporary files on exit from PMB + - This is not done normally until browser exit or + "on-profile-change" + - emits browser:purge-domain-data.. Mostly just for session + editing it appears + - Direct component query for pbs.privateBrowsingEnabled + - This is where we have no ability to provide certain option + control + - browser.js seems to prevent user from allowing blocked + popups? + - Some items in some places context menu get blocked: + - Can't delete items from history? placesContext_deleteHost + - nsCookiePermission::InPrivateBrowsing() calls direct + - but is irellevant + - Form history cannot be saved while in PBM.. :( + - User won't be prompted for adding login passwords.. + - Can't remember prefs on content types + - Many components read this value upon init: + - This fucks up our observer game if tor starts enabled + - NavHistory and cookie and dl manager + - We could just wrap the bool on startup and lie + and emit later... :/ + - Or! emit an exit and an enter always at startup if tor is + enabled. + - Read iSec report + - Compare to Chrome + - API use cases +- SessionStore + - Has been reworked with observers and write methods. Should use those. +- security.enable_ssl2 to clear session id + - Still cleared +- browser.sessionstore.max_tabs_undo + - Yep. +- SafeBrowsing Update Key removed on cookie clear still? + - Yep. +- Livemark updates have kill events now +- Test if nsICertStore is still buggy... + +Third Pass: Exploit Auditing +- Remote fonts +- SVG with HTML +- Javascript threads+locking +- Ogg theora and vorbis codecs +- SQLite + + +- https://developer.mozilla.org/en/Firefox_3_for_developers diff --git a/docs/audits/FF4_AUDIT b/docs/audits/FF4_AUDIT new file mode 100644 index 0000000..7830eb3 --- /dev/null +++ b/docs/audits/FF4_AUDIT @@ -0,0 +1,50 @@ +- Review of https://developer.mozilla.org/en/Firefox_4_for_developers + - Potential proxy issues + - DocShell and plugins inside createHTMLDocument? + - https://developer.mozilla.org/en/DOM/DOMImplementation.createHTMLDocument + - WebSockets? + - Media attributes? + - "buffered" + - "preload" + - new codecs? + - What the hell is a blob url? + - https://developer.mozilla.org/en/DOM/window.createBlobURL + - https://developer.mozilla.org/en/DOM/window.revokeBlobURL + - Seems only relevent to FS injection.. + - WebThreads are OK: + - https://developer.mozilla.org/En/Using_web_workers + - Network activity blocked by content policy + - Fingerprinting issues: + - New screen attributes + - https://developer.mozilla.org/en/DOM/window.mozInnerScreenX, Y + - High Res Animation Timers: + - https://developer.mozilla.org/en/DOM/window.mozAnimationStartTime + - https://developer.mozilla.org/en/DOM/Animations_using_MozBeforePaint + - 50-60hz max.. Can we leverage this? + - timeStamps on keystroke events + - https://developer.mozilla.org/en/DOM/event.timeStamp + - Bounding rectangles -> window sizes? + - Maybe not display sizes, but seems possible to fingerprint rendered + content size.. ugh. + - https://developer.mozilla.org/en/DOM/element.getBoundingClientRect + - https://developer.mozilla.org/en/dom:range + - CSS resize, media queries, etc.. + - WebGL may also expose screen properties and video card properties: + - https://developer.mozilla.org/en/WebGL + - https://www.khronos.org/registry/webgl/specs/1.0/#5.2 + - https://www.khronos.org/registry/webgl/specs/1.0/#5.11 + - SVG needs auditing. It may also expose absolute coords, but appears OK + - https://developer.mozilla.org/en/SVG/SVG_animation_with_SMIL + - Mouse events reveal desktop coordinates + - https://bugzilla.mozilla.org/show_bug.cgi?id=503943 + - https://developer.mozilla.org/en/DOM/Event/UIEvent/MouseEvent + - Actual screen dimensions not exposed + - Identifier Storage + - Content Secuity Properties may need clearing: + - https://developer.mozilla.org/en/Security/CSP + - STS cache needs clearing + - New window.history functions may allow state smuggling + - https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history + +- New Javascript hooking options may help improve Date() hooks: + - https://developer.mozilla.org/en/JavaScript/New_in_JavaScript/1.8.5

1 0