tor-commits December 2011

tor-commits@lists.torproject.org

17 participants
533 discussions

[obfsproxy/master] Add some more content to the architecture doc
by nickm＠torproject.org 29 Dec '11

29 Dec '11

commit d8f3f69dc761140a34653aff3b1db8c6925809f9 Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Dec 29 11:10:29 2011 -0500 Add some more content to the architecture doc --- doc/obfsproxy_architecture.txt | 65 ++++++++++++++++++++++++++------------- 1 files changed, 43 insertions(+), 22 deletions(-) diff --git a/doc/obfsproxy_architecture.txt b/doc/obfsproxy_architecture.txt index 19809e6..299eb7d 100644 --- a/doc/obfsproxy_architecture.txt +++ b/doc/obfsproxy_architecture.txt @@ -1,26 +1,42 @@ - Obfsproxy Architecture + Obfsproxy Architecture + + George Kadianakis + Nick Mathewson 1. Top Level View obfsproxy is a pluggable transports proxy written in C. It's - compliant to the pluggable transports specification [0], and its + compliant to the Tor pluggable transports specification [0], and its modular architecture allows it to support multiple pluggable transports. - # It supports two modes of operation, the 'external proxy' mode and - # the 'managed proxy' mode. When used as an 'external proxy', the - # user configures obfsproxy using the command-line. When used as a - # 'managed proxy', obfsproxy can be configured by another application - # using the managed proxy configuration protocol defined in the - # pluggable transports specification [0]. + It supports two modes of operation, the 'external proxy' mode and + the 'managed proxy' mode. When used as an 'external proxy', the + user configures obfsproxy using the command-line. When used as a + 'managed proxy', obfsproxy can be configured by another application + using the managed proxy configuration protocol defined in the + pluggable transports specification [0]. + + While designed for use with Tor, it should be suitable for + integration with other protocols as well. + + Note also that although obfsproxy is designed to support multiple + protocols and obfuscation mechanisms, it is NOT required (or + intended) that every pluggable transport for Tor be implemented as a + module for obfsproxy. The point of pluggable transports [0] after + all, is that not every obfuscation mechanism should or can be part of + the same program. 2. Modularity - obfsproxy uses callbacks and object-oriented programming principles - to achieve modularity. This way, a developer who is interested in - writing a pluggable transport doesn't need to know obfsproxy's code - inside out. + obfsproxy tries to isolate its modules using callbacks and + vtable-based object-oriented programming principles. This way, a + developer who is interested in writing a pluggable transport doesn't + need to know obfsproxy's code inside out. + + obfsproxy outsources its networking and cryptography functionality to + Libevent 2.x and OpenSSL respectively. 2.1. Callbacks @@ -47,6 +63,11 @@ Developers that make good use of obfsproxy's callbacks and OOP, should be able to implement most pluggable transports. + The implementation uses the standard OOP-in-C trick of having a + subclass's type be a structure that includes the parent class's + structure as its first member, and having polymorphic functions be + implemented as an explicit vtable structure of function pointers. + 3. Codebase tour This section does a short introduction into some areas of obfsproxy's @@ -65,22 +86,22 @@ and 'downstream' connections. The upstream connection of a circuit communicates in cleartext with the higher-level program that wishes to make use of our obfuscation service. The downstream connection - commmunicates in an obfuscated fashion with the remote peer that the + communicates in an obfuscated fashion with the remote peer that the higher-level client wishes to contact. The diagram below might help demonstrate the relationship between connections and circuits: - downstream + downstream - 'circuit_t C' 'conn_t CD' 'conn_t SD' 'circuit_t S' - +-----------+ +-----------+ - upstream ----|obfsproxy c|-------------|obfsproxy s|---- upstream - | +-----------+ +-----------+ | - 'conn_t CU'| |'conn_t SU' - +------------+ +--------------+ - | Tor Client | | Tor Bridge | - +------------+ +--------------+ + 'circuit_t C' 'conn_t CD' 'conn_t SD' 'circuit_t S' + +-----------+ +-----------+ + upstream ----|obfsproxy c|----------|obfsproxy s|---- upstream + | +-----------+ ^ +-----------+ | + 'conn_t CU'| | |'conn_t SU' + +------------+ Sent over +--------------+ + | Tor Client | the net | Tor Bridge | + +------------+ +--------------+ In the above diagram, "obfsproxy c" is the client-side obfsproxy, and "obfsproxy s" is the server-side obfsproxy. "conn_t CU" is the

1 0

[obfsproxy/master] Minor correction on the handshake part of doc/protocol-spec.txt.
by nickm＠torproject.org 29 Dec '11

29 Dec '11

commit 2b0682cdaaa1338db7dc922854a9ff1da91952f6 Author: George Kadianakis <desnacked(a)gmail.com> Date: Mon Dec 19 18:39:05 2011 +0100 Minor correction on the handshake part of doc/protocol-spec.txt. Servers send their initial message right after clients connect to them. --- doc/protocol-spec.txt | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/protocol-spec.txt b/doc/protocol-spec.txt index 4035b23..c0b0578 100644 --- a/doc/protocol-spec.txt +++ b/doc/protocol-spec.txt @@ -66,7 +66,7 @@ INIT_SEED | E(INIT_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN)) - and the responder replies with: + and the responder sends: RESP_SEED | E(RESP_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN))

1 0

r25275: {website} Update design doc to describe CSS media query and font patch (website/trunk/projects/torbrowser/design)
by Mike Perry 29 Dec '11

29 Dec '11

Author: mikeperry Date: 2011-12-29 04:23:25 +0000 (Thu, 29 Dec 2011) New Revision: 25275 Modified: website/trunk/projects/torbrowser/design/index.html.en Log: Update design doc to describe CSS media query and font patches. Modified: website/trunk/projects/torbrowser/design/index.html.en =================================================================== --- website/trunk/projects/torbrowser/design/index.html.en 2011-12-29 04:10:04 UTC (rev 25274) +++ website/trunk/projects/torbrowser/design/index.html.en 2011-12-29 04:23:25 UTC (rev 25275) @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">Dec 16 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2532509">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Pr ivacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Cli ck-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2532509"></a>1. Introduction</h2></div></div></div><p> +<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>The Design and Implementation of the Tor Browser [DRAFT]</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div class="article" title="The Design and Implementation of the Tor Browser [DRAFT]"><div class="titlepage"><div><div><h2 class="title"><a id="design"></a>The Design and Implementation of the Tor Browser [DRAFT]</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Mike</span> <span class="surname">Perry</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:mikeperry#torproject org">mikeperry#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Erinn</span> <span class="surname">Clark</span></h3><div class="affiliation"><div class="address"><p><code class= "email"><<a class="email" href="mailto:erinn#torproject org">erinn#torproject org</a>></code></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Steven</span> <span class="surname">Murdoch</span></h3><div class="affiliation"><div class="address"><p><code class="email"><<a class="email" href="mailto:sjmurdoch#torproject org">sjmurdoch#torproject org</a>></code></p></div></div></div></div><div><p class="pubdate">Dec 28 2011</p></div></div><hr /></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id2619754">1. Introduction</a></span></dt><dd><dl><dt><span class="sect2"><a href="#adversary">1.1. Adversary Model</a></span></dt></dl></dd><dt><span class="sect1"><a href="#DesignRequirements">2. Design Requirements and Philosophy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#security">2.1. Security Requirements</a></span></dt><dt><span class="sect2"><a href="#privacy">2.2. Pr ivacy Requirements</a></span></dt><dt><span class="sect2"><a href="#philosophy">2.3. Philosophy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Implementation">3. Implementation</a></span></dt><dd><dl><dt><span class="sect2"><a href="#proxy-obedience">3.1. Proxy Obedience</a></span></dt><dt><span class="sect2"><a href="#state-separation">3.2. State Separation</a></span></dt><dt><span class="sect2"><a href="#disk-avoidance">3.3. Disk Avoidance</a></span></dt><dt><span class="sect2"><a href="#app-data-isolation">3.4. Application Data Isolation</a></span></dt><dt><span class="sect2"><a href="#identifier-linkability">3.5. Cross-Origin Identifier Unlinkability</a></span></dt><dt><span class="sect2"><a href="#fingerprinting-linkability">3.6. Cross-Origin Fingerprinting Unlinkability</a></span></dt><dt><span class="sect2"><a href="#new-identity">3.7. Long-Term Unlinkability via "New Identity" button</a></span></dt><dt><span class="sect2"><a href="#click-to-play">3.8. Cli ck-to-play for plugins and invasive content</a></span></dt><dt><span class="sect2"><a href="#firefox-patches">3.9. Description of Firefox Patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Packaging">4. Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#build-security">4.1. Build Process Security</a></span></dt><dt><span class="sect2"><a href="#addons">4.2. External Addons</a></span></dt><dt><span class="sect2"><a href="#prefs">4.3. Pref Changes</a></span></dt><dt><span class="sect2"><a href="#update-mechanism">4.4. Update Security</a></span></dt></dl></dd><dt><span class="sect1"><a href="#Testing">5. Testing</a></span></dt><dd><dl><dt><span class="sect2"><a href="#SingleStateTesting">5.1. Single state testing</a></span></dt></dl></dd></dl></div><div class="sect1" title="1. Introduction"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="id2619754"></a>1. Introduction</h2></div></div></div><p> This document describes the <a class="link" href="#adversary" title="1.1. Adversary Model">adversary model</a>, <a class="link" href="#DesignRequirements" title="2. Design Requirements and Philosophy">design requirements</a>, @@ -473,13 +473,13 @@ Tor Browser State is separated from existing browser state through use of a custom Firefox profile. Furthermore, plugins are disabled, which prevents Flash cookies from leaking from a pre-existing Flash directory. - </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2564908"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p></div><div class="sect2" title="3.3. Disk Avoidance"><div class="titlepage"><div><div><h3 class="title"><a id="disk-avoidance"></a>3.3. Disk Avoidance</h3></div></div></div><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2652153"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> Tor Browser MUST (at user option) prevent all disk records of browser activity. The user should be able to optionally enable URL history and other history features if they so desire. Once we <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/3100" target="_top">simplify the preferences interface</a>, we will likely just enable Private Browsing mode by default to handle this goal. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2562959"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2650204"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> For now, Tor Browser blocks write access to the disk through Torbutton using several Firefox preferences. @@ -544,7 +544,7 @@ context-menu option to drill down into specific types of state or permissions. An example of this simplification can be seen in Figure 1. - </p><div class="figure"><a id="id2547125"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> + </p><div class="figure"><a id="id2634370"></a><p class="title"><b>Figure 1. Improving the Privacy UI</b></p><div class="figure-contents"><div class="mediaobject" align="center"><img src="CookieManagers.png" align="middle" alt="Improving the Privacy UI" /></div><div class="caption"><p></p> On the left is the standard Firefox cookie manager. On the right is a mock-up of how isolating identifiers to the URL bar origin might simplify the privacy @@ -825,16 +825,16 @@ number of bits available to the adversary while avoiding the rendering and language issues of supporting a global font set. - </p><p><span class="command"><strong>Design Goal:</strong></span> - -We intend to <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2872" target="_top">limit the number of -fonts</a> a url bar origin can load, gracefully degrading to built-in -and/or remote fonts once the limit is reached. - </p><p><span class="command"><strong>Implementation Status:</strong></span> -Aside from disabling plugins to prevent enumeration, we have not yet -implemented any defense against CSS or Javascript fonts. +We disable plugins, which prevents font 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 by patching Firefox. 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 +limits are reached, the browser behaves as if +<span class="command"><strong>browser.display.use_document_fonts</strong></span> was reached. We are +still working to determine optimal values for these prefs. </p></li><li class="listitem">User Agent and HTTP Headers <p><span class="command"><strong>Design Goal:</strong></span> @@ -874,10 +874,15 @@ We have implemented the above strategy for Javascript using Torbutton's <a class="ulink" href="https://gitweb.torproject.org/torbutton.git/blob/HEAD:/src/chrome/content/j…" target="_top">JavaScript hooks</a> as well as 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>. However, CSS Media Queries -still <a class="ulink" href="https://trac.torproject.org/projects/tor/ticket/2875" target="_top">need -to be dealt with</a>. +new windows based on desktop resolution</a>. Additionally, we patch +Firefox to cause CSS Media Queries to use the client content window size +for all desktop size related media queries. + </p><p> + +As far as we know, this fully satisfies our design goals for desktop +resolution information. + </p></li><li class="listitem">Timezone and clock offset <p><span class="command"><strong>Design Goal:</strong></span> @@ -962,11 +967,11 @@ </p></li></ol></div></div><div class="sect2" title="3.7. Long-Term Unlinkability via "New Identity" button"><div class="titlepage"><div><div><h3 class="title"><a id="new-identity"></a>3.7. Long-Term Unlinkability via "New Identity" button</h3></div></div></div><p> In order to avoid long-term linkability, we provide a "New Identity" context menu option in Torbutton. - </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2550338"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </p><div class="sect3" title="Design Goal:"><div class="titlepage"><div><div><h4 class="title"><a id="id2637889"></a>Design Goal:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> All linkable identifiers and browser state MUST be cleared by this feature. - </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2529377"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> + </blockquote></div></div><div class="sect3" title="Implementation Status:"><div class="titlepage"><div><div><h4 class="title"><a id="id2630536"></a>Implementation Status:</h4></div></div></div><div class="blockquote"><blockquote class="blockquote"> First, Torbutton disables all open tabs and windows by tagging them and blocking them via the nsIContentPolicy, and then closes each tab and @@ -1095,7 +1100,7 @@ all keep-alive connections that still happen to be open. This event is emitted by the <a class="link" href="#new-identity" title="3.7. Long-Term Unlinkability via "New Identity" button">New Identity</a> button. - </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2524128"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2524142"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2524152"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> + </p></li></ol></div></div></div><div class="sect1" title="4. Packaging"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Packaging"></a>4. Packaging</h2></div></div></div><p> </p><div class="sect2" title="4.1. Build Process Security"><div class="titlepage"><div><div><h3 class="title"><a id="build-security"></a>4.1. Build Process Security</h3></div></div></div><p> </p></div><div class="sect2" title="4.2. External Addons"><div class="titlepage"><div><div><h3 class="title"><a id="addons"></a>4.2. External Addons</h3></div></div></div><p> </p><div class="sect3" title="Included Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611402"></a>Included Addons</h4></div></div></div></div><div class="sect3" title="Excluded Addons"><div class="titlepage"><div><div><h4 class="title"><a id="id2611409"></a>Excluded Addons</h4></div></div></div></div><div class="sect3" title="Dangerous Addons"><div class="titlepage"><div><div><h4 cla ss="title"><a id="id2611419"></a>Dangerous Addons</h4></div></div></div></div></div><div class="sect2" title="4.3. Pref Changes"><div class="titlepage"><div><div><h3 class="title"><a id="prefs"></a>4.3. Pref Changes</h3></div></div></div><p> </p></div><div class="sect2" title="4.4. Update Security"><div class="titlepage"><div><div><h3 class="title"><a id="update-mechanism"></a>4.4. Update Security</h3></div></div></div><p> </p></div></div><div class="sect1" title="5. Testing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="Testing"></a>5. Testing</h2></div></div></div><p> The purpose of this section is to cover all the known ways that Tor browser security can be subverted from a penetration testing perspective. The hope

1 0

r25274: {projects} add some properties (projects/presentations)
by Sebastian Hahn 29 Dec '11

29 Dec '11

Author: sebastian Date: 2011-12-29 04:10:04 +0000 (Thu, 29 Dec 2011) New Revision: 25274 Modified: projects/presentations/slides-28c3.odp projects/presentations/slides-28c3.pdf Log: add some properties Property changes on: projects/presentations/slides-28c3.odp ___________________________________________________________________ Added: mime-type + application/vnd.oasis.opendocument.presentation Property changes on: projects/presentations/slides-28c3.pdf ___________________________________________________________________ Added: mime-type + application/pdf

1 0

r25273: {} Add the 28c3 slides for Roger (projects/presentations)
by Sebastian Hahn 29 Dec '11

29 Dec '11

Author: sebastian Date: 2011-12-29 03:46:28 +0000 (Thu, 29 Dec 2011) New Revision: 25273 Added: projects/presentations/slides-28c3.odp projects/presentations/slides-28c3.pdf Log: Add the 28c3 slides for Roger Added: projects/presentations/slides-28c3.odp =================================================================== (Binary files differ) Property changes on: projects/presentations/slides-28c3.odp ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: projects/presentations/slides-28c3.pdf =================================================================== (Binary files differ) Property changes on: projects/presentations/slides-28c3.pdf ___________________________________________________________________ Added: svn:mime-type + application/octet-stream

1 0

[tor/master] Authorities reject insecure Tors.
by nickm＠torproject.org 28 Dec '11

28 Dec '11

commit 9bcb18738747e12629c38ae366b96993e2002859 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Dec 27 21:47:04 2011 -0500 Authorities reject insecure Tors. This patch should make us reject every Tor that was vulnerable to CVE-2011-0427. Additionally, it makes us reject every Tor that couldn't handle RELAY_EARLY cells, which helps with proposal 110 (#4339). --- changes/bug4788 | 6 ++++++ src/or/dirserv.c | 23 ++++++++++++----------- 2 files changed, 18 insertions(+), 11 deletions(-) diff --git a/changes/bug4788 b/changes/bug4788 new file mode 100644 index 0000000..d65c001 --- /dev/null +++ b/changes/bug4788 @@ -0,0 +1,6 @@ + o Minor features (directory server): + - Directory servers now reject versions of Tor older than 0.2.1.30, + and Tor versions between 0.2.2.1-alpha and 0.2.2.20-alpha + (inclusive). These versions accounted for only a small fraction of + the Tor network, and have numerous known security issues. Resolves + issue #4788. diff --git a/src/or/dirserv.c b/src/or/dirserv.c index 634b3ec..0308d4d 100644 --- a/src/or/dirserv.c +++ b/src/or/dirserv.c @@ -388,19 +388,20 @@ dirserv_get_status_impl(const char *id_digest, const char *nickname, strmap_size(fingerprint_list->fp_by_name), digestmap_size(fingerprint_list->status_by_digest)); - /* Tor 0.2.0.26-rc is the oldest version that currently caches the right - * directory information. Once more of them die off, we should raise this - * minimum. */ - if (platform && !tor_version_as_new_as(platform,"0.2.0.26-rc")) { + /* Versions before Tor 0.2.1.30 have known security issues that + * make them unsuitable for the current network. */ + if (platform && !tor_version_as_new_as(platform,"0.2.1.30")) { if (msg) - *msg = "Tor version is far too old to work."; - return FP_REJECT; - } else if (platform && tor_version_as_new_as(platform,"0.2.1.3-alpha") - && !tor_version_as_new_as(platform, "0.2.1.19")) { - /* These versions mishandled RELAY_EARLY cells on rend circuits. */ - if (msg) - *msg = "Tor version is too buggy to work."; + *msg = "Tor version is insecure. Please upgrade!"; return FP_REJECT; + } else if (platform && tor_version_as_new_as(platform,"0.2.2.1-alpha")) { + /* Versions from 0.2.2.1-alpha...0.2.2.20-alpha have known security + * issues that make them unusable for the current network */ + if (!tor_version_as_new_as(platform, "0.2.2.21-alpha")) { + if (msg) + *msg = "Tor version is insecure. Please upgrade!"; + return FP_REJECT; + } } result = dirserv_get_name_status(id_digest, nickname);

1 0

[tor/master] Merge remote-tracking branch 'public/bug4788' into maint-0.2.2
by nickm＠torproject.org 28 Dec '11

28 Dec '11

commit 84bf8e3808d5f10e5ffd0d9f9f31760c6d3875ab Merge: c563551 9bcb187 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Dec 28 16:50:45 2011 -0500 Merge remote-tracking branch 'public/bug4788' into maint-0.2.2 changes/bug4788 | 6 ++++++ src/or/dirserv.c | 23 ++++++++++++----------- 2 files changed, 18 insertions(+), 11 deletions(-)

1 0

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

28 Dec '11

commit bfae41328e9bbd29a3c3df2cd6b7c5d0caf83ada Merge: f71d63e 84bf8e3 Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Dec 28 16:52:31 2011 -0500 Merge remote-tracking branch 'origin/maint-0.2.2' changes/bug4788 | 6 ++++++ src/or/dirserv.c | 23 ++++++++++++----------- 2 files changed, 18 insertions(+), 11 deletions(-)

1 0

[tor/maint-0.2.2] Authorities reject insecure Tors.
by nickm＠torproject.org 28 Dec '11

28 Dec '11

1 0

[tor/maint-0.2.2] Merge remote-tracking branch 'public/bug4788' into maint-0.2.2
by nickm＠torproject.org 28 Dec '11

28 Dec '11

1 0

← Newer
1
2
3
4
5
6
7
8
...
54
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits December 2011