October 2011 - tor-commits - lists.torproject.org

[metrics-web/master] Don't warn when trying to parse a dir key certificate.
by karsten＠torproject.org 31 Oct '11

31 Oct '11

commit f481df454ea82b24f6e627d030c030086e423b9a Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Oct 31 12:58:55 2011 +0100 Don't warn when trying to parse a dir key certificate. --- .../ernie/cron/RelayDescriptorParser.java | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/org/torproject/ernie/cron/RelayDescriptorParser.java b/src/org/torproject/ernie/cron/RelayDescriptorParser.java index f2ae02d..64b809e 100644 --- a/src/org/torproject/ernie/cron/RelayDescriptorParser.java +++ b/src/org/torproject/ernie/cron/RelayDescriptorParser.java @@ -76,8 +76,12 @@ public class RelayDescriptorParser { startToken = "router "; } else if (line.startsWith("extra-info ")) { startToken = "extra-info "; + } else if (line.equals("dir-key-certificate-version 3")) { + this.logger.fine("Not parsing dir key certificate."); + return; } else { - this.logger.warning("Unknown descriptor type. Ignoring."); + this.logger.warning("Unknown descriptor type. First line is '" + + line + "'. Ignoring."); return; } String splitToken = "\n" + startToken;

1 0

[metrics-web/master] Add bridge stability report to papers.html.
by karsten＠torproject.org 31 Oct '11

31 Oct '11

commit 7cf6ebce8ef09cb5bd7963ab46be8d80f3a0abb0 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Oct 31 10:07:12 2011 +0100 Add bridge stability report to papers.html. --- web/WEB-INF/papers.jsp | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/web/WEB-INF/papers.jsp b/web/WEB-INF/papers.jsp index f6aa7bd..ba8eb9f 100644 --- a/web/WEB-INF/papers.jsp +++ b/web/WEB-INF/papers.jsp @@ -45,6 +45,10 @@ been included in the <a href="#papers">papers</a> above or in the daily updated <a href="graphs.html">graphs</a>. <ul> + <li>An Analysis of Tor Bridge Stability—Making BridgeDB + give out at least one stable bridge per user (<a + href="papers/bridge-stability-2011-10-31.pdf">PDF</a>, 419K from + October 31, 2011).</li> <li>Case study: Learning whether a Tor bridge is blocked by looking at its aggregate usage statistics, Part one (<a href="papers/blocking-2011-09-15.pdf">PDF</a>, 767K from

1 0

[metrics-tasks/master] Update bridge stability report (#4255).
by karsten＠torproject.org 31 Oct '11

31 Oct '11

commit 2a8d08ee4a541ca696c800a9717cfafc746e45e8 Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Oct 31 09:57:58 2011 +0100 Update bridge stability report (#4255). --- task-4255/report.tex | 11 ++++++----- task-4255/stability.R | 2 +- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/task-4255/report.tex b/task-4255/report.tex index 0dfd437..d756449 100644 --- a/task-4255/report.tex +++ b/task-4255/report.tex @@ -11,7 +11,7 @@ user ---}} \maketitle -\section{Introducing the instable bridges problem} +\section{Introducing the unstable bridges problem} As of October 2011, the Tor network consists of a few hundred thousand clients, 2\,400 public relays, and about 600 non-public bridge relays. @@ -107,7 +107,7 @@ active bridges have appeared more recently than it, \ldots'') and a static part that is independent of other bridges (e.g., ``\ldots or if it has been around for a Weighted Time of 8 days.''). The dynamic parts ensure that a certain fraction of bridges is considered -stable even in a rather instable network. +stable even in a rather unstable network. The static parts ensures that rather stable bridges are not excluded even when most other bridges in the network are stable. @@ -200,9 +200,10 @@ operating system upgrade of the BridgeDB host. During this time, the bridge authority continued to work, but BridgeDB was unable to learn about new bridge descriptors from it. -During the time from January 31 to February 16, 2011, the \verb+tor+ -process running the bridge authority silently died, but the script to copy -descriptors to BridgeDB kept running. +During the time from January 27 to February 16, 2011, the \verb+tor+ +process running the bridge authority silently died twice after a Tor +version upgrade, but the script to copy descriptors to BridgeDB kept +running. In this case, BridgeDB received fresh tarballs containing stale descriptors with a constant number of 687 relays, visualized in light gray. diff --git a/task-4255/stability.R b/task-4255/stability.R index b2cd487..c46266e 100644 --- a/task-4255/stability.R +++ b/task-4255/stability.R @@ -44,7 +44,7 @@ opts(axis.title.x = theme_text(size = 12 * 0.8, face = "bold", axis.title.y = theme_text(size = 12 * 0.8, face = "bold", vjust = 0.5, hjust = 1), legend.position = "none") -d <- stability[stability$time > '2011-01-29' & +d <- stability[stability$time > '2011-01-24' & stability$time < '2011-02-19', ] e <- read.csv("stale-bridge-tarballs.csv", stringsAsFactors = FALSE, col.names = c("time"))

1 0

[torspec/master] fix typos and ambiguities from proposal 176 merge
by arma＠torproject.org 31 Oct '11

31 Oct '11

commit 075e215564c76bbac983844d5c41d4d54a880595 Author: Roger Dingledine <arma(a)torproject.org> Date: Mon Oct 31 04:12:00 2011 -0400 fix typos and ambiguities from proposal 176 merge --- tor-spec.txt | 51 +++++++++++++++++++++++++++------------------------ 1 files changed, 27 insertions(+), 24 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index 7426659..52a9217 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -194,7 +194,8 @@ see tor-design.pdf. [The above "should not" is because some of the ciphers that clients list may be fake.] - In "in-protocol" (a.k.a. "the v3 handshake"), the initiator sends no certificates, and the + In "in-protocol" (a.k.a. "the v3 handshake"), the initiator sends no + certificates, and the responder sends a single connection certificate. The choice of ciphersuites must be as in a "renegotiation" handshake. There are additionally a set of constraints on the connection certificate, @@ -212,7 +213,7 @@ see tor-design.pdf. protocol version. Assuming that the version they negotiate is 3 (the only one specified for use with this handshake right now), the responder sends a CERTS cell, an AUTH_CHALLENGE cell, and a NETINFO - cell to the initiator, which may send either CERTS,AUTHENTICATE, + cell to the initiator, which may send either CERTS, AUTHENTICATE, NETINFO if it wants to authenticate, or just NETINFO if it does not. For backward compatibility between later handshakes and "certificates @@ -237,7 +238,7 @@ see tor-design.pdf. All new relay implementations of the Tor protocol MUST support backwards-compatible renegotiation; clients SHOULD do this too. If - this is not possible, new client implementations MUST support all + this is not possible, new client implementations MUST support both "renegotiation" and "in-protocol" and use the router's published link protocols list (see dir-spec.txt on the "protocols" entry) to decide which to use. @@ -319,7 +320,7 @@ see tor-design.pdf. Payload [Length bytes] On a version 2 connection, variable-length cells are indicated by a - command byte either equal to 7 ("VERSIONS"). On a version 3 or + command byte equal to 7 ("VERSIONS"). On a version 3 or higher connection, variable-length cells are indicated by a command byte equal to 7 ("VERSIONS"), or greater than or equal to 128. @@ -382,9 +383,9 @@ see tor-design.pdf. When the renegotiation handshake is used, both parties immediately send a VERSIONS cell (4.1 below), and after negotiating a link - protocol version (which will be 2), send a NETINFO cell (4.5 below) to - confirm their addresses and timestamps. No other intervening cell - types are allowed. + protocol version (which will be 2), each send a NETINFO cell (4.5 + below) to confirm their addresses and timestamps. No other intervening + cell types are allowed. When the in-protocol handshake is used, the initiator sends a VERSIONS cell to indicate that it will not be renegotiating. The @@ -392,11 +393,13 @@ see tor-design.pdf. initiator the certificates it needs to learn the responder's identity, an AUTH_CHALLENGE cell (4.3) that the initiator must include as part of its answer if it chooses to authenticate, and a NETINFO - cell (4.5). As soon as it gets the CERTS cell, the initiator knows - whether the responder is correctly authenticated. At this point the - initiator may send a NETINFO cell if it does not wish to - authenticate, or a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO - cell if it does. When this handshake is in use, the first cell must + cell (4.5). The initiator can use the CERTS cell to confirm whether + the responder is correctly authenticated. If the initiator does not wish + to authenticate, it can send a NETINFO cell once it has received the + VERSIONS cell from the responder. If the initiator does wish to + authenticate, it waits until it gets the AUTH_CHALLENGE cell, and then + sends a CERTS cell, an AUTHENTICATE cell (4.4), and a NETINFO + cell. When this handshake is in use, the first cell must still be VERSIONS, and no other cell type is allowed to intervene besides those specified, except for PADDING and VPADDING cells. @@ -414,8 +417,8 @@ see tor-design.pdf. sent only one certificate at first and where the initiator did not send any certificates in the first negotiation), both parties MUST send a VERSIONS cell. In "renegotiation", they send a VERSIONS cell - right after he renegotiation is finished, before any other cells are - sent. In "in-protocol", the initiator send a VERSIONS cell + right after the renegotiation is finished, before any other cells are + sent. In "in-protocol", the initiator sends a VERSIONS cell immediately after the initial TLS handshake, and the responder replies immediately with a VERSIONS cell. Parties MUST NOT send any other cells on a connection until they have received a VERSIONS cell. @@ -435,7 +438,7 @@ see tor-design.pdf. 4.2. CERTS cells - The CERT cell describes the keys that a Tor instance is claiming + The CERTS cell describes the keys that a Tor instance is claiming to have. It is a variable-length cell. Its payload format is: N: Number of certs in cell [1 octet] @@ -444,7 +447,7 @@ see tor-design.pdf. CLEN [2 octets] Certificate [CLEN octets] - Any extra octets at the end of a CERT cell MUST be ignored. + Any extra octets at the end of a CERTS cell MUST be ignored. CertType values are: 1: Link key certificate certified by RSA1024 identity @@ -470,7 +473,7 @@ see tor-design.pdf. * The ID certificate is correctly self-signed. Checking these conditions is sufficient to authenticate that the initiator is talking to the Tor node with the expected identity, - as certified in the ID certificate + as certified in the ID certificate. To authenticate the initiator, the responder MUST check the following: @@ -486,8 +489,8 @@ see tor-design.pdf. ID certificate. * The ID certificate is correctly self-signed. Checking these conditions is NOT sufficient to authenticate that the - initiator has the ID it claims; to do so, the cells in 4.3 below must - be exchanged. + initiator has the ID it claims; to do so, the cells in 4.3 and 4.4 + below must be exchanged. 4.3. AUTH_CHALLENGE cells @@ -510,8 +513,8 @@ see tor-design.pdf. 4.4. AUTHENTICATE cells If an initiator wants to authenticate, it responds to the - AUTH_CHALLENGE cell with a CERT cell and an AUTHENTICATE cell. - The CERT cell is as a server would send, except that instead of + AUTH_CHALLENGE cell with a CERTS cell and an AUTHENTICATE cell. + The CERTS cell is as a server would send, except that instead of sending a CertType 1 cert for an arbitrary link certificate, the client sends a CertType 3 cert for an RSA AUTHENTICATE key. (This difference is because we allow any link key type on a TLS @@ -534,11 +537,11 @@ see tor-design.pdf. SID: A SHA256 hash of the responder's RSA1024 identity key [32 octets] SLOG: A SHA256 hash of all bytes sent from the responder to the initiator as part of the negotiation up to and including the - AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERT cell, + AUTH_CHALLENGE cell; that is, the VERSIONS cell, the CERTS cell, the AUTH_CHALLENGE cell, and any padding cells. [32 octets] CLOG: A SHA256 hash of all bytes sent from the initiator to the responder as part of the negotiation so far; that is, the - VERSIONS cell and the CERT cell and any padding cells. [32 + VERSIONS cell and the CERTS cell and any padding cells. [32 octets] SCERT: A SHA256 hash of the responder's TLS link certificate. [32 octets] @@ -558,7 +561,7 @@ see tor-design.pdf. [variable length] To check the AUTHENTICATE cell, a responder checks that all fields - containing from TYPE through TLSSECRETS contain their unique + from TYPE through TLSSECRETS contain their unique correct values as described above, and then verifies the signature. signature. The server MUST ignore any extra bytes in the signed data after the SHA256 hash.

1 0

[metrics-web/master] Fix consensus params check.
by karsten＠torproject.org 31 Oct '11

31 Oct '11

commit 5a028c663900accdf6f9a88572fee8e87086c7ff Author: Karsten Loesing <karsten.loesing(a)gmx.net> Date: Mon Oct 31 08:53:29 2011 +0100 Fix consensus params check. --- src/org/torproject/chc/NagiosReport.java | 2 +- src/org/torproject/chc/StdOutReport.java | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/org/torproject/chc/NagiosReport.java b/src/org/torproject/chc/NagiosReport.java index a9f27af..e550625 100644 --- a/src/org/torproject/chc/NagiosReport.java +++ b/src/org/torproject/chc/NagiosReport.java @@ -171,7 +171,7 @@ public class NagiosReport implements Report { Map<String, String> voteConsensusParams = vote.getConsensusParams(); boolean conflictOrInvalid = false; - if (voteConsensusParams == null) { + if (voteConsensusParams != null) { for (Map.Entry<String, String> e : voteConsensusParams.entrySet()) { if (!downloadedConsensus.getConsensusParams().containsKey( diff --git a/src/org/torproject/chc/StdOutReport.java b/src/org/torproject/chc/StdOutReport.java index f683ae6..805343f 100644 --- a/src/org/torproject/chc/StdOutReport.java +++ b/src/org/torproject/chc/StdOutReport.java @@ -211,7 +211,7 @@ public class StdOutReport implements Report { Map<String, String> voteConsensusParams = vote.getConsensusParams(); boolean conflictOrInvalid = false; - if (voteConsensusParams == null) { + if (voteConsensusParams != null) { for (Map.Entry<String, String> e : voteConsensusParams.entrySet()) { if (!downloadedConsensus.getConsensusParams().containsKey(

1 0

[flashproxy/master] Add local and remote proxy switching experiments.
by dcf＠torproject.org 31 Oct '11

31 Oct '11

commit 8a18185d9b2b353fd1442c1603518df2c3586f89 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Oct 30 22:57:10 2011 -0700 Add local and remote proxy switching experiments. These are mainly copied from the paper branch, but they use the nicer new common.sh test infrastructure and are easier to run. --- experiments/common.sh | 1 + experiments/switching/local-http-alternating.sh | 61 +++++++++++++++++++++++ experiments/switching/local-http-constant.sh | 56 +++++++++++++++++++++ experiments/switching/proxy-loop.sh | 38 ++++++++++++++ experiments/switching/remote-tor-alternating.sh | 57 +++++++++++++++++++++ experiments/switching/remote-tor-constant.sh | 52 +++++++++++++++++++ 6 files changed, 265 insertions(+), 0 deletions(-) diff --git a/experiments/common.sh b/experiments/common.sh index 6f2deea..7e5d0a4 100644 --- a/experiments/common.sh +++ b/experiments/common.sh @@ -4,6 +4,7 @@ FIREFOX=firefox SOCAT=socat THTTPD=thttpd +TOR=tor visible_sleep() { N="$1" diff --git a/experiments/switching/local-http-alternating.sh b/experiments/switching/local-http-alternating.sh new file mode 100755 index 0000000..d83651a --- /dev/null +++ b/experiments/switching/local-http-alternating.sh @@ -0,0 +1,61 @@ +#!/bin/sh + +# Usage: ./local-http-alternating.sh +# +# Tests a download over alternating flash proxies. + +. ../common.sh + +FLASHPROXY_DIR=../../../flashproxy + +PROFILE_1=flashexp1 +PROFILE_2=flashexp2 +PROXY_URL="http://localhost:8000/swfcat.swf?facilitator=127.0.0.1:9002" +DATA_FILE_NAME="$FLASHPROXY_DIR/dump" + +# Declare an array. +declare -a PIDS_TO_KILL +stop() { + browser_clear "$PROFILE_1" + browser_clear "$PROFILE_2" + if [ -n "${PIDS_TO_KILL[*]}" ]; then + echo "Kill pids ${PIDS_TO_KILL[@]}." + kill "${PIDS_TO_KILL[@]}" + fi + echo "Delete data file." + rm -f "$DATA_FILE_NAME" + exit +} +trap stop EXIT + +echo "Create data file." +dd if=/dev/null of="$DATA_FILE_NAME" bs=1M seek=1024 2>/dev/null || exit + +echo "Start web server." +"$THTTPD" -D -d "$FLASHPROXY_DIR" -p 8000 & +PIDS_TO_KILL+=($!) + +echo "Start facilitator." +"$FLASHPROXY_DIR"/facilitator.py -d --relay 127.0.0.1:8000 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 2 + +echo "Start connector." +"$FLASHPROXY_DIR"/connector.py --facilitator 127.0.0.1 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +echo "Start browsers." +ensure_browser_started "$PROFILE_1" +ensure_browser_started "$PROFILE_2" + +./proxy-loop.sh "$PROXY_URL" "$PROFILE_1" "$PROFILE_2" >/dev/null 2>&1 & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +echo "Start socat." +"$SOCAT" TCP-LISTEN:2000,reuseaddr,fork SOCKS4A:localhost:dummy:0,socksport=9001 & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +time wget http://localhost:2000/dump -t 0 -O /dev/null diff --git a/experiments/switching/local-http-constant.sh b/experiments/switching/local-http-constant.sh new file mode 100755 index 0000000..b551140 --- /dev/null +++ b/experiments/switching/local-http-constant.sh @@ -0,0 +1,56 @@ +#!/bin/sh + +# Usage: ./local-http-constant.sh +# +# Tests a download over an uninterrupted flash proxy. + +. ../common.sh + +FLASHPROXY_DIR=../../../flashproxy + +PROFILE_1=flashexp1 +PROFILE_2=flashexp2 +PROXY_URL="http://localhost:8000/swfcat.swf?facilitator=127.0.0.1:9002" +DATA_FILE_NAME="$FLASHPROXY_DIR/dump" + +# Declare an array. +declare -a PIDS_TO_KILL +stop() { + browser_clear "$PROFILE_1" + browser_clear "$PROFILE_2" + if [ -n "${PIDS_TO_KILL[*]}" ]; then + echo "Kill pids ${PIDS_TO_KILL[@]}." + kill "${PIDS_TO_KILL[@]}" + fi + echo "Delete data file." + rm -f "$DATA_FILE_NAME" + exit +} +trap stop EXIT + +echo "Create data file." +dd if=/dev/null of="$DATA_FILE_NAME" bs=1M seek=1024 2>/dev/null || exit + +echo "Start web server." +"$THTTPD" -D -d "$FLASHPROXY_DIR" -p 8000 & +PIDS_TO_KILL+=($!) + +echo "Start facilitator." +"$FLASHPROXY_DIR"/facilitator.py -d --relay 127.0.0.1:8000 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 2 + +echo "Start connector." +"$FLASHPROXY_DIR"/connector.py --facilitator 127.0.0.1 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +echo "Start browser." +browser_goto "$PROFILE_1" "$PROXY_URL" + +echo "Start socat." +"$SOCAT" TCP-LISTEN:2000,reuseaddr,fork SOCKS4A:localhost:dummy:0,socksport=9001 & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +time wget http://localhost:2000/dump -t 0 -O /dev/null diff --git a/experiments/switching/proxy-loop.sh b/experiments/switching/proxy-loop.sh new file mode 100755 index 0000000..3c3b78a --- /dev/null +++ b/experiments/switching/proxy-loop.sh @@ -0,0 +1,38 @@ +#!/bin/bash + +# Runs overlapping flash proxy instances in a loop. +# Usage: /proxy-loop.sh <URL> PROFILE1 PROFILE2 + +# The profiles need to have the open_newwindow configuration option set +# properly. See ../README. +# browser.link.open_newwindow=1 (default is 3) + +. ../common.sh + +URL=$1 +PROFILE_1=$2 +PROFILE_2=$3 + +# OVERLAP must be at most half of PERIOD. +PERIOD=10 +OVERLAP=2 + +ensure_browser_started "$PROFILE_1" +browser_clear "$PROFILE_1" +ensure_browser_started "$PROFILE_2" +browser_clear "$PROFILE_2" + +while true; do + echo "1 on" + firefox -P "$PROFILE_1" -remote "openurl($URL)" + sleep $OVERLAP + echo "2 off" + firefox -P "$PROFILE_2" -remote "openurl(about:blank)" + sleep $(($PERIOD - (2 * $OVERLAP))) + echo "2 on" + firefox -P "$PROFILE_2" -remote "openurl($URL)" + sleep $OVERLAP + echo "1 off" + firefox -P "$PROFILE_1" -remote "openurl(about:blank)" + sleep $(($PERIOD - (2 * $OVERLAP))) +done diff --git a/experiments/switching/remote-tor-alternating.sh b/experiments/switching/remote-tor-alternating.sh new file mode 100755 index 0000000..e7c14fd --- /dev/null +++ b/experiments/switching/remote-tor-alternating.sh @@ -0,0 +1,57 @@ +#!/bin/sh + +# Usage: ./remote-tor-alternating.sh +# +# Tests a Tor download over alternating flash proxies. + +. ../common.sh + +FLASHPROXY_DIR=../../../flashproxy + +PROFILE_1=flashexp1 +PROFILE_2=flashexp2 +PROXY_URL="http://localhost:8000/swfcat.swf?facilitator=127.0.0.1:9002" +DATA_FILE_NAME="$FLASHPROXY_DIR/dump" + +# Declare an array. +declare -a PIDS_TO_KILL +stop() { + browser_clear "$PROFILE_1" + browser_clear "$PROFILE_2" + if [ -n "${PIDS_TO_KILL[*]}" ]; then + echo "Kill pids ${PIDS_TO_KILL[@]}." + kill "${PIDS_TO_KILL[@]}" + fi + exit +} +trap stop EXIT + +echo "Start web server." +"$THTTPD" -D -d "$FLASHPROXY_DIR" -p 8000 & +PIDS_TO_KILL+=($!) + +echo "Start facilitator." +"$FLASHPROXY_DIR"/facilitator.py -d --relay tor1.bamsoftware.com >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 2 + +echo "Start connector." +"$FLASHPROXY_DIR"/connector.py --facilitator 127.0.0.1 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +echo "Start Tor." +"$TOR" -f "$FLASHPROXY_DIR"/torrc & +PIDS_TO_KILL+=($!) + +echo "Start browsers." +ensure_browser_started "$PROFILE_1" +ensure_browser_started "$PROFILE_2" + +./proxy-loop.sh "$PROXY_URL" "$PROFILE_1" "$PROFILE_2" >/dev/null 2>&1 & +PIDS_TO_KILL+=($!) + +# Let Tor bootstrap. +visible_sleep 15 + +time torify wget http://torperf.torproject.org/.5mbfile -t 0 -O /dev/null diff --git a/experiments/switching/remote-tor-constant.sh b/experiments/switching/remote-tor-constant.sh new file mode 100755 index 0000000..0f84a06 --- /dev/null +++ b/experiments/switching/remote-tor-constant.sh @@ -0,0 +1,52 @@ +#!/bin/sh + +# Usage: ./remote-tor-constant.sh +# +# Tests a Tor download over an uninterrupted flash proxy. + +. ../common.sh + +FLASHPROXY_DIR=../../../flashproxy + +PROFILE_1=flashexp1 +PROFILE_2=flashexp2 +PROXY_URL="http://localhost:8000/swfcat.swf?facilitator=127.0.0.1:9002" +DATA_FILE_NAME="$FLASHPROXY_DIR/dump" + +# Declare an array. +declare -a PIDS_TO_KILL +stop() { + browser_clear "$PROFILE_1" + if [ -n "${PIDS_TO_KILL[*]}" ]; then + echo "Kill pids ${PIDS_TO_KILL[@]}." + kill "${PIDS_TO_KILL[@]}" + fi + exit +} +trap stop EXIT + +echo "Start web server." +"$THTTPD" -D -d "$FLASHPROXY_DIR" -p 8000 & +PIDS_TO_KILL+=($!) + +echo "Start facilitator." +"$FLASHPROXY_DIR"/facilitator.py -d --relay tor1.bamsoftware.com >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 2 + +echo "Start connector." +"$FLASHPROXY_DIR"/connector.py --facilitator 127.0.0.1 >/dev/null & +PIDS_TO_KILL+=($!) +visible_sleep 1 + +echo "Start Tor." +"$TOR" -f "$FLASHPROXY_DIR"/torrc & +PIDS_TO_KILL+=($!) + +echo "Start browsers." +browser_goto "$PROFILE_1" "$PROXY_URL" + +# Let Tor bootstrap. +visible_sleep 15 + +time torify wget http://torperf.torproject.org/.5mbfile -t 0 -O /dev/null

1 0

[translation/orbot] Update translations for orbot
by translation＠torproject.org 31 Oct '11

31 Oct '11

commit eec900bc9c06d7d83a218b6ace633c11d1683ced Author: Translation commit bot <translation(a)torproject.org> Date: Mon Oct 31 04:15:37 2011 +0000 Update translations for orbot --- values/strings.xml | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/values/strings.xml b/values/strings.xml index 41b14fc..dad3146 100644 --- a/values/strings.xml +++ b/values/strings.xml @@ -103,7 +103,7 @@ <string name="wizard_transproxy_hint">(Check this box if you have no idea what we are talking about)</string> <string name="wizard_transproxy_none">None</string> <string name="pref_transparent_tethering_title">Tor Tethering</string> - <string name="pref_transparent_tethering_summary">Enable Tor Transparent Proxying for Wifi and USB Tethered Devices</string> + <string name="pref_transparent_tethering_summary">Enable Tor Transparent Proxying for Wifi and USB Tethered Devices (requires restart)</string> <string name="button_grant_superuser">Request Superuser Access</string> <string name="pref_select_apps">Select Apps</string> <string name="pref_select_apps_summary">Choose Apps to Route Through Tor</string>

1 0

[flashproxy/master] Remove the 01 experiment.
by dcf＠torproject.org 31 Oct '11

31 Oct '11

commit 87ba752d7c6bd6778b556a177ca661ac551a8697 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Oct 30 21:00:37 2011 -0700 Remove the 01 experiment. This was a repeat of the 00 (throughput experiment) with RTMFP. But RTMFP is broken for high-bandwidth local connections: It will push bytes faster than they can be sent, buffer them, and eventually crash after using up all memory. --- experiments/01 | 79 -------------------------------------------------------- 1 files changed, 0 insertions(+), 79 deletions(-) diff --git a/experiments/01 b/experiments/01 deleted file mode 100755 index 8718e0d..0000000 --- a/experiments/01 +++ /dev/null @@ -1,79 +0,0 @@ -#!/bin/bash - -# Get arguments -if [ $1 ]; then - NUM_CLIENTS=$1 -else - NUM_CLIENTS=1 -fi - -# Go to flashproxy repo root dir -cd .. - -# Create 1GB dump file -echo "creating dump file..." -rm dump -dd if=/dev/null of=dump bs=1G seek=1 - -# Start http server -echo "starting http server..." -thttpd -p 1080 - -# Start crossdomain policy server -echo "starting cross domain policy server..." -sudo ./crossdomaind.py & - -# Start the facilitator -echo "starting facilitator..." -./facilitator.py 4701 -r 127.0.0.1:1080 - -# Start socat adapters -echo "starting socat adapters..." -i=1 -until [ $i -gt $NUM_CLIENTS ]; do - let local_port=2000+i - let remote_port=9000+i - socat TCP-LISTEN:${remote_port},reuseaddr,fork TCP-LISTEN:${local_port},reuseaddr & - let i=i+1 -done - -# Start the flash proxy, server side -echo "starting flash proxy server side..." -firefox & -sleep 2 -firefox --remote "openURL(http://localhost:1080/swfcat.swf?facilitator=127.0.0.1:4701)" - -# Start the flash proxy, client side -echo "starting flash proxy client side..." -i=1 -until [ $i -gt $NUM_CLIENTS ]; do - let local_port=9000+i - firefox --remote "openURL(http://localhost:1080/swfcat.swf?local=127.0.0.1:${local_port}&client=1&facilitator=127.0.0.1:4701)" - let i=i+1 - sleep 2 -done - -let query_fac_time=NUM_CLIENTS+2 -sleep ${query_fac_time} - -# wget the dump file -echo "getting the dump file..." -i=2 -until [ $i -gt $NUM_CLIENTS ]; do - let local_port=2000+i - xterm -e "/bin/bash -c 'wget -t1 http://localhost:${local_port}/dump -O - > /dev/null; exec /bin/bash -i'" & - let i=i+1 - sleep 2 -done - -# Use this one for delaying the termination of experiment below -wget -t1 http://localhost:2001/dump -O - > /dev/null - -echo "Press enter to continue." -read - -# Slaughter the processes -sudo killall thttpd -ps -ef | sed -n '/crossdomaind.py/{/grep/!p;}' | awk '{print$2}' | sudo xargs -i kill {} -ps -ef | sed -n '/facilitator.py/{/grep/!p;}' | awk '{print$2}' | sudo xargs -i kill {} -sudo killall socat

1 0

r25192: {website} bump bundles to 0.2.3.7-alpha (except for ppc, since the bui (website/trunk/include)
by Erinn Clark 31 Oct '11

31 Oct '11

Author: erinn Date: 2011-10-31 02:39:39 +0000 (Mon, 31 Oct 2011) New Revision: 25192 Modified: website/trunk/include/versions.wmi Log: bump bundles to 0.2.3.7-alpha (except for ppc, since the build machine is snowed in) Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2011-10-30 23:00:18 UTC (rev 25191) +++ website/trunk/include/versions.wmi 2011-10-31 02:39:39 UTC (rev 25192) @@ -2,27 +2,27 @@ <define-tag version-alpha whitespace=delete>0.2.3.7-alpha</define-tag> <define-tag version-win32-stable whitespace=delete>0.2.2.34</define-tag> -<define-tag version-win32-alpha whitespace=delete>0.2.3.6-alpha</define-tag> +<define-tag version-win32-alpha whitespace=delete>0.2.3.7-alpha</define-tag> <define-tag version-win32-bundle-stable whitespace=delete>0.2.2.34</define-tag> -<define-tag version-win32-bundle-alpha whitespace=delete>0.2.3.6-alpha</define-tag> +<define-tag version-win32-bundle-alpha whitespace=delete>0.2.3.7-alpha</define-tag> <define-tag version-win32-bridge-bundle-stable whitespace=delete>0.2.2.34-<version-vidalia-stable></define-tag> <define-tag version-win32-relay-bundle-stable whitespace=delete>0.2.2.34-<version-vidalia-stable></define-tag> <define-tag version-win32-exit-bundle-stable whitespace=delete>0.2.2.34-<version-vidalia-stable>-2</define-tag> -<define-tag version-win32-bridge-bundle-alpha whitespace=delete>0.2.3.6-alpha-<version-vidalia-stable></define-tag> -<define-tag version-win32-relay-bundle-alpha whitespace=delete>0.2.3.6-alpha-<version-vidalia-stable></define-tag> -<define-tag version-win32-exit-bundle-alpha whitespace=delete>0.2.3.6-alpha-<version-vidalia-stable></define-tag> +<define-tag version-win32-bridge-bundle-alpha whitespace=delete>0.2.3.7-alpha-<version-vidalia-stable></define-tag> +<define-tag version-win32-relay-bundle-alpha whitespace=delete>0.2.3.7-alpha-<version-vidalia-stable></define-tag> +<define-tag version-win32-exit-bundle-alpha whitespace=delete>0.2.3.7-alpha-<version-vidalia-stable></define-tag> <define-tag version-osx-x86-bundle-stable whitespace=delete>0.2.2.34</define-tag> -<define-tag version-osx-x86-bundle-alpha whitespace=delete>0.2.3.6-alpha</define-tag> +<define-tag version-osx-x86-bundle-alpha whitespace=delete>0.2.3.7-alpha</define-tag> <define-tag version-osx-ppc-bundle-stable whitespace=delete>0.2.2.34</define-tag> <define-tag version-osx-ppc-bundle-alpha whitespace=delete>0.2.3.6-alpha</define-tag> <define-tag version-osx-x86-stable whitespace=delete>0.2.2.34</define-tag> -<define-tag version-osx-x86-alpha whitespace=delete>0.2.3.6-alpha</define-tag> +<define-tag version-osx-x86-alpha whitespace=delete>0.2.3.7-alpha</define-tag> <define-tag version-osx-ppc-stable whitespace=delete>0.2.2.34</define-tag> <define-tag version-osx-ppc-alpha whitespace=delete>0.2.3.6-alpha</define-tag>

1 0

[flashproxy/master] Reduce the crossdomain timeout from 2.0 s to 0.5 s.
by dcf＠torproject.org 31 Oct '11

31 Oct '11

commit c04baba6de5ca0301ef3f3d9ddb868ad878cbb97 Author: David Fifield <david(a)bamsoftware.com> Date: Sun Oct 30 18:26:47 2011 -0700 Reduce the crossdomain timeout from 2.0 s to 0.5 s. The public connector has logged 160 crossdomain connections since 2011-09-05. The log entries only have a resolution of a second. That said, in only nine of those entries did the time advance by a second before the crossdomain request was received. This gives an estimate of the mean time before receiving a crossdomain request of 0.05625 s. --- connector.py | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/connector.py b/connector.py index 624b776..3b08272 100755 --- a/connector.py +++ b/connector.py @@ -181,8 +181,11 @@ def format_peername(s): return "<unconnected>" # How long to wait for a crossdomain policy request before deciding that this is -# a normal socket. -CROSSDOMAIN_TIMEOUT = 2.0 +# a normal socket. In 160 crossdomain connections to the public facilitator, the +# mean time before receiving a crossdomain request is only 0.05625 s. But that +# was measured from log entries with a one-second resolution, so give a healthy +# margin above that. +CROSSDOMAIN_TIMEOUT = 0.5 # Local socket, accepting SOCKS requests from localhost local_s = listen_socket(options.local_addr)

1 0