- tor-commits - lists.torproject.org

[stem/master] Implementing general authentication
by atagar＠torproject.org 19 Dec '11

19 Dec '11

commit def66d45d3cf4c82786fa9a8526a18839fcbf816 Author: Damian Johnson <atagar(a)torproject.org> Date: Sun Dec 18 17:25:46 2011 -0800 Implementing general authentication Finally finished the fabled general authentication function, which uses PROTOCOLINFO information for authentication. The vast majority of the effort behind this function was getting the exception hierarchy right. This is totally untested. Unit and integ testing comes next. --- stem/connection.py | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 214 insertions(+), 2 deletions(-) diff --git a/stem/connection.py b/stem/connection.py index e9bd5f7..ddfed89 100644 --- a/stem/connection.py +++ b/stem/connection.py @@ -3,7 +3,10 @@ Functions for connecting and authenticating to the tor process. AuthenticationFailure - Base exception raised for authentication failures. |- UnrecognizedAuthMethods - Authentication methods are unsupported. - |- OpenAuthRejected - Tor rejected this method of authentication. + |- IncorrectSocketType - Socket does not speak the tor control protocol. + | + |- OpenAuthFailed - Failure when authenticating by an open socket. + | +- OpenAuthRejected - Tor rejected this method of authentication. | |- PasswordAuthFailed - Failure when authenticating by a password. | |- PasswordAuthRejected - Tor rejected this method of authentication. @@ -77,8 +80,18 @@ class AuthenticationFailure(Exception): class UnrecognizedAuthMethods(AuthenticationFailure): "All methods for authenticating aren't recognized." + + def __init__(self, message, unknown_auth_methods): + AuthenticationFailure.__init__(self, message) + self.unknown_auth_methods = unknown_auth_methods + +class IncorrectSocketType(AuthenticationFailure): + "Socket does not speak the control protocol." -class OpenAuthRejected(AuthenticationFailure): +class OpenAuthFailed(AuthenticationFailure): + "Failure to authenticate to an open socket." + +class OpenAuthRejected(OpenAuthFailed): "Attempt to connect to an open control socket was rejected." class PasswordAuthFailed(AuthenticationFailure): @@ -120,6 +133,205 @@ class NoAuthMethods(MissingAuthInfo): class NoAuthCookie(MissingAuthInfo): "PROTOCOLINFO response supports cookie auth but doesn't have its path." +# authentication exceptions ordered as per the authenticate function's pydocs +AUTHENTICATE_EXCEPTIONS = ( + IncorrectSocketType, + UnrecognizedAuthMethods, + MissingPassword, + IncorrectPassword, + IncorrectCookieSize, + UnreadableCookieFile, + IncorrectCookieValue, + OpenAuthRejected, + MissingAuthInfo, + AuthenticationFailure, +) + +def authenticate(control_socket, password = None, protocolinfo_response = None): + """ + Authenticates to a control socket using the information provided by a + PROTOCOLINFO response. In practice this will often be all we need to + authenticate, raising an exception if all attempts to authenticate fail. + + All exceptions are subclasses of AuthenticationFailure so, in practice, + callers should catch the types of authentication failure that they care + about, then have a AuthenticationFailure catch-all at the end. For example... + + import sys + import getpass + import stem.connection + import stem.socket + + try: + control_socket = stem.socket.ControlPort(control_port = 9051) + except stem.socket.SocketError, exc: + print "Unable to connect to port 9051 (%s)" % exc + sys.exit(1) + + try: + stem.connection.authenticate(control_socket) + except stem.connection.IncorrectSocketType: + print "Please check in your torrc that 9051 is the ControlPort." + print "Maybe you configured it to be the ORPort or SocksPort instead?" + sys.exit(1) + except stem.connection.MissingPassword: + controller_password = getpass.getpass("Controller password: ") + + try: + stem.connection.authenticate_password(control_socket, controller_password) + except stem.connection.PasswordAuthFailed: + print "Unable to authenticate, password is incorrect" + sys.exit(1) + except stem.connection.AuthenticationFailure, exc: + print "Unable to authenticate: %s" % exc + sys.exit(1) + + Arguments: + control_socket (stem.socket.ControlSocket) - socket to be authenticated + password (str) - passphrase to present to the socket if it uses password + authentication (skips password auth if None) + protocolinfo_response (stem.connection.ProtocolInfoResponse) - + tor protocolinfo response, this is retrieved on our own if None + + Raises: + AuthenticationFailed subclass if all attempts to authenticate fail. Since + this may try multiple authentication methods it may encounter multiple + exceptions. If so then the exception this raises is prioritized as + follows... + + stem.connection.IncorrectSocketType + The control_socket does not speak the tor control protocol. Most often + this happened because the user confused the SocksPort or ORPort with the + ControlPort. + + stem.connection.UnrecognizedAuthMethods + All of the authentication methods tor will accept are new and + unrecognized. Please upgrade stem and, if that doesn't work, file a + ticket on 'trac.torproject.org' and I'd be happy to add support. + + stem.connection.MissingPassword + We were unable to authenticate but didn't attempt password authentication + because none was provided. You should prompt the user for a password and + try again via 'authenticate_password'. + + stem.connection.IncorrectPassword + We were provided with a password but it was incorrect. + + stem.connection.IncorrectCookieSize + Tor allows for authentication by reading it a cookie file, but that file + is the wrong size to be an authentication cookie. + + stem.connection.UnreadableCookieFile + Tor allows for authentication by reading it a cookie file, but we can't + read that file (probaby due to permissions). + + stem.connection.IncorrectCookieValue (*) + Tor allows for authentication by reading it a cookie file, but rejected + the contents of that file. + + stem.connection.OpenAuthRejected (*) + Tor says that it allows for authentication without any credentials, but + then rejected our authentication attempt. + + stem.connection.MissingAuthInfo (*) + Tor provided us with a PROTOCOLINFO reply that is technically valid, but + missing the information we need to authenticate. + + stem.connection.AuthenticationFailure (*) + There are numerous other ways that authentication could have failed + including socket failures, malformed controller responses, etc. These + mostly constitute transient failures or bugs. + + * In practice it is highly unusual for this to occure, being more of a + theoretical possability rather than something you should expect. It's + fine to treat these as errors. If you have a use case where this commonly + happens, please file a ticket on 'trac.torproject.org'. + + In the future new AuthenticationFailure subclasses may be added to allow + for better error handling. + """ + + if not protocolinfo_response: + try: + protocolinfo_response = get_protocolinfo(control_socket) + except stem.socket.ProtocolError: + raise IncorrectSocketType("unable to use the control socket") + except stem.socket.SocketError, exc: + raise AuthenticationFailure("socket connection failed (%s)" % exc) + + auth_methods = list(protocolinfo_response.auth_methods) + auth_exceptions = [] + + if len(auth_methods) == 0: + raise NoAuthMethods("our PROTOCOLINFO response did not have any methods for authenticating") + + # remove authentication methods that are either unknown or for which we don't + # have an input + if AuthMethod.UNKNOWN in auth_methods: + auth_methods.remove(AuthMethod.UNKNOWN) + + unknown_methods = protocolinfo_response.unknown_auth_methods + plural_label = "s" if len(unknown_methods) > 1 else "" + methods_label = ", ".join(unknown_methods) + + # we... er, can't do anything with only unrecognized auth types + if not auth_methods: + exc_msg = "unrecognized authentication method%s (%s)" % (plural_label, methods_label) + auth_exceptions.append(UnrecognizedAuthMethods(exc_msg, unknown_methods)) + else: + LOGGER.debug("Authenticating to a socket with unrecognized auth method%s, ignoring them: %s" % (plural_label, methods_label)) + + if AuthMethod.COOKIE in auth_methods and protocolinfo_response.cookie_path == None: + auth_methods.remove(AuthMethod.COOKIE) + auth_exceptions.append(NoAuthCookie("our PROTOCOLINFO reponse did not have the location of our authentication cookie")) + + if AuthMethod.PASSWORD in auth_methods and password == None: + auth_methods.remove(AuthMethod.PASSWORD) + auth_exceptions.append(MissingPassword("no passphrase provided")) + + # iterating over AuthMethods so we can try them in this order + for auth_type in (AuthMethod.NONE, AuthMethod.PASSWORD, AuthMethod.COOKIE): + if not auth_type in auth_methods: continue + + try: + if auth_type == AuthMethod.NONE: + authenticate_none(control_socket, False) + elif auth_type == AuthMethod.PASSWORD: + authenticate_password(control_socket, password, False) + elif auth_type == AuthMethod.COOKIE: + authenticate_cookie(control_socket, protocolinfo_response.cookie_path, False) + + return # success! + except OpenAuthRejected, exc: + auth_exceptions.append(exc) + except IncorrectPassword, exc: + auth_exceptions.append(exc) + except PasswordAuthRejected, exc: + # Since the PROTOCOLINFO says password auth is available we can assume + # that if PasswordAuthRejected is raised it's being raised in error. + LOGGER.debug("The authenticate_password method raised a PasswordAuthRejected when password auth should be available. Stem may need to be corrected to recognize this response: %s" % exc) + auth_exceptions.append(IncorrectPassword(str(exc))) + except (IncorrectCookieSize, UnreadableCookieFile, IncorrectCookieValue), exc: + auth_exceptions.append(exc) + except CookieAuthRejected, exc: + LOGGER.debug("The authenticate_cookie method raised a CookieAuthRejected when cookie auth should be available. Stem may need to be corrected to recognize this response: %s" % exc) + auth_exceptions.append(IncorrectCookieValue(str(exc))) + except stem.socket.ControllerError, exc: + auth_exceptions.append(AuthenticationFailure(str(exc))) + + # All authentication attempts failed. Raise the exception that takes priority + # according to our pydocs. + + for exc_type in AUTHENTICATE_EXCEPTIONS: + for auth_exc in auth_exceptions: + if isinstance(auth_exc, exc_type): + raise auth_exc + + # We really, really shouldn't get here. It means that auth_exceptions is + # either empty or contains something that isn't an AuthenticationFailure. + + raise AssertionError("BUG: Authenticaion failed without providing a recognized exception: %s" % str(auth_exceptions)) + def authenticate_none(control_socket, suppress_ctl_errors = True): """ Authenticates to an open control socket. All control connections need to

1 0

[arm/master] fix: getProcessName should return the base name
by atagar＠torproject.org 18 Dec '11

18 Dec '11

commit 3f71b5115476a27d6fc58260a6a72125a6a92297 Author: Damian Johnson <atagar(a)torproject.org> Date: Sun Dec 18 14:38:10 2011 -0800 fix: getProcessName should return the base name When the proc query failed the fallback ps command would return the command's full path rather than just the base name. This in turn would make lookups that use this value (like netstat) fail. Caught by Stephan Seitz. --- src/util/sysTools.py | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/util/sysTools.py b/src/util/sysTools.py index 4bb0667..1c84462 100644 --- a/src/util/sysTools.py +++ b/src/util/sysTools.py @@ -152,6 +152,7 @@ def getProcessName(pid, default = None, cacheFailure = True): return default else: + processName = os.path.basename(processName) PROCESS_NAME_CACHE[pid] = processName return processName

1 0

[arm/master] fix: disabling localization for system commands
by atagar＠torproject.org 18 Dec '11

18 Dec '11

commit 31800f4018275d83c2f7db8f725b1fca1ee97360 Author: Damian Johnson <atagar(a)torproject.org> Date: Sun Dec 18 14:35:49 2011 -0800 fix: disabling localization for system commands Setting LANG to C to disable localization for subcommands like netstat. This is important since we use words in it (like ESTABLISHED) to filter the results. Caught by Stephan Seitz. --- src/starter.py | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/src/starter.py b/src/starter.py index 3d74315..40c23f7 100644 --- a/src/starter.py +++ b/src/starter.py @@ -103,6 +103,11 @@ PRIVATE_TORRC_ENTRIES = ["HashedControlPassword", "Bridge", "HiddenServiceDir"] TOR_ROOT_NOTICE = "Tor is currently running with root permissions. This is not a good idea and shouldn't be necessary. See the 'User UID' option from Tor's man page for an easy method of reducing its permissions after startup." ARM_ROOT_NOTICE = "Arm is currently running with root permissions. This is not a good idea, and will still work perfectly well if it's run with the same user as Tor (ie, starting with \"sudo -u %s arm\")." +# Makes subcommands provide us with English results (this is important so we +# can properly parse it). + +os.putenv("LANG", "C") + def allowConnectionTypes(): """ This provides a tuple with booleans indicating if we should or shouldn't

1 0

r25264: {website} Update website for Torbutton 1.4.5.1. (in website/trunk: include torbutton)
by Mike Perry 18 Dec '11

18 Dec '11

Author: mikeperry Date: 2011-12-18 00:42:03 +0000 (Sun, 18 Dec 2011) New Revision: 25264 Modified: website/trunk/include/versions.wmi website/trunk/torbutton/update.rdf Log: Update website for Torbutton 1.4.5.1. Modified: website/trunk/include/versions.wmi =================================================================== --- website/trunk/include/versions.wmi 2011-12-17 04:41:37 UTC (rev 25263) +++ website/trunk/include/versions.wmi 2011-12-18 00:42:03 UTC (rev 25264) @@ -102,8 +102,8 @@ <define-tag file-source-alpha whitespace=delete>tor-<version-alpha>.tar.gz</define-tag> <define-tag package-source-alpha whitespace=delete>../dist/<file-source-alpha></define-tag> -<define-tag version-torbutton whitespace=delete>1.4.5 (14 Oct 2011)</define-tag> -<define-tag version-hash-torbutton whitespace=delete>sha1:5f2e2d72343b2d4702ec24491a11babedd3650b9</define-tag> +<define-tag version-torbutton whitespace=delete>1.4.5.1 (17 Dec 2011)</define-tag> +<define-tag version-hash-torbutton whitespace=delete>sha1:0002e2d61613504e41d8b773c30ff6307b8286da</define-tag> <define-tag version-torbutton-alpha whitespace=delete>None</define-tag> <define-tag version-hash-torbutton-alpha whitespace=delete>sha1:c7323cd408ebee28ee23b6a91fe056d59de668f5</define-tag> Modified: website/trunk/torbutton/update.rdf =================================================================== (Binary files differ)

1 0

[torbutton/master] Update version + changelog.
by mikeperry＠torproject.org 18 Dec '11

18 Dec '11

commit c309f832b52b3808809bc722beb08c541263f5e8 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sat Dec 17 16:35:47 2011 -0800 Update version + changelog. --- README.RELEASE | 2 +- src/CHANGELOG | 4 ++++ src/install.rdf | 2 +- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/README.RELEASE b/README.RELEASE index 83f238b..f386760 100644 --- a/README.RELEASE +++ b/README.RELEASE @@ -5,7 +5,7 @@ #. Decide the version number. - export VERSION="1.4.5" + export VERSION="1.4.5.1" vim ./src/install.rdf # edit <em:version> tag to reflect version #. Test upgrades of candidate XPI in latest Firefox and TBB product matrix diff --git a/src/CHANGELOG b/src/CHANGELOG index d492635..4c049ae 100644 --- a/src/CHANGELOG +++ b/src/CHANGELOG @@ -1,3 +1,7 @@ +1.4.5.1 + 17 Dec 2011 + * bug 4722: Fix ability to drag tabs on Windows (due to #4517) + 1.4.5 14 Dec 2011 * bug 4517: Disable external drag and drop (prevents proxy bypass) diff --git a/src/install.rdf b/src/install.rdf index 2067f72..371d353 100644 --- a/src/install.rdf +++ b/src/install.rdf @@ -6,7 +6,7 @@ <em:name>Torbutton</em:name> <em:creator>Mike Perry & Kory Kirk</em:creator> <em:id>{e0204bd5-9d31-402b-a99d-a6aa8ffebdca}</em:id> - <em:version>1.4.5</em:version> + <em:version>1.4.5.1</em:version> <em:homepageURL>https://www.torproject.org/torbutton/</em:homepageURL> <em:optionsURL>chrome://torbutton/content/preferences.xul</em:optionsURL> <em:iconURL>chrome://torbutton/skin/tor.png</em:iconURL>

1 0

[torbutton/master] Bug 4722: Fix ability to drag tabs on Windows due to #4517 fix.
by mikeperry＠torproject.org 18 Dec '11

18 Dec '11

commit 54896d07d5afeb1c2b0d53840b65d677d94d747a Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sat Dec 17 16:31:41 2011 -0800 Bug 4722: Fix ability to drag tabs on Windows due to #4517 fix. Does not cause regressions for Ubuntu Unity. --- src/components/external-app-blocker.js | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/src/components/external-app-blocker.js b/src/components/external-app-blocker.js index ff81cad..34447cd 100644 --- a/src/components/external-app-blocker.js +++ b/src/components/external-app-blocker.js @@ -225,8 +225,6 @@ ExternalWrapper.prototype = // from nsIDragService invokeDragSessionWithImage: function(aDOMNode, aTransferableArray, aRegion, aActionType, aImage, aImageX, aImageY, aDragEvent, aDataTransfer) { - aActionType = 0; - for(var i = 0; i < aTransferableArray.Count(); i++) { this.logger.log(3, "Inspecting drag+drop transfer: "+i); var tr = aTransferableArray.GetElementAt(i);

1 0

[obfsproxy/master] Merge remote-tracking branch 'asn/bug4558'
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit d589ba698796a44188bfbb5c8768adcf3c32fcf8 Merge: d3afe74 2a65bc2 Author: Nick Mathewson <nickm(a)torproject.org> Date: Sat Dec 17 13:17:14 2011 -0500 Merge remote-tracking branch 'asn/bug4558' doc/obfsproxy_architecture.txt | 186 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 186 insertions(+), 0 deletions(-)

1 0

[obfsproxy/master] Add obfsproxy architecture draft.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 2a65bc2ac1a6257351291afc86fb95fd8bc1e480 Author: George Kadianakis <desnacked(a)gmail.com> Date: Tue Dec 13 14:44:11 2011 +0100 Add obfsproxy architecture draft. --- doc/obfsproxy_architecture.txt | 186 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 186 insertions(+), 0 deletions(-) diff --git a/doc/obfsproxy_architecture.txt b/doc/obfsproxy_architecture.txt new file mode 100644 index 0000000..05ee5eb --- /dev/null +++ b/doc/obfsproxy_architecture.txt @@ -0,0 +1,186 @@ +architecture + + : Top Level View + +obfsproxy is a pluggable transports proxy written in C. It's compliant +to the pluggable transports specification [0], and its modular +architecture allows it to support multiple pluggable transports. + +# It supports two modes of operation, the 'external proxy' mode and the +# 'managed proxy' mode. When used as an 'external proxy', the user +# configures obfsproxy using the command-line. When used as a 'managed +# proxy', obfsproxy can be configured by another application using the +# managed proxy configuration protocol defined in the pluggable +# transports specification [0]. + + : Modularity + +obfsproxy uses callbacks and object-oriented programming principles to +achieve modularity. This way, a developer who is interested in writing +a pluggable transport doesn't need to know obfsproxy's code inside +out. + +- Callbacks + + obfsproxy provides a set of callbacks that the plugin writer can use + to execute his transport's code, in an event-driven programming + fashion. + + As a basic example, there is a callback triggering when obfsproxy + receives network data. The plugin writer uses that callback to + retrieve and process data according to his pluggable transport + protocol. + +- OOP + + obfsproxy provides a set of base classes, representing networking + concepts, that the developer can inherit and populate with his + transport's data. + + As an example, the 'conn_t' structure represents a bidirectional + network connection between two peers. The pluggable transport writer + can inherit 'conn_t' and save his transport's state for that + connection to the new struct. + +Developers that make good use of obfsproxy's callbacks and OOP, should +be able to implement most pluggable transports. + + : Codebase tour + +This section does a short introduction into some areas of obfsproxy's +code. + +- Networking subsystem + +This section explains the networking concepts and terminology of +obfsproxy. The relevant code can be found in src/network.c. + +A 'connection' is a bidirectional communications channel, usually +backed by a network socket. For example, the communication channel +between tor and obfsproxy is a 'connection'. + +A 'circuit' is a pair of connections, referred to as the 'upstream' +and 'downstream' connections. The upstream connection of a circuit +communicates in cleartext with the higher-level program that wishes to +make use of our obfuscation service. The downstream connection +commmunicates in an obfuscated fashion with the remote peer that the +higher-level client wishes to contact. + +The diagram below might help demonstrate the relationship between +connections and circuits: + + downstream + + 'circuit_t C' 'conn_t CD' 'conn_t SD' 'circuit_t S' + +-----------+ +-----------+ + upstream ----|obfsproxy c|-------------|obfsproxy s|---- upstream + | +-----------+ +-----------+ | + 'conn_t CU'| |'conn_t SU' + +------------+ +--------------+ + | Tor Client | | Tor Bridge | + +------------+ +--------------+ + +In the above diagram, "obfsproxy c" is the client-side obfsproxy, and +"obfsproxy s" is the server-side obfsproxy. "conn_t CU" is the +Client's Upstream connection, the communication channel between tor +and obfsproxy. "conn_t CD" is the Client's Downstream connection, the +communication channel between obfsproxy and the remote peer. These two +connections form "circuit_t C". + +A 'listener' is a listening socket bound to a particular obfuscation +protocol. Connecting to a listener creates one connection of a +circuit, and causes this program to initiate the other connection +(possibly after receiving in-band instructions about where to connect +to). A listener is said to be a 'client' listener if connecting to it +creates the upstream connection, and a 'server' listener if connecting +to it creates the downstream connection. + +There are two kinds of client listeners: a 'simple' client listener +always connects to the same remote peer every time it needs to +initiate a downstream connection; a 'socks' client listener can be +told to connect to an arbitrary remote peer using the SOCKS protocol +(version 4 or 5). + +- Protocol subsystem + +Pluggable transports are called 'protocols' in obfsproxy +code. Protocol-specific code can be found in src/protocols/. + +src/protocol.c acts as an intermediary between generic obfsproxy code +and protocol-specific code. It wraps protocol-specific functions for +use by the rest of obfsproxy, and provides various protocol-related +functions. + +All supported protocols are registered to obfsproxy by adding them to +the supported_protocols[] array in src/protocol.c. + +- Cryptography subsystem + +The primary goal of pluggable transports is to obfuscate network +traffic. This means that most transports will need to use +cryptography. + +obfsproxy provides a cryptography subsystem for transports that need +it; the code can be found in src/crypt.c. It supports various +cryptographic operations, like hashing, symmetric encryption and +random-number generation. + + : Extending obfsproxy + +- Adding pluggable transports + +Ideally, this is the only thing you will ever want to add to +obfsproxy: your pluggable transport. A low-level guide on how to add +your own pluggable transport can be found in doc/HACKING. This is a +high level overview: + + * Write your pluggable transport, by writing code for the callback + events in protocol.c:protocol_vtable and by subclassing the base + classes of network.h and protocol.h. Look at doc/HACKING and at the + code of existing transports in src/protocols/. + + * Register your transport to the protocol subsystem by adding it to + the supported_protocols list in src/protocol.c. + + * Add all new files to the Makefile. + +- Extending callbacks + +obfsproxy's modularity is based on callbacks, and even though the +defaults should satisfy the needs of many plugin writers, it's +possible that some plugin writers will need to extend obfsproxy to +write their own callbacks. + +As an example, think of a plugin that needs to send fake data in the +absense of network activity: the current obfsproxy doesn't have a +callback for this scenario. The plugin writer would have to dive into +the networking subsystem of obfsproxy, write the callback triggering +code, register the new callback and finally write the code that +executes when the callback triggers. + +Depending on the scenario's complexity this might be a difficult task, +but there is not much that obfsproxy can do, since it's not possible +to have callbacks for any potentially useful scenario. + +- Extending crypto + +The current cryptography subsystem is made to order for the current +transports, and might not be sufficient for all transports. If a +transport needs more crypto, the plugin writer can add his own +cryptography functions to src/crypt.c. + +- Extending architecture logic + +obfsproxy tries to keep obfsproxy code and protocol-specific code as +disconnected as possible. This means that protocol-specific code +should know as little as possible about generic code internals, and +generic code should know nothing about protocol-specific code except +from what's exported through the protocol subsystem (src/protocol.[ch]). + +Plugin writers should not use their protocol-specific functions in +generic code, and should find a way to complete their task in the most +protocol-agnostic way possible. This helps keep both parts of the code +clean. + +[0]: +https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/180-pluggable-transport.txt

1 0

[obfsproxy/master] Replace old threat model doc. with a new one.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit d3afe7490775312101ede5879a8ebb75f995f59b Author: George Kadianakis <desnacked(a)gmail.com> Date: Tue Dec 13 14:39:22 2011 +0100 Replace old threat model doc. with a new one. --- doc/THREAT_MODEL | 19 ---------------- doc/obfs2_threat_model.txt | 50 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 19 deletions(-) diff --git a/doc/THREAT_MODEL b/doc/THREAT_MODEL deleted file mode 100644 index d973317..0000000 --- a/doc/THREAT_MODEL +++ /dev/null @@ -1,19 +0,0 @@ -obfs2 was created to work on top of the Tor protocol (and specifically -it's TLS handshake phase). Do not use obfs2 to obfuscate other -protocols, unless you are super-sure of what you are doing. - -A list follows, of known attacks that obfs2 protects or does not -protect against. obfs2 does not protect you against unknown attacks. - -Attacks obfs2 protects against: -* Non-intelligent DPI boxes censoring based on TLS content patterns. -* In the case of a shared secret, it also protects against intelligent DPI boxes. - -Attacks obfs2 does not protect against: -* Any distinguisher based on the Tor protocol. This includes timing, packet - size and replay attacks. -* Any distinguisher based on packet entropy. -* In the case of obfs2 without a shared secret, obfs2 does not protect - against an intelligent DPI box; a DPI box that simply deobfuscates - the obfs2 protocol (for those not familiar with the protocol: this - is quite easy.). diff --git a/doc/obfs2_threat_model.txt b/doc/obfs2_threat_model.txt new file mode 100644 index 0000000..08385ae --- /dev/null +++ b/doc/obfs2_threat_model.txt @@ -0,0 +1,50 @@ +threat model: + + Adversary capabilities: + +The adversary controls the infrastructure of the network within her +jurisdiction, and she can potentially monitor, block, alter, and +inject trafﬁc anywhere within this region. + +The censor also holds a blacklist of network protocols, which she is +interested in blocking. + + Adversary attacks: + +The censor passively monitors traffic and looks for content +signatures, in an attempt to distinguish network protocols. Upon +detecting a blacklisted protocol, the censor blocks the connection. + + Goals of obfs2: + +obfs2 attempts to counter the above attack by removing content +signatures from network traffic. obfs2 encrypts the traffic stream +with a stream cipher, which results in the traffic looking uniformly +random. + + Discussion: + +obfs2 shortcomings: + +obfs2 was designed as a pluggable transports proof-of-concept: it is +simple, useable and easily implementable. It does _not_ try to protect +against sophisticated adversaries: + +obfs2 does not try to protect against Tor protocol fingerprints, like +the packet size or packet timing. + +obfs2 does not try to protect against attackers capable of measuring +traffic entropy. + +obfs2 does not try to protect against Deep Packet Inspection machines +that expect the obfs2 protocol. Such machines can trivially retrieve +the decryption key off the traffic stream and use it to decrypt obfs2 +and detect the Tor protocol. + +In other words, obfs2 does not try to protect against anything other +than fingerprintable TLS content patterns. + +That said, obfs2 is not useless. It protects against many real-life +Tor traffic detection methods currentl deployed, since most of them +use static SSL handshake strings as signatures. +

1 0

[tor/master] Doxygenize the file-level documentation of transports.c.
by nickm＠torproject.org 17 Dec '11

17 Dec '11

commit 6d35f08e014cc750239b77e41aa8de9460c615bd Author: George Kadianakis <desnacked(a)gmail.com> Date: Fri Dec 16 11:01:56 2011 +0100 Doxygenize the file-level documentation of transports.c. --- src/or/transports.c | 155 +++++++++++++++++++++++++-------------------------- 1 files changed, 77 insertions(+), 78 deletions(-) diff --git a/src/or/transports.c b/src/or/transports.c index 06bc039..6ee4878 100644 --- a/src/or/transports.c +++ b/src/or/transports.c @@ -4,6 +4,83 @@ /** * \file transports.c * \brief Pluggable Transports related code. + * + * \details + * Each managed proxy is represented by a managed_proxy_t. + * Each managed proxy can support multiple transports. + * Each managed proxy gets configured through a multistep process. + * + * ::managed_proxy_list contains all the managed proxies this tor + * instance is supporting. + * In the ::managed_proxy_list there are ::unconfigured_proxies_n + * managed proxies that are still unconfigured. + * + * In every run_scheduled_event() tick, we attempt to launch and then + * configure the unconfiged managed proxies, using the configuration + * protocol defined in the 180_pluggable_transport.txt proposal. A + * managed proxy might need several ticks to get fully configured. + * + * When a managed proxy is fully configured, we register all its + * transports to the circuitbuild.c subsystem. At that point the + * transports are owned by the circuitbuild.c subsystem. + * + * When a managed proxy fails to follow the 180 configuration + * protocol, it gets marked as broken and gets destroyed. + * + * In a little more detail: + * + * While we are serially parsing torrc, we store all the transports + * that a proxy should spawn in its transports_to_launch + * element. + * + * When we finish reading the torrc, we spawn the managed proxy and + * expect {S,C}METHOD lines from its output. We add transports + * described by METHOD lines to its transports element, as + * transport_t structs. + * + * When the managed proxy stops spitting METHOD lines (signified by a + * '{S,C}METHODS DONE' message) we register all the transports + * collected to the circuitbuild.c subsystem. At this point, the + * pointers to transport_t can be transformed into dangling pointers + * at any point by the circuitbuild.c subsystem, and so we replace all + * transport_t pointers with strings describing the transport names. + * We can still go from a transport name to a transport_t using the + * fact that each transport name uniquely identifies a transport_t. + * + * In even more detail, this is what happens when a SIGHUP + * occurs: + * + * We immediately destroy all unconfigured proxies (We shouldn't have + * unconfigured proxies in the first place, except when SIGHUP rings + * immediately after tor is launched.). + * + * We mark all managed proxies and transports to signify that they + * must be removed if they don't contribute by the new torrc + * (we mark using the marked_for_removal element). + * We also mark all managed proxies to signify that they might need to + * be restarted so that they end up supporting all the transports the + * new torrc wants them to support (using the got_hup element). + * We also clear their transports_to_launch list so that we can + * put there the transports we need to launch according to the new + * torrc. + * + * We then start parsing torrc again. + * + * Everytime we encounter a transport line using a known pre-SIGHUP + * managed proxy, we cleanse that proxy from the removal mark. + * We also mark it as unconfigured so that on the next scheduled + * events tick, we investigate whether we need to restart the proxy + * so that it also spawns the new transports. + * If the post-SIGHUP transports_to_launch list is identical to + * the pre-SIGHUP one, it means that no changes were introduced to + * this proxy during the SIGHUP and no restart has to take place. + * + * During the post-SIGHUP torrc parsing, we unmark all transports + * spawned by managed proxies that we find in our torrc. + * We do that so that if we don't need to restart a managed proxy, we + * can continue using its old transports normally. + * If we end up restarting the proxy, we destroy and unregister all + * old transports from the circuitbuild.c subsystem. **/ #define PT_PRIVATE @@ -64,84 +141,6 @@ static smartlist_t *managed_proxy_list = NULL; /** Number of still unconfigured proxies. */ static int unconfigured_proxies_n = 0; -/** "The main idea is:" - - Each managed proxy is represented by a 'managed_proxy_t'. - Each managed proxy can support multiple transports. - Each managed proxy gets configured through a multistep process. - - 'managed_proxy_list' contains all the managed proxies this tor - instance is supporting. - In the 'managed_proxy_list' there are 'unconfigured_proxies_n' - managed proxies that are still unconfigured. - - In every run_scheduled_event() tick, we attempt to launch and then - configure the unconfiged managed proxies, using the configuration - protocol defined in the 180_pluggable_transport.txt proposal. A - managed proxy might need several ticks to get fully configured. - - When a managed proxy is fully configured, we register all its - transports to the circuitbuild.c subsystem. At that point the - transports are owned by the circuitbuild.c subsystem. - - When a managed proxy fails to follow the 180 configuration - protocol, it gets marked as broken and gets destroyed. - - "In a little more technical detail:" - - While we are serially parsing torrc, we store all the transports - that a proxy should spawn in its 'transports_to_launch' element. - - When we finish reading the torrc, we spawn the managed proxy and - expect {S,C}METHOD lines from its output. We add transports - described by METHOD lines to its 'transports' element, as - 'transport_t' structs. - - When the managed proxy stops spitting METHOD lines (signified by a - '{S,C}METHODS DONE' message) we register all the transports - collected to the circuitbuild.c subsystem. At this point, the - 'transport_t's can be transformed into dangling pointers at any - point by the circuitbuild.c subsystem, and so we replace all - 'transport_t's with strings describing the transport names. We - can still go from a transport name to a 'transport_t' using the - fact that transport names uniquely identify 'transport_t's. - - "In even more technical detail I shall describe what happens when - the SIGHUP bell tolls:" - - We immediately destroy all unconfigured proxies (We shouldn't have - unconfigured proxies in the first place, except when SIGHUP rings - immediately after tor is launched.). - - We mark all managed proxies and transports to signify that they - must be removed if they don't contribute by the new torrc - (marked_for_removal). - We also mark all managed proxies to signify that they might need - to be restarted so that they end up supporting all the transports - the new torrc wants them to support (got_hup). - We also clear their 'transports_to_launch' list so that we can put - there the transports we need to launch according to the new torrc. - - We then start parsing torrc again. - - Everytime we encounter a transport line using a known pre-SIGHUP - managed proxy, we cleanse that proxy from the removal mark. - - We also mark it as unconfigured so that on the next scheduled - events tick, we investigate whether we need to restart the proxy - so that it also spawns the new transports. - If the post-SIGHUP 'transports_to_launch' list is identical to the - pre-SIGHUP one, it means that no changes were introduced to this - proxy during the SIGHUP and no restart has to take place. - - During the post-SIGHUP torrc parsing, we unmark all transports - spawned by managed proxies that we find in our torrc. - We do that so that if we don't need to restart a managed proxy, we - can continue using its old transports normally. - If we end up restarting the proxy, we destroy and unregister all - old transports from the circuitbuild.c subsystem. -*/ - /** Return true if there are still unconfigured managed proxies. */ int pt_proxies_configuration_pending(void)

1 0