- tor-commits - lists.torproject.org

[torspec/master] prop176 evisions based on Roger's tor-dev email of 20 Sep.
by nickm＠torproject.org 21 Sep '11

21 Sep '11

commit 8d51fb27adcddca401a7d77c5b69bc25a199adaa Author: Nick Mathewson <nickm(a)torproject.org> Date: Wed Sep 21 14:01:41 2011 -0400 prop176 evisions based on Roger's tor-dev email of 20 Sep. --- proposals/176-revising-handshake.txt | 49 ++++++++++++++++----------------- 1 files changed, 24 insertions(+), 25 deletions(-) diff --git a/proposals/176-revising-handshake.txt b/proposals/176-revising-handshake.txt index 39f4465..52a2d0a 100644 --- a/proposals/176-revising-handshake.txt +++ b/proposals/176-revising-handshake.txt @@ -146,16 +146,11 @@ Supersedes: 169 1) We should make it easier to use self-signed certs, or maybe even existing HTTPS certificates, for the server side handshake, since most non-Tor SSL handshakes use either - self-signed certificates or + self-signed certificates or CA-signed certificates. - 2) We should make it harder to probe for a Tor server. Right - now, you can just do a handshake with a server, - renegotiate, then see if it gives you a VERSIONS cell. - That's no good. - - 3) We should allow other changes in our use of TLS and in our + 2) We should allow other changes in our use of TLS and in our certificates so as to resist fingerprinting based on how - our certificates look. + our certificates look. (See proposal 179.) 3. Design @@ -217,6 +212,7 @@ Supersedes: 169 S->C: VERSIONS cell, CERT cell, AUTH_CHALLENGE cell, NETINFO cell C->S: Optionally: CERT cell, AUTHENTICATE cell + C->S: NETINFO cell A "CERTS" cell contains a set of certificates; an "AUTHENTICATE" cell authenticates the client to the server. More on these @@ -253,8 +249,7 @@ Supersedes: 169 signed by a CA, then the issuer will surely have more DN fields set. Certificates that aren't trying to resist fingerprinting can trivially become v3 by using a CN that doesn't end with .net, - or using a 1024-bit key. - + or using a key longer than 1024 bits. 3.3. Authenticating via Tor cells: server authentication @@ -321,20 +316,28 @@ Supersedes: 169 the connection. If the client wanted to connect to a server with a different identity key, the client closes the connection. - An AUTH_CHALLENGE cell is a variable-length cell with the following fields: Challenge [32 octets] + N_Methods [2 octets] + Methods [2 * N_Methods octets] + It is sent from the server to the client. Clients MUST ignore unexpected bytes at the end of the cell. Servers MUST generate every challenge using a strong RNG or PRNG. + The Challenge field is a randomly generated string that the + client must sign (a hash of) as part of authenticating. The + methods are the authentication methods that the server will + accept. Only one authentication method is defined right now; see + 3.4 below. + 3.4. Authenticating via Tor cells: Client authentication A client does not need to authenticate to the server. If it does not wish to, it responds to the server's valid CERT cell by - sending a NETINFO cell: once it has gotten a valid NETINFO cell - back, the client should consider the connection open, and the + sending a NETINFO cell: once it has gotten a valid NETINFO cell, + the client should consider the connection open, and the server should consider the connection as opened by an unauthenticated client. @@ -352,7 +355,6 @@ Supersedes: 169 AuthLen [2 octets] Authentication [AuthLen octets] - Servers MUST ignore extra bytes at the end of an AUTHENTICATE cell. If AuthType is 1 (meaning "RSA-SHA256-TLSSecret"), then the Authentication contains the following: @@ -369,15 +371,15 @@ Supersedes: 169 VERSIONS cell and the CERT cell. [32 octets] SCERT: A SHA256 hash of the server's TLS link certificate. [32 octets] - TLSSECRETS: Either 32 zero octets, or a SHA256 HMAC, using - the TLS master secret as the secret key, of the following: + TLSSECRETS: A SHA256 HMAC, using the TLS master secret as the + secret key, of the following: - client_random, as sent in the TLS Client Hello - server_random, as sent in the TLS Server Hello - the NUL terminated ASCII string: "Tor V3 handshake TLS cross-certification" [32 octets] TIME: The time of day in seconds since the POSIX epoch. [8 octets] - NONCE: A 16 byte value, randomly chosen by the client [16 octets] + RAND: A 16 byte value, randomly chosen by the client [16 octets] SIG: A signature of a SHA256 hash of all the previous fields using the client's "Authenticate" key as presented. (As always in Tor, we use OAEP-MGF1 padding; see tor-spec.txt @@ -386,19 +388,16 @@ Supersedes: 169 To check the AUTHENTICATE cell, a server checks that all fields containing a hash contain the correct value, then verifies the - signature. The server MUST ignore any extra bytes after - the SHA256 hash. - - When possible (that is, when implemented using C TLS API), - implementations SHOULD include and verify the TLSSECRETS field. + signature. The server MUST ignore any extra bytes in the signed + data after the SHA256 hash. 3.5. Responding to extra cells, and other security checks. - If the handshake is a V3+ TLS handshake, both parties MUST reject + If the handshake is a V3 TLS handshake, both parties MUST reject any negotiated link version less than 3. Both parties MUST check this and close the connection if it is violated. - If the handshake is not a V3+ TLS handshake, both parties MUST + If the handshake is not a V3 TLS handshake, both parties MUST still advertise all link protocols they support in their versions cell. Both parties MUST close the link if it turns out they both would have supported version 3 or higher, but they somehow wound @@ -613,7 +612,7 @@ Supersedes: 169 - Can we give some way for clients to signal "I want to use the V3 protocol if possible, but I can't renegotiate, so don't give me the V2"? Clients currently have a fair idea of server - versions, so they could potentially do the V3+ handshake with + versions, so they could potentially do the V3 handshake with servers that support it, and fall back to V1 otherwise. - What should servers that don't have TLS renegotiation do? For

1 0

r25093: {projects} add the new bwauth. (projects/misc-sysadmin)
by Andrew Lewman 21 Sep '11

21 Sep '11

Author: phobos Date: 2011-09-21 17:23:59 +0000 (Wed, 21 Sep 2011) New Revision: 25093 Modified: projects/misc-sysadmin/namelist Log: add the new bwauth. Modified: projects/misc-sysadmin/namelist =================================================================== --- projects/misc-sysadmin/namelist 2011-09-21 08:03:48 UTC (rev 25092) +++ projects/misc-sysadmin/namelist 2011-09-21 17:23:59 UTC (rev 25093) @@ -43,3 +43,4 @@ tui - 38.229.70.48 - 48GB - build server tui-ipmi - 38.229.70.50 - - mgt card tui - 2620:0:6b0:b:225:90ff:fe0e:30fb +sewerzowi - 74.95.122.147 - 4GB - bwauth

1 0

[arm/master] fix: tor process detection limited to our user
by atagar＠torproject.org 21 Sep '11

21 Sep '11

commit 795f5a061f2960cbb0659a6e5f796423e7873187 Author: Damian Johnson <atagar(a)torproject.org> Date: Wed Sep 21 09:01:12 2011 -0700 fix: tor process detection limited to our user When checking to see if a tor process is already running I forgot the '-A' flag for ps, limiting the check to our user. --- src/util/torTools.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/util/torTools.py b/src/util/torTools.py index f6d9d86..8c7a1ed 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -352,7 +352,7 @@ def isTorRunning(): """ # suggestions welcome for making this more reliable - commandResults = sysTools.call("ps co command") + commandResults = sysTools.call("ps -A co command") if commandResults: for cmd in commandResults: if cmd.strip() == "tor": return True

1 0

[arm/master] fix: using all controller authentication methods
by atagar＠torproject.org 21 Sep '11

21 Sep '11

commit 8070fd004acde588f4d56d75bf6aa2c3f4d61b77 Author: Damian Johnson <atagar(a)torproject.org> Date: Wed Sep 21 09:33:28 2011 -0700 fix: using all controller authentication methods This is a hacked up version of the fix for https://trac.torproject.org/projects/tor/ticket/3958 It's a bit of a Frankenstein and will be removed when the TorCtl fix is merged. --- src/starter.py | 9 ++- src/util/torTools.py | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 186 insertions(+), 4 deletions(-) diff --git a/src/starter.py b/src/starter.py index dd5f5c9..4315f06 100644 --- a/src/starter.py +++ b/src/starter.py @@ -203,15 +203,16 @@ def _torCtlConnect(controlAddr="127.0.0.1", controlPort=9051, passphrase=None, i conn = None try: - conn, authType, authValue = TorCtl.TorCtl.preauth_connect(controlAddr, controlPort) + #conn, authType, authValue = TorCtl.TorCtl.preauth_connect(controlAddr, controlPort) + conn, authTypes, authValue = util.torTools.preauth_connect_alt(controlAddr, controlPort) - if authType == TorCtl.TorCtl.AUTH_TYPE.PASSWORD: + if TorCtl.TorCtl.AUTH_TYPE.PASSWORD in authTypes: # password authentication, promting for the password if it wasn't provided if passphrase: authValue = passphrase else: try: authValue = getpass.getpass("Controller password: ") except KeyboardInterrupt: return None - elif authType == TorCtl.TorCtl.AUTH_TYPE.COOKIE and authValue[0] != "/": + elif TorCtl.TorCtl.AUTH_TYPE.COOKIE in authTypes and authValue[0] != "/": # Connecting to the control port will probably fail if it's using cookie # authentication and the cookie path is relative (unfortunately this is # the case for TBB). This is discussed in: @@ -226,7 +227,7 @@ def _torCtlConnect(controlAddr="127.0.0.1", controlPort=9051, passphrase=None, i except IOError: pass # appends the path prefix if it's set - if authType == TorCtl.TorCtl.AUTH_TYPE.COOKIE: + if TorCtl.TorCtl.AUTH_TYPE.COOKIE in authTypes: pathPrefix = util.torTools.getConn().getPathPrefix() # The os.path.join function is kinda stupid. If given an absolute path diff --git a/src/util/torTools.py b/src/util/torTools.py index 8c7a1ed..e59b35e 100644 --- a/src/util/torTools.py +++ b/src/util/torTools.py @@ -359,6 +359,187 @@ def isTorRunning(): return False +# ============================================================ +# TODO: Remove when TorCtl can handle multiple auth methods +# https://trac.torproject.org/projects/tor/ticket/3958 +# +# The following is a hacked up version of the fix in that ticket. +# ============================================================ + +class FixedConnection(TorCtl.Connection): + def __init__(self, sock): + TorCtl.Connection.__init__(self, sock) + self._authTypes = [] + + def get_auth_types(self): + """ + Provides the list of authentication types used for the control port. Each + are members of the AUTH_TYPE enumeration and return results will always + have at least one result. This raises an IOError if the query to + PROTOCOLINFO fails. + """ + + if not self._authTypes: + # check PROTOCOLINFO for authentication type + try: + authInfo = self.sendAndRecv("PROTOCOLINFO\r\n")[1][1] + except Exception, exc: + if exc.message: excMsg = ": %s" % exc + else: excMsg = "" + raise IOError("Unable to query PROTOCOLINFO for the authentication type%s" % excMsg) + + # parses the METHODS and COOKIEFILE entries for details we need to + # authenticate + + authTypes, cookiePath = [], None + + for entry in authInfo.split(): + if entry.startswith("METHODS="): + # Comma separated list of our authentication types. If we have + # multiple then any of them will work. + + methodsEntry = entry[8:] + + for authEntry in methodsEntry.split(","): + if authEntry == "NULL": + authTypes.append(TorCtl.AUTH_TYPE.NONE) + elif authEntry == "HASHEDPASSWORD": + authTypes.append(TorCtl.AUTH_TYPE.PASSWORD) + elif authEntry == "COOKIE": + authTypes.append(TorCtl.AUTH_TYPE.COOKIE) + else: + # not of a recognized authentication type (new addition to the + # control-spec?) + + raise IOError("Unrecognized authentication type: %s" % authEntry) + elif entry.startswith("COOKIEFILE=\"") and entry.endswith("\""): + # Quoted path of the authentication cookie. This only exists if we're + # using cookie auth and, of course, doesn't account for chroot. + + cookiePath = entry[12:-1] + + # There should always be a AUTH METHODS entry. If we didn't then throw a + # wobbly. + + if not authTypes: + raise IOError("PROTOCOLINFO response didn't include any authentication methods") + + self._authType = authTypes[0] + self._authTypes = authTypes + self._cookiePath = cookiePath + + return list(self._authTypes) + + def authenticate(self, secret=""): + """ + Authenticates to the control port. If an issue arises this raises either of + the following: + - IOError for failures in reading an authentication cookie or querying + PROTOCOLINFO. + - TorCtl.ErrorReply for authentication failures or if the secret is + undefined when using password authentication + """ + + # fetches authentication type and cookie path if still unloaded + if not self._authTypes: self.get_auth_types() + + # validates input + if TorCtl.AUTH_TYPE.PASSWORD in self._authTypes and secret == "": + raise TorCtl.ErrorReply("Unable to authenticate: no passphrase provided") + + # tries each of our authentication methods, throwing the last exception if + # they all fail + + raisedExc = None + for authMethod in self._authTypes: + authCookie = None + try: + if authMethod == TorCtl.AUTH_TYPE.NONE: + self.authenticate_password("") + elif authMethod == TorCtl.AUTH_TYPE.PASSWORD: + self.authenticate_password(secret) + else: + authCookie = open(self._cookiePath, "r") + self.authenticate_cookie(authCookie) + authCookie.close() + + # Did the above raise an exception? No? Cool, we're done. + return + except TorCtl.ErrorReply, exc: + if authCookie: authCookie.close() + issue = str(exc) + + # simplifies message if the wrong credentials were provided (common + # mistake) + if issue.startswith("515 Authentication failed: "): + if issue[27:].startswith("Password did not match"): + issue = "password incorrect" + elif issue[27:] == "Wrong length on authentication cookie.": + issue = "cookie value incorrect" + + raisedExc = TorCtl.ErrorReply("Unable to authenticate: %s" % issue) + except IOError, exc: + if authCookie: authCookie.close() + issue = None + + # cleaner message for common errors + if str(exc).startswith("[Errno 13] Permission denied"): + issue = "permission denied" + elif str(exc).startswith("[Errno 2] No such file or directory"): + issue = "file doesn't exist" + + # if problem's recognized give concise message, otherwise print exception + # string + if issue: raisedExc = IOError("Failed to read authentication cookie (%s): %s" % (issue, self._cookiePath)) + else: raisedExc = IOError("Failed to read authentication cookie: %s" % exc) + + # if we got to this point then we failed to authenticate and should have a + # raisedExc + + if raisedExc: raise raisedExc + +def preauth_connect_alt(controlAddr="127.0.0.1", controlPort=9051, + ConnClass=FixedConnection): + """ + Provides an uninitiated torctl connection components for the control port, + returning a tuple of the form... + (torctl connection, authTypes, authValue) + + The authValue corresponds to the cookie path if using an authentication + cookie, otherwise this is the empty string. This raises an IOError in case + of failure. + + Arguments: + controlAddr - ip address belonging to the controller + controlPort - port belonging to the controller + ConnClass - connection type to instantiate + """ + + conn = None + try: + s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) + s.connect((controlAddr, controlPort)) + conn = ConnClass(s) + authTypes, authValue = conn.get_auth_types(), "" + + if TorCtl.AUTH_TYPE.COOKIE in authTypes: + authValue = conn.get_auth_cookie_path() + + return (conn, authTypes, authValue) + except socket.error, exc: + if conn: conn.close() + + if "Connection refused" in exc.args: + # most common case - tor control port isn't available + raise IOError("Connection refused. Is the ControlPort enabled?") + + raise IOError("Failed to establish socket: %s" % exc) + except Exception, exc: + if conn: conn.close() + raise IOError(exc) + +# ============================================================ + def getConn(): """ Singleton constructor for a Controller. Be aware that this starts as being

1 0

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