tor-dev February 2012

tor-dev@lists.torproject.org

26 participants
24 discussions

Proposal 188: Bridge Guards and other anti-enumeration defenses
by Nick Mathewson 12 Jun '12

12 Jun '12

Filename: 188-bridge-guards.txt Title: Bridge Guards and other anti-enumeration defenses Author: Nick Mathewson Created: 14 Oct 2011 Status: Open 1. Overview Bridges are useful against censors only so long as the adversary cannot easily enumerate their addresses. I propose a design to make it harder for an adversary who controls or observes only a few nodes to enumerate a large number of bridges. Briefly: bridges should choose guard nodes, and use the Tor protocol's "Loose source routing" feature to re-route all extend requests from clients through an additional layer of guard nodes chosen by the bridge. This way, only a bridge's guard nodes can tell that it is a bridge, and the attacker needs to run many more nodes in order to enumerate a large number of bridges. I also discuss other ways to avoid enumeration, recommending some. These ideas are due to a discussion at the 2011 Tor Developers' Meeting in Waterloo, Ontario. Practically none of the ideas here are mine; I'm just writing up what I remember. 2. History and Motivation Under the current bridge design, an attacker who runs a node can identify bridges by seeing which "clients" make a large number of connections to it, or which "clients" make connections to it in the same way clients do. This has been a known attack since early versions {XXXX check} of the design document; let's try to fix it. 2.1. Related ideas: Guard nodes The idea of guard nodes isn't new: since 0.1.1, Tor has used guard nodes (first designed as "Helper" nodes by Wright et al in {XXXX}) to make it harder for an adversary who controls a smaller number of nodes to eavesdrop on clients. The rationale was: an adversary who controls or observes only one entry and one exit will have a low probability of correlating any single circuit, but over time, if clients choose a random entry and exit for each circuit, such an adversary will eventually see some circuits from each client with a probability of 1, thereby building a statistical profile of the client's activities. Therefore, let each client choose its entry node only from among a small number of client-selected "guard" nodes: the client is still correlated with the same probability as before, but now the client has a nonzero chance of remaining unprofiled. 2.2. Related idea: Loose source routing Since the earliest versions of Onion Routing, the protocol has provided "loose source routing". In strict source routing, the source of a message chooses every hop on the message's path. But in loose source routing, the message traverses the selected nodes, but may also traverse other nodes as well. In other words, the client selects nodes N_a, N_b, and N_c, but the message may in fact traverse any sequence of nodes N_1...N_j, so long as N_1=N_a, N_x=N_b, and N_y=N_c, for 1 < x < y. Tor has retained this feature, but has not yet made use of it. 3. Design Every bridge currently chooses a set of guard nodes for its circuits. Bridges should also re-route client circuits through these circuits. Specifically, when a bridge receives a request from a client to extend a circuit, it should first create a circuit to its guard, and then relay that extend cell through the guard. The bridge should add an additional layer of encryption to outgoing cells on that circuit corresponding to the encryption that the guard will remove, and remove a layer of encryption on incoming cells on that circuit corresponding to the encryption that the guard will add. 3.1. An example This example doesn't add anything to the design above, but has some interesting inline notes. - Alice has connected to her bridge Bob, and built a circuit through Bob, with the negotiated forward and reverse keys KB_f and KB_r. - Alice then wants to extend the circuit to node Charlie. She makes a hybrid-encrypted onionskin, encrypted to Charlie's public key, containing her chosen g^x value. She puts this in an extend cell: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". She encrypts this with KB_f and sends it as a RELAY_EARLY cell to Bob. - Bob receives the RELAY_EARLY cell, and decrypts it with KB_f. He then sees that it's an extend cell for him. So far, this is exactly the same as the current procedure that Alice and Bob would follow. Now we diverge: - Instead of connecting to Charlie directly, Bob makes sure that he is connected to his guard, Guillaume. Bob uses a CREATE_FAST cell (or a CREATE cell, but see 4.1 below) to open a circuit to Guillaume. Now Bob and Guillaume share keys KG_f and KG_b. - Now Bob encrypts the Extend cell body with KG_f and sends it as a RELAY_EARLY cell to Guillaume. - Guillaume receives it, decrypts it with KG_f, and sees: "Extend (Charlie's address) (Charlie's OR Port) (Onionskin) (Charlie's ID)". Guillaume acts accordingly: creating a connection to Charlie if he doesn't have one, ensuring that the ID is as expected, and then sending the onionskin in a create cell on that connection. Note that Guillaume is behaving exactly as a regular node would upon receiving an Extend cell. - Now the handshake finishes. Charlie receives the onionskin and sends Guillaume "CREATED g^y,KH". Guillaume sends Bob "E(KG_r, EXTENDED g^y KH)". (Charlie and Guillaume are still running as regular Tor nodes do today). - With this extend cell, and with all future relay cells received on this circuit, Bob first decrypts the cell with KG_r, then re-encrypts it with KB_r, then passes it to Alice. When Alice receives the cell, it will be just as she would have received if Bob had extended to Charlie directly. - With all future outgoing cells that he receives from Alice, Bob first decrypts the cell with KA_f, and if the cell does not have Bob as its destination, Bob encrypts it with KG_f before passing it to Guillaume. Note that this design does not require that our stream cipher operations be transitive, even though they are. Note also that this design requires no change in behavior from any node other than Bob the bridge. Finally, observe that even though the circuit is one hop longer than it would be otherwise, no relay's count of permissible RELAY_EARLY cells falls lower than it otherwise would. This is because the extra hop that Bob adds is done with a CREATE_FAST cell, and so he does not need to send any RELAY_EARLY cells not originated by Alice. 4. Other ideas and alternative designs In addition to the design above, there are more ways to try to prevent enumeration. 4.1. Make it harder to tell clients from bridges Right now, there are multiple ways for the node after a bridge to distinguish a circuit extended through the bridge from one originating at the bridge. (This lets the node after the bridge tell that a bridge is talking to it.) One of the giveaways here is that the first hop in a circuit is created with CREATE_FAST cells, but all subsequent hops are created with CREATE cells. In the above design, it's no longer quite so simple to tell, since all of the circuits that extend through a bridge now reach its guards through CREATE_FAST cells, whether the bridge originated them or not. (If we adopt a faster circuit extension algorithm -- for example, Goldberg, Stebila, and Ustaoglu's design instantiated over curve25519 -- we could also solve this issue by eliminating CREATE_FAST/CREATED_FAST entirely, which would also help our security margin a little.) The CREATE/CREATE_FAST distinction is not the only way for a bridge's guard to tell bridges from orginary clients, however. Most importantly, a busy bridge will open far more circuits than a client would. More subtly, the timing on response from the client will be higher and more highly variable that it would be with an ordinary client. I don't think we can make bridges behave wholly indistinguishably from clients: that's why we should go with guard nodes for bridges. 4.2. Client-enforced bridge guards What if Tor didn't have loose source routing? We could have bridges tell clients what guards to use by advertising those guard in their descriptors, and then refusing to extend circuits to any other nodes. This change would require all clients to upgrade in order to be able to use the newer bridges, and would quite possibly cause a fair amount of pain along the way. Fortunately, we don't need to go down this path. So let's not! 4.3. Separate bridge-guards and client-guards In the design above, I specify that bridges should use the same guard nodes for extending client circuits as they use for their own circuits. It's not immediately clear whether this is a good idea or not. Having separate sets would seem to make the two kinds of circuits more easily distinguishable (even though we already assume they are distinguishable). Having different sets of guards would also seem like a way to keep the nodes who guard our own traffic from learning that we're a bridge... but another set of nodes will learn that anyway, so it's not clear what we'd gain. 5. Other considerations What fraction of our traffic is bridge traffic? Will this alter our circuit selection weights? Are the current guard selection/evaluation/replacement mechanisms adequate for bridge guards, or do bridges need to get more sophisticated?

7 7

Proposal 189: AUTHORIZE and AUTHORIZED cells
by George Kadianakis 12 Jun '12

12 Jun '12

Filename: 189-authorize-cell.txt Title: AUTHORIZE and AUTHORIZED cells Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposal 187 introduced the concept of the AUTHORIZE cell, a cell whose purpose is to make Tor bridges resistant to scanning attacks. This is achieved by having the bridge and the client share a secret out-of-band and then use AUTHORIZE cells to validate that the client indeed knows that secret before proceeding with the Tor protocol. This proposal specifies the format of the AUTHORIZE cell and also introduces the AUTHORIZED cell, a way for bridges to announce to clients that the authorization process is complete and successful. 2. Motivation AUTHORIZE cells should be able to perform a variety of authorization protocols based on a variety of shared secrets. This forces the AUTHORIZE cell to have a dynamic format based on the authorization method used. AUTHORIZED cells are used by bridges to signal the end of a successful bridge client authorization and the beginning of the actual link handshake. AUTHORIZED cells have no other use and for this reason their format is very simple. Both AUTHORIZE and AUTHORIZED cells are to be used under censorship conditions and they should look innocuous to any adversary capable of monitoring network traffic. As an attack example, an adversary could passively monitor the traffic of a bridge host, looking at the packets directly after the TLS handshake and trying to deduce from their packet size if they are AUTHORIZE and AUTHORIZED cells. For this reason, AUTHORIZE and AUTHORIZED cells are padded with a random amount of padding before sending. 3. Design 3.1. AUTHORIZE cell The AUTHORIZE cell is a variable-sized cell. The generic AUTHORIZE cell format is: AuthMethod [1 octet] MethodFields [...] PadLen [2 octets] Padding ['PadLen' octets] where: 'AuthMethod', is the authorization method to be used. 'MethodFields', is dependent on the authorization Method used. It's a meta-field hosting an arbitrary amount of fields. 'PadLen', specifies the amount of padding in octets. 'Padding', is 'PadLen' octets of random content. 3.2. AUTHORIZED cell format The AUTHORIZED cell is a variable-sized cell. The AUTHORIZED cell format is: 'AuthMethod' [1 octet] 'PadLen' [2 octets] 'Padding' ['PadLen' octets] where all fields have the same meaning as in section 3.1. 3.3. Cell parsing Implementations MUST ignore the contents of 'Padding'. Implementations MUST reject an AUTHORIZE or AUTHORIZED cell where the 'Padding' field is not 'PadLen' octets long. Implementations MUST reject an AUTHORIZE cell with an 'AuthMethod' they don't recognize. 4. Discussion 4.1. Why not let the pluggable transports do the padding, like they are supposed to do for the rest of the Tor protocol? The arguments of section "Alternative design: Just use pluggable transports" of proposal 187, apply here as well: All bridges who use client authorization will also need camouflaged AUTHORIZE/AUTHORIZED cell. 4.2. How should multiple round-trip authorization protocols be handled? Protocols that require multiple round-trips between the client and the bridge should use AUTHORIZE cells for communication. The format of the AUTHORIZE cell is flexible enough to support messages from the client to the bridge and the inverse. In the end of a successful multiple round-trip protocol, an AUTHORIZED cell must be issued from the bridge to the client. 4.3. AUTHORIZED seems useless. Why not use VPADDING instead? As noted in proposal 187, the Tor protocol uses VPADDING cells for padding; any other use of VPADDING makes the Tor protocol kludgy. In the future, and in the example case of a v3 handshake, a client can optimistically send a VERSIONS cell along with the final AUTHORIZE cell of an authorization protocol. That allows the bridge, in the case of successful authorization, to also process the VERSIONS cell and begin the v3 handshake promptly.

6 12

Thandy and what's next
by Tomas Touceda 13 May '12

13 May '12

Hello everyone, Thandy, for those who haven't heard about it by now, in few words is a package system for Tor packages and the like. One of the biggest problems we have right now is keeping users' Tor up to date, so we are trying to make time to get this going. (For more detailed information about Thandy check [1], specially the doc/ and specs/ directories) A couple of months ago, nickm and erinn worked in writing the package format spec (see [2] for more details), and now I'm going to start working as fast as I can (which may be slow) in implementing this last spec and get a working Thandy. On the more technical side, the idea is to implement this in Python as a first approach. In terms of distribution, Python isn't the best choice for platforms like Windows, but right now porting Thandy to another language isn't among the top priorities. This will probably be merged with the alpha track of releases we are making, so this can have as much testing as it can before going to stable. [1] https://gitweb.torproject.org/thandy.git/tree [2] https://gitweb.torproject.org/erinn/thandy.git/blob/934300a7c4c6c0493bedaf0… Cheers, -- Tomas Touceda Gentoo Developer - Qt, Scheme, Lisp

4 4

Implement JSONP interface for check.torproject.org
by Arturo Filastò 26 Mar '12

26 Mar '12

I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor. This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org. I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously. Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible. Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge. You can see how this works on the live demo hosted here: http://hellais.github.com/torcheck/privacybadge.html I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler. Also, the check.torproject repo should be moved to svn. - Art.

4 10

Re: [tor-dev] Proposal 193: Safe cookie authentication
by Robert Ransom 22 Mar '12

22 Mar '12

I've pushed a revised protocol change to branch safecookie of git.tpo/rransom/torspec.git, and a (messy, needs rebase, untested) implementation to branch safecookie-023 of git.tpo/rransom/tor.git. Now, the client and server nonces are fed to the same HMAC invocation, so that the client can believe (modulo Merkle-Damgard and general iterative hash function ‘features’) that the server knows the cookie (rather than just HMAC(constant, cookie)). Almost all controllers must drop almost all support for non-safe cookie authentication ASAP, because a compromised system-wide Tor process could drop a symlink to /home/rransom/.ed25519-secret-key in where it was supposed to put a cookie file. The sole exception to ‘non-safe cookie authentication must die’ is when a controller knows that it is connected to a server process with equal or greater access to the same filesystem it has access to. In practice, this means ‘only if you're completely sure that Tor is running in the same user account as the controller, and you're completely sure that you're connected to Tor’, and no controller is sure of either of those. Robert Ransom

2 2

Mnemonic 80-bit phrases (proposal)
by Sai 21 Mar '12

21 Mar '12

Hello all. We've written up our proposal for mnemonic .onion URLs. See https://docs.google.com/document/d/sT5CulCVl0X5JeOv4W_wC_A/edit?disco=AAAAA… for details; please read the full intro for explanations and caveats, as some are important. tl;dr: It's a system that would have all three properties of being secure, distributed, and human-meaningful… but would *not* also have choice of name (though it has the required *canonicality* of names), and has a somewhat absurdist definition of 'meaningful'. :-P Please feel free to put comments there or on list. Right now we're at the stage just before implementation; namely, we haven't yet collated the necessary dictionaries, but we have a reasonably good idea of how the system would work, including needed constraints on the dictionaries. If you have suggestions or comments, now is a good time to talk about them, so that if any of it affects the dictionary collation step we don't waste work. Thanks, Sai

6 13

A modest proposal for a petname system in ideas/xxx-onion-nyms.txt
by Jacob Appelbaum 19 Mar '12

19 Mar '12

Hi, Arturo and I have discussed a possible petname system for tor2web that would make it simple to remember hidden service names; it's not perfect, it's not secure and it requires comment from the community. The basic idea is to make it easy to deploy and see if anyone cares to use it. Here's the proposal in url form: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-on… Here's the proposal as text: Filename: xxx-onion-nyms.txt Title: .onion nym system Author: Arturo FilastÃ², Jacob Appelbaum Created: 17 December 2011 Status: Draft 1. Intro and Motivation The main issue that prohibits the wide scale adoption of .onion addressing is the fact that they are not human memorable. While Zooko's triangle says that you can only have at most two of "memorable", "secure" and "global" it is possible to build a simple nym mechanism that relies on the current .onion addressing system. We define a basic registration system generally and also it's particual application to the tor2web network. This is a very simple kind of petname system for applications such as tor2web. 2. Definitions These are the definitions of the actors involved in the process. Beppe - The owner of the Tor Hidden Service User - A random user of Tor/tor2web v2cbb2l4lsnpio4q.onion - The .onion address that Beppe is interested in registering antani - The nym Beppe is interested in associating to v2cbb2l4lsnpio4q.onion t2w - A tor2web node 3. Registration This is the process through which Beppe is able to make a registration for his chosen nym. 3.1 General implementation Beppe wishes to register "antani" to point to v2cbb2l4lsnpio4q.onion so he creates a a TCP service listening on his .onion will respond with the string "reg antani" when interrogated. The requester will make a lookup in his database to see if "antani" is already registered. If it is not registered the "antani" <-> v2cbb2l4lsnpio4q.onion mapping is created. A timestamp is added to the database. 3.2 Tor2web implementation Beppe creates a file called "onion.txt" containing the string "reg antani" and uploads it to the root of his web server. When User visits v2cbb2l4lsnpio4q.tor2web.org the t2w checks if his database contains a mapping with v2cbb2l4lsnpio4q.onion, if it does not, it requests the http://v2cbb2l4lsnpio4q.onion/onion.txt file. If the file exists t2w reads it and extracts the "antani" string. A lookup is made in his database. If "antani" is not registered he creates a mapping between "antani" and v2cbb2l4lsnpio4q.onion. A timestamp is added to the database. 4. Expiration A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting. 4.1 Time delay We define the default tiem threshold to be 30 days since the last check. At the time of expiry or anytime before, another request is made to either the TCP service or for the "onion.txt" file. If the Hidden Service is offline or if the requested mapping has changed the mapping is removed or modified. If the onion.txt is unchanged, the nym remains valid and the database timestamp entry is updated. 4.2 Release The HS can specify the "release" string to delete the entry from the nym database. 5. Synchronization To keep the database of registered nyms up to date in for many t2w nodes, a synchronization mechanism is required but currently out of scope for this document. All the best, Jacob

5 5

Pre-draft of Proposal XXX: Extended ORPort and TransportControlPort
by George Kadianakis 15 Mar '12

15 Mar '12

After discussion in tickets #4773 and #3587 this is a pre-draft of a proposal that revamps the Extended ORport, introduced in proposal 180, and specifies the new TransportControlPort. Comments are marked with '#', and there is also: https://trac.torproject.org/projects/tor/ticket/4773#comment:5 Note that this proposal is not ready for prime time. It needs more thought and lots of editing to become functional and implementable. Inlining: Filename: X Title: Extended ORPort and TransportControlPort Author: X Created: X Status: worse-than-draft-still-probably-more-thoughtful-than-sopa 1. Overview Proposal 180 defined Tor pluggable transports, a way to decouple protocol-level obfuscation from the core Tor protocol in order to better resist client-bridge censorship. This is achieved by introducing pluggable transport proxies, programs that obfuscate Tor traffic to resist DPI detection. Proposal 180 defined a way for pluggable transport proxies to communicate with local tor clients and bridges, so as to exchange traffic. This document extends this communication protocol, so that pluggable transport proxies can exchange arbitrary operational information and metadata with tor clients and bridges. 2. Motivation The communication protocol specified in Proposal 180 gives a way for transport proxies to announce the IP address of their clients to tor. Still, modern pluggable transports might have more (?) needs than this. For example: 1. Tor might want to inform pluggable transport proxies on how to rate-limit incoming or outgoing connections. 2. Server pluggable transport proxies might want to pass client information to an anti-active-probing system controlled by tor. 3. Tor might want to temporarily stop a transport proxy from obfuscating traffic. To satisfy the above use cases, there must be real-time communication between the tor process and the pluggable transport proxy. To achieve this, this proposal refactors the extended ORPort protocol specified in Proposal 180, and introduces a new port, TransportControlPort, whose sole role is the exchange of control information between transport proxies and tor. 3. The new extended ORPort protocol Server transport proxies may need to connect to the bridge and pass additional information about client connections that the bridge would ordinarily receive from the kernel's TCP stack. To do this, they connect to the "extended server port" as given in EXTENDED_SERVER_PORT, send a short amount of information, wait for a response, and then send the user traffic on that port. The extended server port protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Commands sent from the transport proxy to the bridge are: [0x0000] DONE: There is no more information to give. (body ignored) [0x0001] USERADDR: an address:port string that represents the user's address. [0x0002] WANT_CONTROL: A body-less message which indicates that the transport proxy wants to use the TransportControlPort of the bridge. It SHOULD be followed by a CONTROL command from the bridge, otherwise the transport may close the connection. # will this work? Replies sent from tor to the proxy are: [0x1000] OKAY: Send the user's traffic. (body ignored) [0x1001] DENY: Tor would prefer not to get more traffic from this address for a while. (body ignored) [0x1002] CONTROL: a NUL-terminated "identifier" string, followed by a second NUL-terminated string of the <address>:<port> of the TransportControlPort. The pluggable transport proxy must use the "identifier" to access the TransportControlPort. # pass TransportControlPort <address>:<port> through env. vars? # what should parties do when they receive a command they don't # understand? should we enforce forward-compatibility with protocol # versioning or with "ignore commands you don't understand", or what? [We could also use an out-of-band signalling method to tell Tor about client addresses, but that's a historically error-prone way to go about annotating connections.] The new TransportControlPort protocol The TransportControlPort protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Association commands sent from the transport proxy to the bridge are: [0x0000] ASSOCIATE: a NUL-terminated "identifier" string. See 'Association' section below. Association commands sent from the bridge to the transport proxy are: [0x1000] ASSOCIATED: Sent upon receiving a legit ASSOCIATE command from a transport proxy. (body ignored) [0x1001] NOT_ASSOCIATED: Sent after the bridge receives a non-legit ASSOCIATE command from a transport proxy. Also sent when the bridge receives a non-ASSOCIATE command from a non-associated transport proxy. Upon sending this command, the bridge SHOULD close the connection. (body ignored) Configuration commands sent from the transport proxy to the bridge: [0x0001] RATE_LIMITED: Message confirming that the rate limiting request of the bridge was carried out successfully (body ignored). See the 'Rate Limiting' section below. [0x0001] NOT_RATE_LIMITED: Message notifying that the transport proxy failed to carry out the rate limiting request of the bridge (body ignored). See the 'Rate Limiting' section below. Configuration commands sent from the bridge to the transport proxy are: [0x1002] RATE_LIMIT: Carries information on how the pluggable transport proxy should rate-limit its traffic. See the 'Rate Limiting' section below. # what should parties do when they receive a command they don't understand? 3.1. Association and identifier creation For Tor and a transport proxy to communicate using the TransportControlPort, an identifier must have already been negotiated using the 'CONTROL' command of Extended ORPort. The TransportControlPort identifier should not be predictable by a user who hasn't received a 'CONTROL' command from the Extended ORPort. For this reason, the TransportControlPort identifier should not be cryptographically-weak or deterministically created. Tor should create its identifiers by generating 16 bytes of random data and hashing them with the SHA256 cryptographic hash function. The identifier string transmitted with the 'CONTROL' command should be the hex representation of the SHA256 output. 4. Configuration commands 4.1. Rate Limiting A tor relay should be able to inform a transport proxy in real-time about its rate-limiting needs. This can be achieved by using the TransportControlPort and sending a 'RATE_LIMIT' command to the transport proxy. The body of the 'RATE_LIMIT' command should carry two integers, in NUL-terminated ASCII string format, representing the bandwidth rate and bandwidth burst in 'bytes per second', that the transport proxy must set. # better transmit format? After reading langsec.org, I prefer to avoid # length fields. Not that this format is bug-proof... When the transport proxy sets the appropriate rate limiting, it should send back a 'RATE_LIMITED' command. If it fails while setting up rate limiting, it should send back a 'NOT_RATE_LIMITED' command. After sending a 'RATE_LIMIT' command. the tor bridge might want to stop pushing data to the transport proxy, till it receives a 'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED' command it might want to shutdown its connections to the transport proxy. # is this realistic? 5. Security Considerations Extended ORPort or TransportControlPort do _not_ provide link confidentiality, authentication or integrity. Sensitive data, like cryptographic material, should not be transferred through them. Note that an attacker with superuser access, is able to sniff network traffic, and capture TransportControlPort identifiers and any data passed through those ports. # Is it worth adding an SSL layer (passing pub. key fpr via # env. vars?)? :/ # Talk about Incentives of tor or transport proxies to comply to the # wishes of each other. Ways to detect nonconformism. (threat # model. Should tor speak with 3v1l transport proxies in the first # place?) 6. Future In the future, we might have pluggable transports which require the _client_ transport proxy to use the TransportControlPort and exchange control information with the tor client. The current proposal doesn't yet support this, but we should not add functionality that will prevent it from being possible.

2 6

New IP-address for directory authority maatuska
by Linus Nordberg 29 Feb '12

29 Feb '12

Hi, The provider where maatuska, my directory authority, has been hosted for the last two years or so has had some trouble with its switches lately. I was unable to keep maatuska on the network enough to be a good participant of making a consensus. I decided to move the machine to a place where I have physical access 24x7 and can run it on a network under my control. Other directory authorities need to change its idea of where maatuska lives in order to make it part of the consensus making. Clients benefit from the same change, for downloading the consensus. Nick, Roger, can you please apply the following patch. --8<---------------cut here---------------start------------->8--- diff --git a/src/or/config.c b/src/or/config.c index d341d63..3a7bf65 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -928,7 +928,7 @@ add_default_trusted_dir_authorities(dirinfo_type_t type) "208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417", "maatuska orport=80 no-v2 " "v3ident=49015F787433103580E3B66A1707A00E60F2D15B " - "213.115.239.118:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810", + "171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810", NULL }; for (i=0; dirservers[i]; i++) { --8<---------------cut here---------------end--------------->8--- Thanks. -- Linus

2 1

Pluggable Transport through SOCKS proxy
by Arturo Filastò 29 Feb '12

29 Feb '12

Following up on the discussion at the Tor dev meeting with Nick this is the proposal for the Pluggable Transport through SOCKS proxies. You can also find it committed on github: https://github.com/hellais/torspec/commit/f0a89c8ded1971199fec6ffd0fe7e4056… Filename: xxx-pluggable-transports-through-proxy.txt Title: Pluggable Transport through SOCKS proxy Author: Arturo Filastò Created: 28 February 2012 Status: Draft Overview Tor introduced Pluggable Transports in proposal 180 Pluggable Transports for circumvention. The problem is that Tor currently cannot use a Pluggable Transport proxy and a SOCKS proxy at the same time. This has been noticed by users in #5195, where Tor would be failing saying "Unacceptable option value: You have configured more than one proxy type". Trivia This comes from a discussion that came up with Nick and I promised to write a proposal for it if I wanted to hear what he had to say. Nick spoke and I am writing this proposal. Acknowledgements Most of the credit goes to Nick Mathewson for the main idea and the rest of it goes to George Kadianakis for helping me out in writing it. Motivation After looking at some options we decided to go for this solution solution since it guarantees backwards compatibility and is not particularly costly to implement. Design overview When Tor is configured to use both a Pluggable Transport proxy and SOCKS proxy it should delegate the proxying to the pluggable transport proxy. This can be achieved by setting the environment variables for the SOCKS proxy to that specified inside of the torrc. When the pluggable transport proxy starts it will first read the environment variables and if it detects that it should be using a SOCKS proxy make all it's traffic go through it. Once the pluggable transport proxy has successfully established a connection to the SOCKS proxy it should notify Tor of it's success or failure. When both the SOCKS and the PluggableTransport directives are set Tor should set the environemnt variable start the pluggabletransport proxy and wait for it to report back on the SOCKS proxy status. If the pluggable transport reports back a failure or it does not report back at all (maybe because it is an outdated version), Tor should notify the user of the failure and exit with an error. The environment variables can also contain the credentials for accessing the proxy. Specifications: Tor Pluggable Transport communication When Tor detects a SOCKS proxy directive and a Pluggable Transport proxy directive it sets the environment variable: "TOR_PT_PROXY" -- This is the address of the proxy to be used by the pluggable transport proxy. It is in the format: <proxy_type>://<user_name?>:<password?>@<ip>:<port> ex. socks5://tor:test1234@198.51.100.1:8000 socks4a://198.51.100.2:8001 If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set it attempts connecting to it. On successs it will write to stdout (as specified in 180-pluggable-transport.txt) PROXY true. On failure it should write PROXY-ERROR <errormessage>. If Tor does not read any PROXY line or it reads a PROXY-ERROR line and it is configured to use both SOCKS and PluggableTransport it should exit with error.

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2012