tor-commits September 2011

tor-commits@lists.torproject.org

19 participants
865 discussions

r25092: {} tex, pdf and images from my presentation yesterday (in projects/presentations: . images)
by Runa Sandvik 21 Sep '11

21 Sep '11

Author: runa Date: 2011-09-21 08:03:48 +0000 (Wed, 21 Sep 2011) New Revision: 25092 Added: projects/presentations/2011-anonymity-usability-humans-mdx.pdf projects/presentations/2011-anonymity-usability-humans-mdx.tex projects/presentations/images/bridge-users-2010-09-11-300-2011-09-11-ir.png projects/presentations/images/direct-users-off-2010-09-11-off-300-2011-09-11-ir.png projects/presentations/images/direct-users-off-2010-09-19-off-300-2011-09-19-all.png Log: tex, pdf and images from my presentation yesterday Added: projects/presentations/2011-anonymity-usability-humans-mdx.pdf =================================================================== (Binary files differ) Property changes on: projects/presentations/2011-anonymity-usability-humans-mdx.pdf ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: projects/presentations/2011-anonymity-usability-humans-mdx.tex =================================================================== --- projects/presentations/2011-anonymity-usability-humans-mdx.tex (rev 0) +++ projects/presentations/2011-anonymity-usability-humans-mdx.tex 2011-09-21 08:03:48 UTC (rev 25092) @@ -0,0 +1,265 @@ +\documentclass{beamer} +\mode<presentation> +\usetheme{Boadilla} +\title{Anonymity, Usability, and Humans. Pick Two.} +\author{Runa A. Sandvik \\ runa(a)torproject.org} +\date{20 September 2011} +\begin{document} + +\begin{frame} +\maketitle +\begin{center} +\includegraphics[height=3cm]{../images/2009-tor-logo} +\end{center} +\end{frame} + +% Introduce myself, just to be nice +\begin{frame} +\frametitle{About Runa} +\begin{itemize} +\item Studied at the Norwegian University of Science and Technology +\item Worked for the Tor Project during Google Summer of Code in 2009 +\item Developer, security researcher, translation coordinator +\end{itemize} +\end{frame} + +% And here's what we'll talk about +\begin{frame} +\frametitle{What are we talking about?} +\begin{itemize} +\item Crash course on anonymous communications +\item Quick overview of Tor +\item Usability, Security, and Humans +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{The Tor Project, Inc.} +501(c)(3) non-profit organization dedicated to the research and development of technologies for online anonymity and privacy +\begin{center} +\includegraphics[height=5cm]{../images/2009-oval_sticker_new} +\end{center} +\end{frame} + +% Crash course on anonymous communications +\begin{frame} +\frametitle{What is anonymity?} +\includegraphics[width=10cm]{../images/2llg3ts} +\end{frame} + +\begin{frame} +\frametitle{Anonymity isn't cryptography} +\begin{itemize} +\item Cryptography protects the contents in transit +\item You still know who is talking to whom, how often, and how much data is sent. +\end{itemize} +\begin{center} +\includegraphics[width=5cm]{../images/encryption-cc-by-sa} +\end{center} +\end{frame} + +\begin{frame} +\frametitle{Anonymity isn't steganography} +Attacker can tell Alice is talking to someone, how often, and how much data is sent. +\bigskip + +\begin{center} +\includegraphics[width=5cm]{../images/steganography-cc-by-sa} +\end{center} +\end{frame} + +\begin{frame} +\frametitle{Anonymity isn't just wishful thinking...} +\begin{itemize} +\item "You can't prove it was me!" +\pause \item "Promise you won't look" +\pause \item "Promise you won't remember" +\pause \item "Promise you won't tell" +\pause \item "I didn't write my name on it!" +\pause \item "Isn't the Internet already anonymous?" +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{..since "weak" isn't anonymity.} +\begin{itemize} +\item<1> \textit{"You can't prove it was me!"} Proof is a very \textbf{strong} word. Statistical analysis allows suspicion to become certainty. +\item<2> \textit{"Promise you won't look/remember/tell"} Will other parties have the abilities and incentives to keep these promises? +\item<3> \textit{"I didn't write my name on it!"} Not what we're talking about. +\item<4> \textit{"Isn't the Internet already anonymous?"} Nope! +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Anonymous communication} +\begin{itemize} +\item People have to hide in a crowd of other people ("anonymity loves company") +\item The goal of the system is to make all users look as similar as possible, to give a bigger crowd +\item Hide who is communicating with whom +\item Layered encryption and random delays hide correlation between input traffic and output traffic +\end{itemize} +\end{frame} + +% What is Tor? +\begin{frame} +\frametitle{What is Tor?} +\begin{itemize} +\item Online anonymity software and network +\pause \item Open source, freely available (3-clause BSD license) +\pause \item Active research environment: \\ +Rice, UMN, NSF, NRL, Drexel, Waterloo, Cambridge UK, Bamberg Germany, Boston Univ, Harvard, MIT, RPI, Georgia Tech +\pause \item Increasingly diverse toolset: \\ +Tor, Torbutton, Tor Browser Bundle, TAILS Anonymous Operating System, +Tor Weather, GetTor, Thandy, Orbot, Tor Check, Arm, Torouter, Tor Cloud +and more +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{What makes Tor different, part 1} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../images/single_hop_relay}} +\only<2>{\includegraphics[height=7cm]{../images/evil_single_hop_relay}} +\only<3>{\includegraphics[height=7cm]{../images/data_snooping_single_hop_relay}} +\end{overlayarea} +\end{frame} + +% And what makes Tor different? +\begin{frame} +\frametitle{What makes Tor different, part 2} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../../website/images/htw1}} +\only<2>{\includegraphics[height=7cm]{../../website/images/htw2}} +\only<3>{\includegraphics[height=7cm]{../../website/images/htw3}} +\end{overlayarea} +\end{frame} + +\begin{frame} +\frametitle{Bridges versus relays} +\begin{itemize} +\item A step forward in the blocking resistance race +\item Bridge relays (or "bridges" for short) are Tor relays that aren't +listed in the main Tor directory +\item To use a bridge, you will need to locate one first (can be done +using bridges.torproject.org, email, social media etc) +\item A bridge will act as the first hop in the circuit +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Hidden services} +\begin{itemize} +\item Tor makes it possible for users to hide their locations while +offering various kinds of services, such a website or an im server +\item Using Tor "rendezvous points," other Tor users can connect to +these hidden services, each without knowing the other's network identity +\item A hidden service will have an address that ends in .onion, e.g. +http://duskgytldkxiuqc6.onion/ +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Who uses Tor?} +\parbox{8cm}{\sloppy +\setbeamercolor{background}[\includegraphics[scale=0.35]{../images/anonymousman}} +\parbox{3cm}{\sloppy +\begin{flushleft} +\begin{itemize} +\begin{small} +\item Normal people +\item Law Enforcement +\item Human Rights Activists +\item Business Execs +\item Militaries +\item Abuse Victims +\end{small} +\end{itemize} +\end{flushleft} +} +\end{frame} + +\begin{frame} +\frametitle{estimated 300k to 800k daily users} +\setbeamercolor{background}[\includegraphics[scale=0.4]{../images/huge-crowd}] +\end{frame} + +\begin{frame} +\frametitle{How many people use Tor daily?} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../images/direct-users-off-2010-09-19-off-300-2011-09-19-all}} +% Should probably add a graph for daily bridge users, but the graph +% seems a bit off +%\only<2>{\includegraphics[height=7cm]{../images/direct-users-off-2010-09-19-off-300-2011-09-19-all}} +\end{overlayarea} +\end{frame} + +\begin{frame} +\frametitle{Tor users in China} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../images/direct-users-2010-09-11-off-300-2011-09-11-cn}} +\only<2>{\includegraphics[height=7cm]{../images/bridge-users-2010-09-11-300-2011-09-11-cn}} +\end{overlayarea} +\end{frame} + +\begin{frame} +\frametitle{Tor users in Egypt} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../images/direct-users-2010-09-11-off-300-2011-09-11-eg}} +\only<2>{\includegraphics[height=7cm]{../images/bridge-users-2010-09-11-300-2011-09-11-eg}} +\end{overlayarea} +\end{frame} + +\begin{frame} +\frametitle{Tor users in Iran} +\begin{overlayarea}{9cm}{6cm} +\only<1>{\includegraphics[height=7cm]{../images/direct-users-off-2010-09-11-off-300-2011-09-11-ir}} +\only<2>{\includegraphics[height=7cm]{../images/bridge-users-2010-09-11-300-2011-09-11-ir}} +\end{overlayarea} +\end{frame} + +\begin{frame} +\frametitle{Anonymity, Usability, and Humans} +\begin{itemize} +\item Allow the user to fully configure Tor rather than manually searching for and opening text files. +\item Let users learn about the current state of their Tor connection, and configure or find out whether any of their applications are using it. +\item Make alerts and error conditions visible to the user. +\item Run on Windows, Linux, and OS X, on a normal consumer-level machine. +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Time for a demo} +Demonstration of Tor Browser Bundle +\end{frame} + +\begin{frame} +\frametitle{Experience so far} +\begin{itemize} +\item Our web site is confusing to users and not technical enough for researchers. +\pause \item The quality of translations can vary. +\pause \item Concepts of anonymity and its threats escape most users.\\"I want my Youtube!" "I use tor to organize on facebook." +\pause \item Cultural differences and their expectations of software, usability, anonymity, privacy, and what tor provides. +\pause \item Software leaks data all over the place. Stopping these leaks leads to unexpected user experiences. +\pause \item Five years since we last dabbled in Usability. +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Next steps and how you can help} +\begin{itemize} +\item Test software. +\item Provide feedback and suggest improvements. +\item Help with development. +\item Visit \url{https://www.torproject.org/} for more information, links, and ideas. +\end{itemize} +\end{frame} + +\begin{frame} +\frametitle{Copyright} +\begin{itemize} +\item who uses tor? \url{http://www.flickr.com/photos/mattw/2336507468/siz}, Matt Westervelt, CC-BY-SA. +\item 500k, \url{http://www.flickr.com/photos/lukaskracic/334850378/sizes/l/}, Luka Skracic, used with permission. +\end{itemize} +\end{frame} + +\end{document} Added: projects/presentations/images/bridge-users-2010-09-11-300-2011-09-11-ir.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/bridge-users-2010-09-11-300-2011-09-11-ir.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: projects/presentations/images/direct-users-off-2010-09-11-off-300-2011-09-11-ir.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/direct-users-off-2010-09-11-off-300-2011-09-11-ir.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: projects/presentations/images/direct-users-off-2010-09-19-off-300-2011-09-19-all.png =================================================================== (Binary files differ) Property changes on: projects/presentations/images/direct-users-off-2010-09-19-off-300-2011-09-19-all.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream

1 0

[bridgedb/master] point to correct entry in I18n.BRIDGEDB_TEXT
by arma＠torproject.org 21 Sep '11

21 Sep '11

commit deb700c43bc5ab8bb9479d0257a15e6fc1c64922 Author: aagbsn <aagbsn(a)extc.org> Date: Tue Sep 20 16:17:39 2011 -0700 point to correct entry in I18n.BRIDGEDB_TEXT use correct text for blocked bridges this didn't get changed when merging. --- lib/bridgedb/Server.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/bridgedb/Server.py b/lib/bridgedb/Server.py index 964506a..956cc59 100644 --- a/lib/bridgedb/Server.py +++ b/lib/bridgedb/Server.py @@ -151,7 +151,7 @@ class WebResource(twisted.web.resource.Resource): if bridges: answer = "".join("%s %s\n" % ( b.getConfigLine(self.includeFingerprints), - (I18n.BRIDGEDB_TEXT[9] if b.isBlocked(countryCode) else "") + (I18n.BRIDGEDB_TEXT[16] if b.isBlocked(countryCode) else "") ) for b in bridges) else: answer = t.gettext(I18n.BRIDGEDB_TEXT[7])

1 0

[bridgedb/master] import after logging is configured
by arma＠torproject.org 21 Sep '11

21 Sep '11

commit 40c835ba1e0e2600ebde9fe36320d600ea15bdec Author: aagbsn <aagbsn(a)extc.org> Date: Mon Sep 19 17:14:09 2011 -0700 import after logging is configured bridgedb.Server tries to graciously import GeoIP support, but because logging is not yet configured at import time Python creates a default handler that goes to the console and ignores further basicConfig calls See also: http://stackoverflow.com/questions/1943747/ \ python-logging-before-you-run-logging-basicconfig Our solution is to relocate the import so that configureLogging() is called first. --- lib/bridgedb/Main.py | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/lib/bridgedb/Main.py b/lib/bridgedb/Main.py index 2ef56bf..3e06936 100644 --- a/lib/bridgedb/Main.py +++ b/lib/bridgedb/Main.py @@ -18,7 +18,6 @@ from twisted.internet import reactor import bridgedb.Bridges as Bridges import bridgedb.Dist as Dist import bridgedb.Time as Time -import bridgedb.Server as Server import bridgedb.Storage import bridgedb.Opt as Opt import bridgedb.Bucket as Bucket @@ -235,6 +234,11 @@ def startup(cfg): # Set up logging. configureLogging(cfg) + #XXX import Server after logging is set up + # Otherwise, python will create a default handler that logs to + # the console and ignore further basicConfig calls + import bridgedb.Server as Server + # Load the master key, or create a new one. key = getKey(cfg.MASTER_KEY_FILE)

1 0

[torspec/master] Add two small proposals
by nickm＠torproject.org 20 Sep '11

20 Sep '11

commit 0c856b58719133110d09f35ca8eb47728d42748c Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Sep 20 15:34:48 2011 -0400 Add two small proposals --- proposals/184-v3-link-protocol.txt | 82 +++++++++++++++++++++++++++++++++ proposals/185-dir-without-dirport.txt | 41 ++++++++++++++++ 2 files changed, 123 insertions(+), 0 deletions(-) diff --git a/proposals/184-v3-link-protocol.txt b/proposals/184-v3-link-protocol.txt new file mode 100644 index 0000000..910f223 --- /dev/null +++ b/proposals/184-v3-link-protocol.txt @@ -0,0 +1,82 @@ +Filename: 184-v3-link-protocol.txt +Title: Miscellaneous changes for a v3 Tor link protocol +Author: Nick Mathewson +Created: 19-Sep-2011 +Status: Open +Target: 0.2.3.x + +Overview: + + When proposals 176 and 179 are implemented, Tor will have a new + link protocol. I propose two simple improvements for the v3 link + protocol: a more partitioned set of which types indicate + variable-length cells, and a better way to handle link padding if + and when we come up with a decent scheme for it. + +Motivation: + + We're getting a new link protocol in 0.2.3.x, thanks (again) to + TLS fingerprinting concerns. When we do, it'd be nice to take + care of some small issues that require a link protocol version + increment. + + First, our system for introducing new variable-length cell types + has required a protocol increment for each one. Unlike + fixed-length (512 byte) cells, we can't add new variable-length + cells in the existing link protocols and just let older clients + ignore them, because unless the recipient knows which cells are + variable-length, it will treat them as 512-byte cells and discard + too much of the stream or too little. In the past, it's been + useful to be able to introduce new cell types without having to + increment the link protocol version. + + Second, once we have our new TLS handshake in place, we will want + a good way to address the remaining fingerprinting opportunities. + Some of those will likely involve traffic volume. We can't fix + that easily with our existing PADDING cell type, since PADDING + cells are fixed-length, and wouldn't be so easy to use to break up + our TLS record sizes. + +Design: Indicating variable-length cells. + + Beginning with the v3 link protocol, we specify that all cell + types in the range 128..255 indicate variable-length cells. + Cell types in the range 0..127 are still used for 512-byte + cells, except that the VERSIONS cell type (7) also indicates a + variable-length cell (for backward compatibility). + + As before, all Tor instances must ignore cells with types that + they don't recognize. + +Design: Variable-length padding. + + We add a new variable-length cell type, "VPADDING", to be used for + padding. All Tor instances may send a DROP cell at any point that + a VERSIONS cell is not required; a VPADDING cell's body may be any + length; the body of a VPADDING cell MAY have any content. Upon + receiving a VPADDING cell, the recipient should drop it, as with a + PADDING cell. + +Interaction with proposal 176: + + Proposal 176 says that during the v3 handshake, no cells other + than VERSIONS, AUTHENTICATE, AUTH_CHALLENGE, CERT, and NETINFO are + allowed, and those are only allowed in their standard order. If + this proposal is accepted, then VPADDING cells should also be + allowed in the handshake at any point after the VERSIONS cell. + They should be included when computing the "SLOG" and "CLOG" + handshake-digest fields of the AUTHENTICATE cell. + +Notes on future-proofing: + + It may be in the future we need a new cell format that is neither the + original 512-byte format nor the variable-length format. If we + do, we can just increment the link protocol version number again. + + Right now we have 10 cell types; with this proposal and proposal + 176, we will have 14. It's unlikely that we'll run out any time + soon, but if we start to approach the number 64 with fixed-length + cell types or 196 with var-length cell types, we should consider + tweaking the link protocol to have a variable-length cell type + encoding. + diff --git a/proposals/185-dir-without-dirport.txt b/proposals/185-dir-without-dirport.txt new file mode 100644 index 0000000..c84ec35 --- /dev/null +++ b/proposals/185-dir-without-dirport.txt @@ -0,0 +1,41 @@ +Filename: 185-dir-without-dirport.txt +Title: Directory caches without DirPort +Author: Nick Mathewson +Created: 20-Sep-2011 +Status: Open + +Overview: + + Exposing a directory port is no longer necessary for running as a + directory cache. This proposal suggests that we eliminate that + requirement, and describes how. + +Motivation: + + Now that we tunnel directory connections by default, it is no + longer necessary to have a DirPort to be a directory cache. In + fact, bridges act as directory caches but do not actually have a + DirPort exposed. It would be nice and tidy to expand that + property to the rest of the network. + +Configuration: + + Add a new torrc option, "DirCache". Its values can be "0", "1", + and "auto". If it is 0, we never act as a directory cache, even + if DirPort is set. If it is 1, then we act as a directory cache + according to same rules as those used for nodes that set a + DirPort. If it is "auto", then Tor decides whether to act as a + directory cache. + +Advertising cache status: + + Nodes which are running as a directory cache but which do not have + a DirPort set should set the entry "dir-cache 1" in their router + descriptors. + +Consensus: + + Authorities should assign a "DirCache" flag to all nodes running + as a directory cache that do not set a DirPort. + + This does not require a new version of the consensus algorithm.

1 0

[torspec/master] Add a draft for a successor to proposal 118.
by nickm＠torproject.org 20 Sep '11

20 Sep '11

commit 20a5ec257603e025a8b08dc57c1a8390ac019598 Author: Nick Mathewson <nickm(a)torproject.org> Date: Tue Sep 20 15:35:14 2011 -0400 Add a draft for a successor to proposal 118. --- proposals/000-index.txt | 12 +- proposals/118-multiple-orports.txt | 3 +- proposals/ideas/xxx-multiple-orports.txt | 259 ++++++++++++++++++++++++++++++ 3 files changed, 269 insertions(+), 5 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index c4106e8..bc25574 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -38,7 +38,7 @@ Proposals by number: 115 Two Hop Paths [DEAD] 116 Two hop paths from entry guards [DEAD] 117 IPv6 exits [ACCEPTED] -118 Advertising multiple ORPorts at once [NEEDS-REVISION] +118 Advertising multiple ORPorts at once [SUPERSEDED] 119 New PROTOCOLINFO command for controllers [CLOSED] 120 Shutdown descriptors when Tor servers stop [DEAD] 121 Hidden Service Authentication [FINISHED] @@ -103,7 +103,9 @@ Proposals by number: 180 Pluggable transports for circumvention [OPEN] 181 Optimistic Data for Tor: Client Side [CLOSED] 182 Credit Bucket [DRAFT] -183 Refill Intervals [CLOSED] +183 Refill Intervals [OPEN] +184 Miscellaneous changes for a v3 Tor link protocol [OPEN] +185 Directory caches without DirPort [OPEN] Proposals by status: @@ -118,7 +120,6 @@ Proposals by status: 179 TLS certificate and parameter normalization [for 0.2.3.x] 182 Credit Bucket NEEDS-REVISION: - 118 Advertising multiple ORPorts at once 131 Help users to verify they are using Tor NEEDS-RESEARCH: 145 Separate "suitable as a guard" from "suitable as a new guard" @@ -134,6 +135,9 @@ Proposals by status: 177 Abstaining from votes on individual flags [for 0.2.3.x] 178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x] 180 Pluggable transports for circumvention [for 0.2.3.x] + 183 Refill Intervals + 184 Miscellaneous changes for a v3 Tor link protocol [for 0.2.3.x] + 185 Directory caches without DirPort 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] @@ -187,10 +191,10 @@ Proposals by status: 171 Separate streams across circuits by connection metadata [in 0.2.3.3-alpha] 174 Optimistic Data for Tor: Server Side [in 0.2.3.1-alpha] 181 Optimistic Data for Tor: Client Side [in 0.2.3.3-alpha] - 183 Refill Intervals [in 0.2.3.4-alpha] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration + 118 Advertising multiple ORPorts at once 124 Blocking resistant TLS certificate usage 149 Using data from NETINFO cells 153 Automatic software update protocol diff --git a/proposals/118-multiple-orports.txt b/proposals/118-multiple-orports.txt index 64a6000..b21f034 100644 --- a/proposals/118-multiple-orports.txt +++ b/proposals/118-multiple-orports.txt @@ -2,7 +2,8 @@ Filename: 118-multiple-orports.txt Title: Advertising multiple ORPorts at once Author: Nick Mathewson Created: 09-Jul-2007 -Status: Needs-Revision +Status: Superseded +Superseded-By: xxx-multiple-orports.txt [Needs Revision: This proposal needs revision to come up to 2011 standards and take microdescriptors into account.] diff --git a/proposals/ideas/xxx-multiple-orports.txt b/proposals/ideas/xxx-multiple-orports.txt new file mode 100644 index 0000000..fc3a741 --- /dev/null +++ b/proposals/ideas/xxx-multiple-orports.txt @@ -0,0 +1,259 @@ +Filename: xxx-multiple-orports.txt +Title: Multiple addresses for one OR or bridge +Author: Nick Mathewson +Created: 19-Sep-2011 +Supersedes: 118 +Status: Draft + +Overview: + + This document is a proposal for servers to advertise multiple + address/port combinations for their ORPort. + + It supersedes proposal 118. + +Motivation: + + Sometimes servers want to support multiple ports for incoming + connections, either in order to support multiple address families + (ie, to add IPv6 support), to better use multiple interfaces, or + to support a variety of FascistFirewallPorts settings. This is + easy to set up now, but there's no way to advertise it to clients. + +Configuring additional addresses and ports: + + In consonance with our chances to the (Socks|Trans|NATD|DNS)Port + options made in 0.2.3.x for proposal 171, I make a corresponding + change to allow multiple SocksPort options and deprecate + SocksListenAddress. + + The new syntax will be: + + "SocksPort" PortDescription Options? + + Options = "NoAdvertise" | "NoListen" | "AllAddrs" | "IPV4Only" + | "IPV6Only" + + PortDescription = PORTLIST | + ADDRESS ":" PORTLIST | + Hostname ":" PORTLIST + + (PORTLIST and ADDRESS are defined below.) + + The 'NoAdvertise' option performs the function of the old + SocksListenAddress option. If it is set, we bind a port, but + don't put it in our descriptor. + + The 'NoListen' option tells Tor to advertise an address, but not + bind to it. The operator needs to use some other mechanism to + ensure that ports are redirected to ports that _are_ listened on. + + The 'AllAddrs' option tells Tor that if no address is given in the + PortDescription part, we should bind/advertise every one of our + publicly visible unicast addresses; and that if a hostname address + is given in the PortDescription, we should bind/advertise every + publicly visible unicast address that the hostname resolves to. + (Q: Should this be on by default?) The 'IPv4Only' and 'IPv6Only' + options tell Tor to interpret such situations as applying only to + IPv4 addresses or to IPv6 addresses. + + As with the client *Port options, only the old format or the new + format are allowed: either a single numeric socksport and zero or + more sockslistenaddress options, or a set of one or more + SocksPorts in the new extended format. + + In current operating systems (unless we get into crazy nonportable + tricks) we need to use one socket for every address:port that Tor + bind on. As a sanity check, we can limit the number of such + sockets we use to, say, 64. If you want to bind lots more + address:port combinations, you'll want to do it at the + firewall/routing level. + + Example: We want to bind on 0.0.0.0:9001 + + SocksPort 9001 + + Example: Our firewall is redirecting ports 80, 443, and 7000-8000 + on all hosts in x.244.2.0/24 onto our port 2929. + + SocksPort 2929 no-advertise + SocksPort x.244.2.0/24:80,443,7000-8000 no-listen + + Example: We have a dynamic DNS provider that maps + tornode.example.com to our current external IPv4 and IPv6 + addresses. Our firefall forwards port 443 on those address to our + port 1337. + + SocksPort 1337 no-advertise alladdrs + SocksPort tornode.example.com:443 no-bind alladdrs + +Self-testing: + + Right now, Tor nodes need to check every port that advertise + before they declare themselves reachable. If a Tor has a large IP + a lot of advertised ports, that could be prohibitive. + Instead, it should try a sample of ports for each address. It should + not advertise any given SocksPort line until it has tried + extending to or connecting to a sample of the address/port + combinations. + + It will now be possible for a Tor node to find that some addresses + work and others do not. In this case, the node should only + advertise socksport lines that have been checked. + + {Until support is added for extend cells to IPv6 addresses, it + will only be possible to test IPv6 addresses by connecting + directly. We might want to just skip self-testing those until we + have IPv6 extend support.} + +New descriptor syntax: + + We add a new line in the router descriptor, "or-address". This line + can occur zero, one, or multiple times. Its format is: + + or-address SP ADDRESS ":" PORTLIST NL + + ADDRESS = IP6ADDR | IP4ADDR + IPV6ADDR = an ipv6 address, surrounded by square brackets. + IPV4ADDR = an ipv4 address, represented as a dotted quad. + PORTLIST = PORTSPEC | PORTSPEC "," PORTLIST + PORTSPEC = PORT | PORT "-" PORT + PORT = a number between 1 and 65535 inclusive. + + [This is the regular format for specifying sets of addresses and + ports in Tor.] + + A descriptor should not include an or-address line that does + nothing but duplicate the address:port pair from its "router" + line. + + A node must not list more than 8 or-address lines. + + (Q: Any reason to allow more than 2?) + +New authority behavior: + + The same rationale applies as for self-testing. An authority + needs to test the main address:port from the router line, and + every or-address line. For or-address lines that contains + multiple ports, it needs to test all of them if they are few, or a + sample if they are not. + + An authority shouldn't list a node as Running unless every + or-address line it advertises looks like it will work. + +Consensus directories and microdescriptors: + + We introduce a new line type for microdescriptors and consensuses, + "a". Each "a" line has the same format as an or-address line. + The "a" lines (if any) appear immediately after the "r" line for a + router in the consensus, and immediately after the "onion-key" + entry in a microdescriptor. + + Clients that use microdescriptors should consider a node's + addresses to be the address:port listed in the "r" line of a + consensus, plus all "a" lines for that node in the consensus, plus + all "a" lines for that node in the its microdescriptor. Clients + that use full descriptors should consider a node's addresses to be + everything listed in its descriptor. + + We will have to define a new voting algorithm version; when using + this version or later, votes should include a single "a" line for + every relay that has an IPv6 address, to include the first IPv6 + line in its descriptor. (If there are no or-address lines, then + they shouldn't include any "a" lines.) The remaining or-address + lines will turn into "a" lines in the microdescriptor. + + As with other data in the vote derived from the descriptor, + the vote will include whichever set of "a" lines are given by the + most authorities who voted for the descriptor digest that will be + used for the router. + +Directory authorities with more addresses: + + We need a way for a client to configure a TrustedDirServer as + having multiple OR addresses, specifically so that we can give at + least one default authority an IPv6 address for bootstrapping + purposes. + + (Q: Do any of the current authorities have stable IPv6 addresses?) + + We will want to allow the address in a "dir-source" line in a vote + to contain an IPv6 address, and/or allow voters to list themselves + with more addresses in votes/consensuses. But right now, nothing + actually uses the addresses listed for voters in dir-source lines + for anything besides log messages. + +Client behavior: + + I propose that initially we shouldn't change client behavior too + much here. + + (Q: Is there any advantage to having a client choose a random + address? If so we can do it later.) + + Tor clients not running with bridges, and running with IPv4 + support, should still use the address and ORPort as advertised in + the router or r line of the appropriate directory object. + + Tor clients not running with bridges, and running without IPv4 + support, should use the first listed IPv6 address for a node, + using the lowest-numbered listed port for that address. They + should only connect to nodes with an IPv6 address. + + Clients should accept Bridge lines with IPv6 addresses, and + address:port sets, in addition to the lines they currently accept. + + Clients, for now, should only use the address:port from the router + line when making EXTEND cells; see below. + +Nodes without IPv4 addresses: + + Currently Tor requires every node or bridge to have an IPv4 + address. We will want to maintain this property for the + forseeable future, but we should define how a node without an IPv4 + address would advertise itself. + + Right now, there's no way to do that: if anything but an IPv4 + address appears in a router line of a routerdesc, or the r line of + a consensus, then it won't parse. If something that looks like an + IPv4 address appears there, clients will (I believe) try to + connect to it. + + We can make this work, though: let's allow nodes to list themselves + with a magic IPv4 address (say, 127.1.1.1) if they have + or-address entries containing only IPv6 address. We could give + these nodes a new flag other than Running to indicate that they're + up, and not give them the Running flag. That way, old clients + would never try to use them, but new clients could know to treat + the new flag as indicating that the node is running, and know not + to connect to a node listed with address 127.1.1.1. + +Interaction with EXTEND and NETINFO: + + Currently, EXTEND cells only support IPv4 addresses, so we should + use only those. There is a proposal draft to support more address + types. + + A server's NETINFO cells must list all configured addresses for a + server. + +Why not extend DirPort this way too? + + Because clients are all using BEGINDIR these days. + +Why not have address ranges? + + Earlier drafts of this proposal suggested that clients should + provide not only ranges of ports, but also ranges of addresses, + specified with bitmasks. That's a neat idea for circumvention, + but if we did that, you wouldn't want to advertise publicly that + you have an entire address range. + +Coding impact: + + In addition to the obvious changes, we need to audit everything + that looks up or compares OR connections and nodes by address:port + under the assumptions that each node has only a single address or + ORPort. +

1 0

[torflow/master] Fix an exception in emailed results.
by mikeperry＠torproject.org 20 Sep '11

20 Sep '11

commit b596753d5326da49eaddfc097b3777a8f2d084c1 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Sep 20 10:38:51 2011 -0700 Fix an exception in emailed results. --- NetworkScanners/ExitAuthority/snakeinspector.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/NetworkScanners/ExitAuthority/snakeinspector.py b/NetworkScanners/ExitAuthority/snakeinspector.py index 5eb9e0f..b46f702 100755 --- a/NetworkScanners/ExitAuthority/snakeinspector.py +++ b/NetworkScanners/ExitAuthority/snakeinspector.py @@ -260,7 +260,7 @@ def main(argv): text += "authdirbadexit "+socket.inet_ntoa(struct.pack(">I",r.exit_ip))+" # "+r.exit_name+"\n" text += "\n# approved-routers\n" text += "!badexit "+r.exit_node+" # "+r.exit_name+"\n" - text += + "\n------------------------------------------\n" + text += "\n------------------------------------------\n" except Exception, e: text += traceback.format_exc() # TODO: Attach files? Or is that too much.. Maybe serve

1 0

[torflow/master] Clarify soat_config names for emailing results.
by mikeperry＠torproject.org 20 Sep '11

20 Sep '11

commit 1ce6ee264dced96e452462ba839e8ce7393cdfcb Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Tue Sep 20 10:47:22 2011 -0700 Clarify soat_config names for emailing results. --- NetworkScanners/ExitAuthority/snakeinspector.py | 2 +- NetworkScanners/ExitAuthority/soat_config.py | 7 +++---- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/NetworkScanners/ExitAuthority/snakeinspector.py b/NetworkScanners/ExitAuthority/snakeinspector.py index b46f702..cf1edfe 100755 --- a/NetworkScanners/ExitAuthority/snakeinspector.py +++ b/NetworkScanners/ExitAuthority/snakeinspector.py @@ -265,7 +265,7 @@ def main(argv): text += traceback.format_exc() # TODO: Attach files? Or is that too much.. Maybe serve # them via http and include links? - send_mail(from_email, to_email, subject, text) + send_mail(mail_from_email, mail_to_email, subject, text) if __name__ == "__main__": main(sys.argv) diff --git a/NetworkScanners/ExitAuthority/soat_config.py b/NetworkScanners/ExitAuthority/soat_config.py index 99cd4ff..6beba50 100644 --- a/NetworkScanners/ExitAuthority/soat_config.py +++ b/NetworkScanners/ExitAuthority/soat_config.py @@ -43,10 +43,7 @@ max_content_size = 256*1024 refetch_ip = None #refetch_ip = "4.4.4.4" -# Email settings for email scans. -from_email = "Tor Exit Scanner <noreply(a)torproject.org>" -to_email = ["Tor Exit Scanner List <flynn(a)torproject.org>"] - +# Email settings for emailing scanned results: mail_server = "127.0.0.1" # Email authentication # If your smtp server requires a username and password, set @@ -57,6 +54,8 @@ mail_user = "soat(a)fscked.org" mail_password = "password" mail_tls = False # Requires Python >= 2.6 mail_starttls = False +mail_from_email = "Tor Exit Scanner <"+mail_user+">" +mail_to_email = ["Tor Exit Scanner List <tor-exitscanner(a)lists.torproject.org>"] # What percentage of tested nodes must disagree with our local fetches before # we ignore the target site/url

1 0

r25091: {website} add community-support list and clarify that if you leave a m (website/trunk/about/en)
by Andrew Lewman 20 Sep '11

20 Sep '11

Author: phobos Date: 2011-09-20 17:25:55 +0000 (Tue, 20 Sep 2011) New Revision: 25091 Modified: website/trunk/about/en/contact.wml Log: add community-support list and clarify that if you leave a message, you should leave a way to reach you too. Modified: website/trunk/about/en/contact.wml =================================================================== --- website/trunk/about/en/contact.wml 2011-09-20 17:22:36 UTC (rev 25090) +++ website/trunk/about/en/contact.wml 2011-09-20 17:25:55 UTC (rev 25091) @@ -21,6 +21,9 @@ A few other addresses are more specific: <ul> + <li><i>community-support at lists.torproject.org</i> is for + volunteers helping people with questions about using or configuring + Tor.</li> <li><i>tor-translation at lists.torproject.org</i> can put new <a href="<page getinvolved/translation>">website translations</a> into place, and help answer questions about existing and new translations.</li> @@ -62,7 +65,7 @@ <a id="phone"></a> <p>If none of the above appeal to you, calling +1-781-352-0568 will reach the Tor office. Should there be no answer, please leave - a message.</p> + a message with a way to reach you.</p> </div>

1 0

r25090: {translation} Removed puppettor from website translations (in translation/trunk/projects/website/po: .tx templates/projects)
by Runa Sandvik 20 Sep '11

20 Sep '11

Author: runa Date: 2011-09-20 17:22:36 +0000 (Tue, 20 Sep 2011) New Revision: 25090 Removed: translation/trunk/projects/website/po/templates/projects/3-low.puppettor.pot Modified: translation/trunk/projects/website/po/.tx/config Log: Removed puppettor from website translations Modified: translation/trunk/projects/website/po/.tx/config =================================================================== --- translation/trunk/projects/website/po/.tx/config 2011-09-20 15:42:50 UTC (rev 25089) +++ translation/trunk/projects/website/po/.tx/config 2011-09-20 17:22:36 UTC (rev 25090) @@ -196,11 +196,6 @@ source_file = templates/1-high.index.pot source_lang = en -[torproject.5-website-projects-puppettor-pot] -file_filter = <lang>/projects/3-low.puppettor.po -source_file = templates/projects/3-low.puppettor.pot -source_lang = en - [torproject.5-website-about-volunteers-pot] file_filter = <lang>/about/3-low.volunteers.po source_file = templates/about/3-low.volunteers.pot Deleted: translation/trunk/projects/website/po/templates/projects/3-low.puppettor.pot =================================================================== --- translation/trunk/projects/website/po/templates/projects/3-low.puppettor.pot 2011-09-20 15:42:50 UTC (rev 25089) +++ translation/trunk/projects/website/po/templates/projects/3-low.puppettor.pot 2011-09-20 17:22:36 UTC (rev 25090) @@ -1,35 +0,0 @@ -# SOME DESCRIPTIVE TITLE -# Copyright (C) YEAR The Tor Project, Inc. -# This file is distributed under the same license as the PACKAGE package. -# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. -# -#, fuzzy -msgid "" -msgstr "" -"Project-Id-Version: PACKAGE VERSION\n" -"POT-Creation-Date: 2010-12-26 14:32+0000\n" -"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" -"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" -"Language-Team: LANGUAGE <LL(a)li.org>\n" -"Language: \n" -"MIME-Version: 1.0\n" -"Content-Type: text/plain; charset=UTF-8\n" -"Content-Transfer-Encoding: 8bit\n" - -#. type: Content of: <div><div> -#: /home/runa/transifex/website/projects/en/puppettor.wml:8 -msgid "" -"<a href=\"<page index>\">Home » </a> <a href=\"<page projects/projects>" -"\">Projects » </a> <a href=\"<page projects/projects>\">Sample " -"Project</a>" -msgstr "" - -#. type: Content of: <div><div><h1> -#: /home/runa/transifex/website/projects/en/puppettor.wml:14 -msgid "Sample Tor Project" -msgstr "" - -#. type: Content of: <div><div> -#: /home/runa/transifex/website/projects/en/puppettor.wml:15 -msgid "Here is some information" -msgstr ""

1 0

r25089: {website} update windows vidalia bundle to have the right tor version (website/trunk/include)
by Erinn Clark 20 Sep '11

20 Sep '11

Author: erinn Date: 2011-09-20 15:42:50 +0000 (Tue, 20 Sep 2011) New Revision: 25089 Modified: website/trunk/include/versions.wmi Log: update windows vidalia bundle to have the right tor version Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2011-09-20 11:53:49 UTC (rev 25088) +++ website/trunk/include/versions.wmi 2011-09-20 15:42:50 UTC (rev 25089) @@ -62,7 +62,7 @@ <define-tag package-win32-stable whitespace=delete>/dist/win32/tor-<version-win32-stable>-win32.exe</define-tag> <define-tag package-win32-alpha whitespace=delete>/dist/win32/tor-<version-win32-alpha>-win32.exe</define-tag> -<define-tag file-win32-bundle-stable whitespace=delete>vidalia-bundle-<version-win32-bundle-stable>-0.2.14.exe</define-tag> +<define-tag file-win32-bundle-stable whitespace=delete>vidalia-bundle-<version-win32-bundle-stable>-0.2.14-1.exe</define-tag> <define-tag package-win32-bundle-stable whitespace=delete>/dist/vidalia-bundles/<file-win32-bundle-stable></define-tag> <define-tag file-win32-bundle-alpha whitespace=delete>vidalia-bundle-<version-win32-bundle-alpha>-0.2.14.exe</define-tag> <define-tag package-win32-bundle-alpha whitespace=delete>/dist/vidalia-bundles/<file-win32-bundle-alpha></define-tag>

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-commits September 2011