- tor-commits - lists.torproject.org

[stem/master] Function and testing for cookie authentication
by atagar＠torproject.org 01 Dec '11

01 Dec '11

commit 8fd556572a170d06359458a37848d947313984d2 Author: Damian Johnson <atagar(a)torproject.org> Date: Thu Dec 1 10:10:43 2011 -0800 Function and testing for cookie authentication Adding a function for password authentication. This includes checks for the file's existance and that the size is valid (for 4303). --- stem/connection.py | 56 ++++++++++++++++++ test/integ/connection/authentication.py | 94 ++++++++++++++++++++++-------- 2 files changed, 125 insertions(+), 25 deletions(-) diff --git a/stem/connection.py b/stem/connection.py index 3ea5747..0b654d8 100644 --- a/stem/connection.py +++ b/stem/connection.py @@ -14,7 +14,9 @@ ProtocolInfoResponse - Reply from a PROTOCOLINFO query. +- convert - parses a ControlMessage, turning it into a ProtocolInfoResponse """ +import os import logging +import binascii import stem.socket import stem.version @@ -38,6 +40,9 @@ LOGGER = logging.getLogger("stem") AuthMethod = stem.util.enum.Enum("NONE", "PASSWORD", "COOKIE", "UNKNOWN") +AUTH_COOKIE_MISSING = "Authentication failed: '%s' doesn't exist" +AUTH_COOKIE_WRONG_SIZE = "Authentication failed: authentication cookie '%s' is the wrong size (%i bytes instead of 32)" + def authenticate_none(control_socket): """ Authenticates to an open control socket. All control connections need to @@ -92,6 +97,57 @@ def authenticate_password(control_socket, password): if str(auth_response) != "OK": raise ValueError(str(auth_response)) +def authenticate_cookie(control_socket, cookie_path): + """ + Authenticates to a control socket that uses the contents of an authentication + cookie (generated via the CookieAuthentication torrc option). This does basic + validation that this is a cookie before presenting the contents to the + socket. + + If authentication fails then tor will close the control socket. + + Arguments: + control_socket (stem.socket.ControlSocket) - socket to be authenticated + cookie_path (str) - path of the authentication cookie to send to tor + + Raises: + ValueError if the authentication credentials aren't accepted + OSError if the cookie file doesn't exist or we're unable to read it + stem.socket.ProtocolError the content from the socket is malformed + stem.socket.SocketError if problems arise in using the socket + """ + + if not os.path.exists(cookie_path): + raise OSError(AUTH_COOKIE_MISSING % cookie_path) + + # Abort if the file isn't 32 bytes long. This is to avoid exposing arbitrary + # file content to the port. + # + # Without this a malicious socket could, for instance, claim that + # '~/.bash_history' or '~/.ssh/id_rsa' was its authentication cookie to trick + # us into reading it for them with our current permissions. + # + # https://trac.torproject.org/projects/tor/ticket/4303 + + auth_cookie_size = os.path.getsize(cookie_path) + + if auth_cookie_size != 32: + raise ValueError(AUTH_COOKIE_WRONG_SIZE % (cookie_path, auth_cookie_size)) + + try: + auth_cookie_file = open(cookie_path, "r") + auth_cookie_contents = auth_cookie_file.read() + auth_cookie_file.close() + + control_socket.send("AUTHENTICATE %s" % binascii.b2a_hex(auth_cookie_contents)) + auth_response = control_socket.recv() + + # if we got anything but an OK response then error + if str(auth_response) != "OK": + raise ValueError(str(auth_response)) + except IOError, exc: + raise OSError(exc) + def get_protocolinfo_by_port(control_addr = "127.0.0.1", control_port = 9051, get_socket = False): """ Issues a PROTOCOLINFO query to a control port, getting information about the diff --git a/test/integ/connection/authentication.py b/test/integ/connection/authentication.py index c3759e6..7883c8a 100644 --- a/test/integ/connection/authentication.py +++ b/test/integ/connection/authentication.py @@ -3,6 +3,7 @@ Integration tests for authenticating to the control socket via stem.connection.authenticate_* functions. """ +import os import unittest import functools @@ -25,17 +26,18 @@ class TestAuthenticate(unittest.TestCase): integ target to exercise the widest range of use cases. """ + def setUp(self): + connection_type = test.runner.get_runner().get_connection_type() + + # none of these tests apply if there's no control connection + if connection_type == test.runner.TorConnection.NONE: + self.skipTest("(no connection)") + def test_authenticate_none(self): """ Tests the authenticate_none function. """ - runner = test.runner.get_runner() - connection_type = runner.get_connection_type() - - if connection_type == test.runner.TorConnection.NONE: - self.skipTest("(no connection)") - expect_success = self._is_authenticateable(stem.connection.AuthMethod.NONE) self._check_auth(stem.connection.AuthMethod.NONE, None, expect_success) @@ -44,12 +46,6 @@ class TestAuthenticate(unittest.TestCase): Tests the authenticate_password function. """ - runner = test.runner.get_runner() - connection_type = runner.get_connection_type() - - if connection_type == test.runner.TorConnection.NONE: - self.skipTest("(no connection)") - expect_success = self._is_authenticateable(stem.connection.AuthMethod.PASSWORD) self._check_auth(stem.connection.AuthMethod.PASSWORD, test.runner.CONTROL_PASSWORD, expect_success) @@ -61,6 +57,42 @@ class TestAuthenticate(unittest.TestCase): self._check_auth(stem.connection.AuthMethod.PASSWORD, "blarg", expect_success) self._check_auth(stem.connection.AuthMethod.PASSWORD, "this has a \" in it", expect_success) + def test_authenticate_cookie(self): + """ + Tests the authenticate_cookie function. + """ + + test_path = test.runner.get_runner().get_auth_cookie_path() + expect_success = self._is_authenticateable(stem.connection.AuthMethod.COOKIE) + self._check_auth(stem.connection.AuthMethod.COOKIE, test_path, expect_success) + + def test_authenticate_cookie_missing(self): + """ + Tests the authenticate_cookie function with a path that really, really + shouldn't exist. + """ + + test_path = "/if/this/exists/then/they're/asking/for/a/failure" + expected_exc = OSError(stem.connection.AUTH_COOKIE_MISSING % test_path) + self._check_auth(stem.connection.AuthMethod.COOKIE, test_path, False, expected_exc) + + def test_authenticate_cookie_wrong_size(self): + """ + Tests the authenticate_cookie function with our torrc as an auth cookie. + This is to confirm that we won't read arbitrary files to the control + socket. + """ + + test_path = test.runner.get_runner().get_torrc_path() + auth_cookie_size = os.path.getsize(test_path) + + if auth_cookie_size == 32: + # Weird coincidence? Fail so we can pick another file to check against. + self.fail("Our torrc is 32 bytes, preventing the test_authenticate_cookie_wrong_size test from running.") + else: + expected_exc = ValueError(stem.connection.AUTH_COOKIE_WRONG_SIZE % (test_path, auth_cookie_size)) + self._check_auth(stem.connection.AuthMethod.COOKIE, test_path, False, expected_exc) + def _get_socket_auth(self): """ Provides the types of authentication that our current test socket accepts. @@ -99,7 +131,7 @@ class TestAuthenticate(unittest.TestCase): elif auth_type == stem.connection.AuthMethod.COOKIE: return cookie_auth else: return False - def _check_auth(self, auth_type, auth_value, expect_success): + def _check_auth(self, auth_type, auth_value, expect_success, failure_exc = None): """ Attempts to use the given authentication function against our connection. If this works then checks that we can use the connection. If not then we @@ -111,6 +143,8 @@ class TestAuthenticate(unittest.TestCase): auth_value (str) - value to be provided to the authentication function expect_success (bool) - true if the authentication should succeed, false otherwise + failure_exc (Exception) - exception that we want to assert is raised, if + None then we'll check for an auth mismatch error """ runner = test.runner.get_runner() @@ -124,7 +158,7 @@ class TestAuthenticate(unittest.TestCase): elif auth_type == stem.connection.AuthMethod.PASSWORD: auth_function = stem.connection.authenticate_password elif auth_type == stem.connection.AuthMethod.COOKIE: - auth_function = None # TODO: fill in + auth_function = stem.connection.authenticate_cookie else: raise ValueError("unexpected auth type: %s" % auth_type) @@ -143,20 +177,30 @@ class TestAuthenticate(unittest.TestCase): self.assertEquals("config-file=%s\nOK" % runner.get_torrc_path(), str(config_file_response)) control_socket.close() else: - if cookie_auth and password_auth: failure_msg = MULTIPLE_AUTH_FAIL - elif cookie_auth: failure_msg = COOKIE_AUTH_FAIL - else: - # if we're attempting to authenticate with a password then it's a - # truncated message - - if auth_type == stem.connection.AuthMethod.PASSWORD: - failure_msg = INCORRECT_PASSWORD_FAIL + # if unset then determine what the general authentication error should + # look like + + if not failure_exc: + if cookie_auth and password_auth: + failure_exc = ValueError(MULTIPLE_AUTH_FAIL) + elif cookie_auth: + failure_exc = ValueError(COOKIE_AUTH_FAIL) else: - failure_msg = PASSWORD_AUTH_FAIL + # if we're attempting to authenticate with a password then it's a + # truncated message + + if auth_type == stem.connection.AuthMethod.PASSWORD: + failure_exc = ValueError(INCORRECT_PASSWORD_FAIL) + else: + failure_exc = ValueError(PASSWORD_AUTH_FAIL) try: auth_function() self.fail() - except ValueError, exc: - self.assertEqual(failure_msg, str(exc)) + except Exception, exc: + # we can't check exception equality directly because it contains other + # attributes which will fail + + self.assertEqual(type(failure_exc), type(exc)) + self.assertEqual(str(failure_exc), str(exc))

1 0

[stem/master] Skipping get_pid_by_name test when doomed
by atagar＠torproject.org 01 Dec '11

01 Dec '11

commit 2c91e342a58dd389d5cb777cb1f4f59bfc198f71 Author: Damian Johnson <atagar(a)torproject.org> Date: Wed Nov 30 19:02:32 2011 -0800 Skipping get_pid_by_name test when doomed The get_pid_by_name function fails when there's multiple instances of a process with that name. As a result the integ test for the function fails if there's extra tor instances running on the system. Using pgrep to check for other instances and skip those tests if they'd be doomed to failure. --- test/integ/util/system.py | 41 ++++++++++++++++++++++++++++++++++------- 1 files changed, 34 insertions(+), 7 deletions(-) diff --git a/test/integ/util/system.py b/test/integ/util/system.py index dfce42d..d1e9f88 100644 --- a/test/integ/util/system.py +++ b/test/integ/util/system.py @@ -16,6 +16,18 @@ class TestSystem(unittest.TestCase): running. """ + is_extra_tor_running = None + + def setUp(self): + # Try to figure out if there's more than one tor instance running. This + # check will fail if pgrep is unavailable (for instance on bsd) but this + # isn't the end of the world. It's just used to skip tests if they should + # legitemately fail. + + if self.is_extra_tor_running == None: + pgrep_results = stem.util.system.call("pgrep -x tor") + self.is_extra_tor_running = len(pgrep_results) > 1 + def tearDown(self): # resets call mocking back to being disabled stem.util.system.CALL_MOCKING = None @@ -45,6 +57,9 @@ class TestSystem(unittest.TestCase): will fail if there's other tor instances running. """ + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + runner = test.runner.get_runner() self.assertEquals(runner.get_pid(), stem.util.system.get_pid_by_name("tor")) self.assertEquals(None, stem.util.system.get_pid_by_name("blarg_and_stuff")) @@ -54,7 +69,9 @@ class TestSystem(unittest.TestCase): Tests the get_pid_by_name function with a pgrep response. """ - if not stem.util.system.is_available("pgrep"): + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + elif not stem.util.system.is_available("pgrep"): self.skipTest("(pgrep unavailable)") pgrep_prefix = stem.util.system.GET_PID_BY_NAME_PGREP % "" @@ -65,7 +82,9 @@ class TestSystem(unittest.TestCase): Tests the get_pid_by_name function with a pidof response. """ - if not stem.util.system.is_available("pidof"): + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + elif not stem.util.system.is_available("pidof"): self.skipTest("(pidof unavailable)") pidof_prefix = stem.util.system.GET_PID_BY_NAME_PIDOF % "" @@ -76,9 +95,12 @@ class TestSystem(unittest.TestCase): Tests the get_pid_by_name function with the linux variant of ps. """ - if not stem.util.system.is_available("ps"): + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + elif not stem.util.system.is_available("ps"): self.skipTest("(ps unavailable)") - elif stem.util.system.is_bsd(): self.skipTest("(linux only)") + elif stem.util.system.is_bsd(): + self.skipTest("(linux only)") ps_prefix = stem.util.system.GET_PID_BY_NAME_PS_LINUX % "" self._run_pid_test(ps_prefix, stem.util.system.get_pid_by_name, "tor") @@ -88,9 +110,12 @@ class TestSystem(unittest.TestCase): Tests the get_pid_by_name function with the bsd variant of ps. """ - if not stem.util.system.is_available("ps"): + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + elif not stem.util.system.is_available("ps"): self.skipTest("(ps unavailable)") - elif not stem.util.system.is_bsd(): self.skipTest("(bsd only)") + elif not stem.util.system.is_bsd(): + self.skipTest("(bsd only)") ps_cmd = stem.util.system.GET_PID_BY_NAME_PS_BSD self._run_pid_test(ps_cmd, stem.util.system.get_pid_by_name, "tor") @@ -100,7 +125,9 @@ class TestSystem(unittest.TestCase): Tests the get_pid_by_name function with a lsof response. """ - if not stem.util.system.is_available("lsof"): + if self.is_extra_tor_running: + self.skipTest("(multiple tor instances)") + elif not stem.util.system.is_available("lsof"): self.skipTest("(lsof unavailable)") lsof_prefix = stem.util.system.GET_PID_BY_NAME_LSOF % ""

1 0

[arm/master] Fix a help entry on connection panel
by atagar＠torproject.org 01 Dec '11

01 Dec '11

commit 1945566a7e57e45bb9f60c050859ac82fdc44d43 Author: Tim Wilde <github(a)krellis.org> Date: Thu Dec 1 01:37:58 2011 +0000 Fix a help entry on connection panel --- src/cli/connections/connPanel.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/cli/connections/connPanel.py b/src/cli/connections/connPanel.py index 9745176..3a8a07c 100644 --- a/src/cli/connections/connPanel.py +++ b/src/cli/connections/connPanel.py @@ -308,7 +308,7 @@ class ConnectionPanel(panel.Panel, threading.Thread): options.append(("down arrow", "scroll down a line", None)) options.append(("page up", "scroll up a page", None)) options.append(("page down", "scroll down a page", None)) - options.append(("enter", "edit configuration option", None)) + options.append(("enter", "toggle connection details", None)) options.append(("d", "raw consensus descriptor", None)) if self.isClientsAllowed():

1 0

[arm/master] Replacing 'toggle' with 'show'
by atagar＠torproject.org 01 Dec '11

01 Dec '11

commit fbf672b17899f185e799b57f24ddfafcb5e89dd5 Author: Damian Johnson <atagar(a)torproject.org> Date: Thu Dec 1 07:32:22 2011 -0800 Replacing 'toggle' with 'show' Minor change to the previous fix's wording. --- src/cli/connections/connPanel.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/cli/connections/connPanel.py b/src/cli/connections/connPanel.py index 3a8a07c..d108252 100644 --- a/src/cli/connections/connPanel.py +++ b/src/cli/connections/connPanel.py @@ -308,7 +308,7 @@ class ConnectionPanel(panel.Panel, threading.Thread): options.append(("down arrow", "scroll down a line", None)) options.append(("page up", "scroll up a page", None)) options.append(("page down", "scroll down a page", None)) - options.append(("enter", "toggle connection details", None)) + options.append(("enter", "show connection details", None)) options.append(("d", "raw consensus descriptor", None)) if self.isClientsAllowed():

1 0

[torspec/master] Add proposal 191 and 192
by nickm＠torproject.org 01 Dec '11

01 Dec '11

commit d329528c3942727c591ba8bb9100d5d65a50fd8a Author: Nick Mathewson <nickm(a)torproject.org> Date: Thu Dec 1 09:42:38 2011 -0500 Add proposal 191 and 192 --- proposals/000-index.txt | 4 + proposals/191-mitm-bridge-detection-resistance.txt | 114 ++++++++++++++++ proposals/192-store-bridge-information.txt | 137 ++++++++++++++++++++ 3 files changed, 255 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 68ce0b2..950bc38 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -111,6 +111,8 @@ Proposals by number: 188 Bridge Guards and other anti-enumeration defenses [OPEN] 189 AUTHORIZE and AUTHORIZED cells [OPEN] 190 Password-based Bridge Client Authorization [OPEN] +191 Bridge Detection Resistance against MITM-capable Adversaries [OPEN] +192 Automatically retrieve and store information about bridges [OPEN] Proposals by status: @@ -144,6 +146,8 @@ Proposals by status: 188 Bridge Guards and other anti-enumeration defenses 189 AUTHORIZE and AUTHORIZED cells 190 Password-based Bridge Client Authorization + 191 Bridge Detection Resistance against MITM-capable Adversaries + 192 Automatically retrieve and store information about bridges [for 0.2.[45].x] ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x] diff --git a/proposals/191-mitm-bridge-detection-resistance.txt b/proposals/191-mitm-bridge-detection-resistance.txt new file mode 100644 index 0000000..7709ae8 --- /dev/null +++ b/proposals/191-mitm-bridge-detection-resistance.txt @@ -0,0 +1,114 @@ +Filename: 191-mitm-bridge-detection-resistance.txt +Title: Bridge Detection Resistance against MITM-capable Adversaries +Author: George Kadianakis +Created: 07 Nov 2011 +Status: Open + +1. Overview + + Proposals 187, 189 and 190 make the first steps toward scanning + resistant bridges. They attempt to block attacks from censoring + adversaries who provoke bridges into speaking the Tor protocol. + + An attack vector that hasn't been explored in those previous + proposals is that of an adversary capable of performing Man In The + Middle attacks to Tor clients. At the moment, Tor clients using the + v3 link protocol have no way to detect such an MITM attack, and + will gladly send an VERSIONS or an AUTHORIZE cell to the MITMed + connection, thereby revealing the Tor protocol and thus the bridge. + + This proposal introduces a way for clients to detect an MITMed SSL + connection, allowing them to protect against the above attack. + +2. Motivation + + When the v3 link handshake protocol is performed, Tor's SSL + handshake is performed with the server sending a self-signed + certificate and the client blindly accepting it. This allows the + adversary to perform an MITM attack. + + A Tor client must detect the MITM attack before he initializes the + Tor protocol by sending a VERSIONS or an AUTHORIZE cell. A good + moment to detect such an MITM attack is during the SSL handshake. + + To achieve that, bridge operators provide their bridge users with a + hash digest of the public-key certificate their bridge is using for + SSL. Bridge clients store that hash digest locally and associate it + with that specific bridge. Bridge clients who have "pinned" a + bridge to a certificate "fingerprint" can thereafter validate that + their SSL connection peer is the intended bridge. + + Of course, the hash digest must be provided to users out-of-band + and before the actual SSL handshake. Usually, the bridge operator + gives the hash digest to her bridge users along with the rest of + the bridge credentials, like the bridge's address and port. + +3. Security implications + + Bridge clients who have pinned a bridge to a certificate + fingerprint will be able to detect an MITMing adversary in timely + fashion. If after detection they act as an innocuous Internet + client, they can successfully remove suspicion from the SSL + connection and subvert bridge detection. + + Pinning a certificate fingerprint and detecting an MITMing attacker + does not automatically aleviate suspicions from the bridge or the + client. Clients must have a behavior to follow after detecting the + MITM attack so that they look like innocent Netizens. This proposal + does not try to specify such a behavior. + + Implementation and use of this scheme does not render bridges and + clients immune to scanning or DPI attacks. This scheme should be + used along with bridge client authorization schemes like the ones + detailed in proposal 190. + +4. Tor Implementation + +4.1. Certificate fingerprint creation + + The certificate fingerprints used on this scheme MUST be computed + by applying the SHA256 cryptographic hash function upon the ASN.1 + DER encoding of a public-key certificate. + +4.2. Bridge side implementation + + Tor bridge implementations SHOULD provide a command line option + that exports a fully equipped Bridge line containing the bridge + address and port, the link certificate fingerprint and any other + enabled Bridge options, so that bridge operators can easily send it + to their users. + + In the case of expiring SSL certificates, Tor bridge + implementations SHOULD warn the bridge operator a sensible amount + of time before the expiration, so that she can warn her clients and + potentially rotate the certificate herself. + +4.3. Client side implementation + + Tor client implementations MUST extend their Bridge line format to + support bridge SSL certificate fingerprints. The new format is: + Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \ + ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>] + + where <fingerprint> is the bridge's SSL certificate fingerprint in + hexademical encoding. + + Tor clients who use bridges and want to pin their SSL certificates + must specify the bridge's SSL certificate fingerprint as in: + Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ + link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187 + +4.4. Implementation prerequisites + + Tor bridges currently rotate their SSL certificates every 2 + hours. This not only acts as a fingerprint for the bridges, but it + also acts as a blocker for this proposal. + + Tor trac ticket #4390 and proposal YYY were created to resolve this + issue. + +5. Acknowledgements + + Thanks to Robert Ransom for his great help and suggestions on + devising this scheme and writing this proposal! + diff --git a/proposals/192-store-bridge-information.txt b/proposals/192-store-bridge-information.txt new file mode 100644 index 0000000..09ecc5a --- /dev/null +++ b/proposals/192-store-bridge-information.txt @@ -0,0 +1,137 @@ +Filename: 192-store-bridge-information.txt +Title: Automatically retrieve and store information about bridges +Author: Sebastian Hahn +Created: 16-Nov-2011 +Status: Open +Target: 0.2.[45].x + +Overview: +Currently, tor already stores some information about the bridges it is +configured to use locally, but doesn't make great use of the stored +data. This data is the Tor configuration information about the bridge +(IP address, port, and optionally fingerprint) and the bridge descriptor +which gets stored along with the other descriptors a Tor client fetches, +as well as an "EntryGuard" line in the state file. That line includes +the Tor version we used to add the bridge, and a slightly randomized +timestamp (up to a month in the past of the real date). The descriptor +data also includes some more accurate timestamps about when the +descriptor was fetched. + +The information we give out about bridges via bridgedb currently only +includes the IP address and port, because giving out the fingerprint as +well might mean that Tor clients make direct connections to the bridge +authority, since we didn't design Tor's UpdateBridgesFromAuthority +behaviour correctly. + +Motivation: + +The only way to let Tor know about a change affecting the bridge (IP +address or port change) is to either ask the bridge authority directly, +or reconfigure Tor. The former requires making a non-anonymized direct +connection to the bridge authority Tonga and asking it for the current +descriptor of the bridge with a given fingerprint - this is unsafe and +also requires prior knowledge of the fingerprint. The latter requires +user intervention, first to learn that there was an update and second to +actually teach Tor about the change. + +This is way too complicated for most users, and should be unnecessary +while the user has at least one bridge that remains working: Tonga can +give out bridge descriptors when asked for the descriptor for a certain +fingerprint, and Tor clients learn the fingerprint either from their +torrc file or from the first connection they make to a bridge. + +For some users, however, this option is not what they want: They might +use private bridges or have special security concerns, which would make +them want to connect to the IP addresses specified in their +configuration only, and not tell Tonga about the set of bridges they +know about, even through a Tor circuit. Also see +https://blog.torproject.org/blog/different-ways-use-bridge for more +information about the different types of bridge users. + +Design: + +Tor should provide a new configuration option that allows bridge users +to indicate that they wish to contact Tonga anonymously and learn about +updates for the bridges that they know about, but can't currently reach. +Once those updates have been received, the clients would then hold on to +the new information in their state file, and use it across restarts for +connection attempts. + +The option UpdateBridgesFromAuthority should be removed or recycled for +this purpose, as it is currently dangerous to set (it makes direct +connections to the bridge authority, thus leaking that a user is about +to use bridges). Recycling the option is probably the better choice, +because current users of the option get a surprising and never useful +behaviour. On the other hand, users who downgrade their Tors might get +the old behaviour by accident. + +If configured with this option, tor would make an anonymized connection +to Tonga to ask for the descriptors of bridges that it cannot currently +connect to, once every few hours. Making more frequent requests would +likely not help, as bridge information doesn't typically change that +frequently, and may overload Tonga. + +This information needs to be stored in the state file: + +- An exact copy of the Bridge stanza in the torrc file, so that tor can + detect when the bridge is unconfigured/the configuration is changed + +- The IP address, port, and fingerprint we last used when making a + successful connection to the bridge, if this differs from/supplements + the configured data. + +- The IP address, port, and fingerprint we learned from the bridge + authority, if this differs from both the configured data and the data + we used for the last successful connection. + +We don't store more data in the state file to avoid leaking too much if +the state file falls into the hands of an adversary. + +Security implications: + +Storing sensitive data on disk is risky when the computer one uses gets +into the wrong hands, and state file entries can be used to identify +times the user was online. This is already a problem for the Bridge +lines in a user's configuration file, but by storing more information +about bridges some timings can be deduced. + +Another risk is that this allows long-term tracking of users when the +set of bridges a user knows about is known to the attacker, and the set +is unique. This is not very hard to achieve for bridgedb, as users +typically make requests to it non-anomymized and bridgedb can +selectively pick bridges to report. By combining the data about +descriptor fetches on Tonga and this fingerprint, a usage pattern can be +established. Also, bridgedb could give out a made-up fingerprint to a +user that requested bridges, thus easily creating a unique set. + +Users of private bridges should not set this option, as it will leak the +fingerprints of their bridges to Tonga. This is not a huge concern, as +Tonga doesn't know about those descriptors, but private bridge users +will likely want to avoid leaking the existence of their bridge. We +might want to figure out a way to indicate that a bridge is private on +the Bridge line in the configuration, so fetching the descriptor from +Tonga is disabled for those automatically. This warrants more discussion +to find a solution that doesn't require bridge users to understand the +trade-offs of setting a configuration option. + +One idea is to indicate that a bridge is private by a special flag in +its bridge descriptor, so clients can avoid leaking those to the bridge +authority automatically. Also, Bridge lines for private bridges +shouldn't include the fingerprint so that users don't accidentally leak +the fingerprint to the bridge authority before they have talked to the +bridge. + +Specification: + +No change/addition to the current specification is necessary, as the +data that gets stored at clients is not covered by the specification. +This document is supposed to serve as a basis for discussion and to +provide hints for implementors. + +Compatibility: + +Tonga is already set up to send out descriptors requested by clients, so +the bridge authority side doesn't need any changes. The new +configuration options governing the behaviour of Tor would be +incompatible with previous versions, so the torrc needs to be adapted. +The state file changes should not affect older versions.

1 0

[tor/master] Fix warnings.
by nickm＠torproject.org 01 Dec '11

01 Dec '11

commit c06c80b7f7911b0d5c99860ef8c4770cacdbe0a2 Author: Linus Nordberg <linus(a)nordberg.se> Date: Thu Dec 1 09:40:47 2011 +0100 Fix warnings. Remove environ declaration. Use ORPort->value. And it's a string. Make tmp a char *. --- src/or/transports.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-) diff --git a/src/or/transports.c b/src/or/transports.c index eaaf1a3..06bc039 100644 --- a/src/or/transports.c +++ b/src/or/transports.c @@ -946,10 +946,8 @@ static void set_managed_proxy_environment(LPVOID *envp, const managed_proxy_t *mp) { const or_options_t *options = get_options(); - extern char **environ; - - LPVOID tmp=NULL; + char *tmp=NULL; char *state_tmp=NULL; char *state_env=NULL; char *transports_to_launch=NULL; @@ -992,7 +990,8 @@ set_managed_proxy_environment(LPVOID *envp, const managed_proxy_t *mp) smartlist_add(envs, transports_env); if (mp->is_server) { - tor_asprintf(&orport_env, "TOR_PT_ORPORT=127.0.0.1:%d", options->ORPort); + tor_asprintf(&orport_env, "TOR_PT_ORPORT=127.0.0.1:%s", + options->ORPort->value); bindaddr_tmp = get_bindaddr_for_proxy(mp); tor_asprintf(&bindaddr_env, "TOR_PT_SERVER_BINDADDR=%s", bindaddr_tmp);

1 0

[translation/vidalia_help] Update translations for vidalia_help
by translation＠torproject.org 01 Dec '11

01 Dec '11

commit 2ce3aadc88c95d0df82431b53761a796e8ad43bc Author: Translation commit bot <translation(a)torproject.org> Date: Thu Dec 1 12:15:27 2011 +0000 Update translations for vidalia_help --- zh_CN/bridges.po | 9 +++++++-- 1 files changed, 7 insertions(+), 2 deletions(-) diff --git a/zh_CN/bridges.po b/zh_CN/bridges.po index ac11b62..368578d 100644 --- a/zh_CN/bridges.po +++ b/zh_CN/bridges.po @@ -1,5 +1,6 @@ # # Translators: +# Kevin Chen <szescxz(a)126.com>, 2011. # runasand <runa.sandvik(a)gmail.com>, 2011. # snakeyi <snakeyi0624(a)gmail.com>, 2011. # <szescxz(a)126.com>, 2011. @@ -8,7 +9,7 @@ msgstr "" "Project-Id-Version: The Tor Project\n" "Report-Msgid-Bugs-To: https://trac.torproject.org/projects/tor\n" "POT-Creation-Date: 2010-06-26 16:58+0200\n" -"PO-Revision-Date: 2011-11-29 12:32+0000\n" +"PO-Revision-Date: 2011-12-01 12:04+0000\n" "Last-Translator: szescxz <szescxz(a)126.com>\n" "Language-Team: LANGUAGE <LL(a)li.org>\n" "MIME-Version: 1.0\n" @@ -97,12 +98,16 @@ msgid "" "attacker to learn lots of bridge addresses, you must send this request from " "a Gmail account." msgstr "" +"您可以通过浏览 https://bridges.torproject.org " +"来获取公共网桥。您从那个页面获取的信息会在数天内自动更新，所以如果您需要更多网桥地址，请周期性地浏览一次。另一种获取公共网桥地址的方式是发送一封电子邮件到" +" bridges(a)torproject.org ，正文中写上 get bridges " +"。为了让攻击者难以获取多个网桥地址（译者注：以防止这些网桥被黑客攻击），您必须使用 Gmail 发送。" #. type: Content of: <html><body> #: en/bridges.html:63 msgid "" "Configuring more than one bridge address will make your Tor connection more " "stable, in case some of the bridges become unreachable." -msgstr "" +msgstr "如果一些网桥地址无法连接，则配置一个以上的网桥地址会使您的 Tor 连接更加坚固。"

1 0

r25239: {website} fix typo reported on tor-assistants (website/trunk/about/en)
by Roger Dingledine 01 Dec '11

01 Dec '11

Author: arma Date: 2011-12-01 04:51:48 +0000 (Thu, 01 Dec 2011) New Revision: 25239 Modified: website/trunk/about/en/torusers.wml Log: fix typo reported on tor-assistants Modified: website/trunk/about/en/torusers.wml =================================================================== --- website/trunk/about/en/torusers.wml 2011-11-30 18:16:28 UTC (rev 25238) +++ website/trunk/about/en/torusers.wml 2011-12-01 04:51:48 UTC (rev 25239) @@ -297,7 +297,7 @@ <li>To bypass their own security systems for sensitive professional activities: For instance, a company may have a strict policy regarding the material employees can view on the internet. A log review reveals a possible violation. Tor can be used to verify the information without an exception being put into corporate security systems.</li> <li>To connect back to deployed services: A network engineer can use Tor to remotely connect back to services, without the need for an external machine and user account, as part of operational testing.</li> <li>To access internet resources: Acceptable use policy for IT Staff and normal employees is usually different. Tor can allow unfettered access to the internet while leaving standard security policies in place.</li> - <li>To work around ISP network outages: Sometimes when an ISP is having routing or DNS problems, Tor can make internet resources available, when the actual ISP is malfunctioning. This can be invaluable is crisis situations. </li> + <li>To work around ISP network outages: Sometimes when an ISP is having routing or DNS problems, Tor can make internet resources available, when the actual ISP is malfunctioning. This can be invaluable in crisis situations. </li> </ul>

1 0

[tor/master] Only define set_buffer_lengths_to_zero if bufferevents are enabled
by nickm＠torproject.org 30 Nov '11

30 Nov '11

commit b0d3c6a8783a0ad8178d8fe396ad75bb0355f5f7 Author: Murdoch(a)cl.cam.ac.uk <Murdoch(a)cl.cam.ac.uk> Date: Wed Nov 30 20:14:46 2011 +0000 Only define set_buffer_lengths_to_zero if bufferevents are enabled Otherwise, on Windows, gcc will warn about the function being unused --- src/or/main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/or/main.c b/src/or/main.c index d3eb721..3cf9856 100644 --- a/src/or/main.c +++ b/src/or/main.c @@ -196,7 +196,7 @@ free_old_inbuf(connection_t *conn) } #endif -#ifdef MS_WINDOWS +#if defined(MS_WINDOWS) && defined(USE_BUFFEREVENTS) /** Remove the kernel-space send and receive buffers for s. For use * with IOCP only. */ static int

1 0

[tor/master] Add an initializer to appease older gcc
by nickm＠torproject.org 30 Nov '11

30 Nov '11

commit d106caaadc66f519d66e7b20068050113d99a1ac Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Nov 30 18:08:07 2011 -0500 Add an initializer to appease older gcc --- src/test/test_util.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/test/test_util.c b/src/test/test_util.c index c762a8d..f9b57d6 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1659,7 +1659,7 @@ test_util_split_lines(void *ptr) }; int i, j; - char *orig_line; + char *orig_line=NULL; smartlist_t *sl=NULL; (void)ptr;

1 0