tor-dev December 2011

tor-dev@lists.torproject.org

23 participants
29 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

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

Proposal 190: Password-based Bridge Client Authorization
by George Kadianakis 27 Jan '12

27 Jan '12

Filename: 190-password-bridge-authorization.txt Title: Password-based Bridge Client Authorization Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. Their purpose is to make bridge relays scanning resistant against censoring adversaries capable of probing hosts to observe whether they speak the Tor protocol. This proposal specifies a bridge client authorization scheme based on a shared password between the bridge user and bridge operator. 2. Motivation A proper bridge client authorization scheme should: - request information from a client that only an authorized bridge client would know. - ensure that the shared secret sent by the bridge client during the authorization can only be read and validated by the proper bridge relay. This is important since the v3 link handshake which authenticates the bridge to the client is carried out *after* the bridge client authorization, which means that when the AUTHORIZE cell is sent, the client might be actually speaking to a Man In The Middle. The bridge client authorization scheme presented in this proposal is based on a shared password and attempts to satisfy both of the above requirements. 3. Design If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants to become authorized using a shared secret based on a password. The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. 3.1. Notation '||', denotes concatenation. 'HMAC(k, m)', is the Hash-based Message Authentication Code of message 'm' using 'k' as the secret key. 'H(m)', is a cryptographic hash function applied on a message 'm'. 'HASH_LEN', is the output size of the hash function 'H'. 3.2. Shared secret format A bridge client and a bridge relay willing to use this authorization scheme, should have already exchanged out-of-band (for example, during the bridge credentials exchange) a shared password. In this case, the shared secret of this scheme becomes: shared_secret = H( H(bridge_identity_key) || ":" || password) where: 'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's public identity key. '":"', is the colon character (0x3a in UTF-8). 'password', is the bridge password. 3.3. Password-based authorization AUTHORIZE cell format In password-based authorization, the MethodFields field of the AUTHORIZE cell becomes: 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] where: 'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS certificate of the bridge relay, using the shared secret of section 3.2 as the secret key. 3.4. Password-based authorization notes Bridge implementations MUST reject clients who provide malformed AUTHORIZE cells or HMAC values that do not verify the appropriate TLS certificate. Bridge implementations SHOULD provide an easy way to create and change the bridge shared secret. 3.5. Security arguments An adversary who does not know the 'shared_secret' of a bridge cannot construct an HMAC that verifies its TLS certificate when used with the correct 'shared_secret'. An adversary who attempts to MITM the TLS connection of a bridge user to steal the 'shared_secret' will instead steal an HMAC value created by the 'tls_cert' of the TLS certificate that the attacker used to MITM the TLS connection. Replaying that 'shared_secret' value to the actual bridge will fail to verify the correct 'tls_cert'. The two above paragraphs resolve the requirements of the 'Motivation' section. Furthermore, an adversary who compromises a bridge, steals the shared secret and attempts to replay it to other bridges of the same bridge operator will fail since each shared secret has a digest of the bridge's identity key baked in it. The bridge's identity key digest also serves as a salt to counter rainbow table precomputation attacks. 4. Tor implementation The Tor implementation of the above scheme uses SHA256 as the hash function 'H'. SHA256 also makes HASH_LEN equal to 32. 5. Discussion 5.1. Do we need more authorization schemes? Probably yes. The centuries-old problem with passwords is that humans can't get their passwords right. To avoid problems associated with the human condition, schemes based on public key cryptography and certificates can be used. A public and well tested protocol that can be used as the basis of a future authorization scheme is the SSH "publickey" authorization protocol. 5.2. What should actually happen when a bridge rejects an AUTHORIZE cell? When a bridge detects a badly formed or malicious AUTHORIZE cell, it should assume that the other side is an adversary scanning for bridges. The bridge should then act accordingly to avoid detection. This proposal does not try to specify how a bridge can avoid detection by an adversary. 6. Acknowledgements Without Nick Mathewson and Robert Ransom this proposal would actually be specifying a useless and broken authentication scheme. Thanks!

5 12

Proposal 186: Multiple addresses for one OR or bridge
by Nick Mathewson 17 Jan '12

17 Jan '12

Filename: 186-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 changes 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 firewall 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 they advertise before they declare themselves reachable. If a Tor has 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? Multiple interfaces, I guess.) 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. If not, why list any more than one IPv4 and one IPv6 address?) 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 foreseeable 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. That is, clients tunnel their directory requests inside OR connections, and don't generally connect to DirPorts at all. 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.

5 5

New paper by Goldberg, Stebila, and Ostaoglu with proposed circuit handshake
by Nick Mathewson 16 Jan '12

16 Jan '12

Crypto people who have been following threads about the circuit-establishment handshake will be interested in the new paper, "Anonymity and one-way authentication in key-exchange protocols", by Goldberg, Stebila, and Ostaoglu. Here's the version they updated today: http://www.cacr.math.uwaterloo.ca/techreports/2011/cacr2011-11.pdf If we're moving to an improved handshake, this might be a good candidate to consider. The protocol itself is on page 14. Some notes, written by a guy who knows less crypto than everybody involved: * It's a pure Diffie-Hellman based system, which would lend itself nicely to use with ECC. * It seems to require the same number of exponentiations as our current system, but Ian Goldberg notes that if you want to compute X^a and X^b at the same time you can do so more efficiently by taking into account the shared base. * The security proof requires that the Gap DH assumption holds over the group -- basically, that computing the Decisional DH problem is easy, but computing the Computational DH problem is hard. This assumption isn't true of most basic ECC groups -- I think it means you need to use a pairing-based system instead for the proof to hold. I'd bet that the authors aren't seriously suggesting that we use pairing-based crypto, but I'm wondering how much they were able to prove in a groups where DDH is hard. * I haven't read over the security model closely yet; folks should review it for reasonableness. * I'm hoping to write this up as a proposed spec soon, unless Ian or somebody wants to give it a shot. yrs, -- Nick

8 29

Some naive Ideas for Bridge Distribution
by Max Maass 31 Dec '11

31 Dec '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, first off, I am only a third-semester computer science student from germany, so most likely, you will already have thought about these Ideas and discarded them. The reason I am writing them anyway is that there is still the small chance that it might help, and that I would like to learn why the other ideas won't work. So, during 28C3 I heard the TOR-Talk and it was mentioned that you are looking for ways to distribute Bridges that are harder to ban by the GFW, and it was mentioned that you are in need of more changing IPs. It was also mentioned that the GFW is following up every SSL connection and is trying to "speak TOR" on them to identify Bridges. So, some ideas: - - You mentioned that these follow-up connections are of an old version of TOR. That version doesn't have any blatant security holes, does it? ;-) - - I think you are already doing IP forwarding for bridges to gain some more IPs. Why not give us a small tool we can run on our PC / Server that is doing this forwarding. I think you can get many people to run this tool, and maybe you can even build a flash version of it, like the flash TOR Node you (or someone else, I don't remember) did a few weeks ago. - - You could also use HTTP Requests for these forwarders, to confuse the GFW a bit if it tries to follow them up. - - And, if you want to annoy them even more, you can maybe make the first response the default "I don't know what you are talking about" HTTP Response, so the GFW get's a lot of false positives if they follow up every SSL connection (Because the other Servers they are contacting will most likely will throw this Response if someone tries to contact them with the TOR-Version of HTTP Requests). - - Make it easier to host a bridge. I tried it a while ago and it did not work for me, for some reason (I don't remember anymore what the reason was, but I always got some weird error message, and the internet could not help me with it. I might try again now, though). For example: Work with the guys from DD-WRT or OpenWRT to add a TOR-Module to the Router firmware. If it only takes one checkmark to create a TOR Node / Bridge, more people will be likely to do it, and most routers are online 24/7, as opposed to maybe 10 hours a day or less if you use a regular PC. - - In addition to that: A ARM-Version of TOR that runs on Network Attached storages (For example: Synology gives the users the ability to SSH into their Box and install a packet manager). I have seen that you are already developing a ARM-Version, but I have also read that it does not work properly on Synology Hardware. I would be willing to test any ARM-Release for you on my DS211j. So, I hope that I have not wasted your time completely, and I am looking forward to being told why these things won't work (Or that you are already working on implementing them). Keep up your great and important work! Max -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO/xOVAAoJEDxYz0BvOJH8E78H/AuS1gSx6Bb7tP3JeqHqZVL0 j0tDSTqW9554CmGA9TmSe5OWc+tbkDc0ULrmr2smNucE8NOT/ylCEr5Ck/JR7ra1 nwILRzrjVwV5MyOrOgtsAce57+K/SFQCBo4N+mdhOOIMfcMnjxDWr3LVFkdO0PQ4 /eP2Zfuj7aDj3nHDiG8ipqnYlfg+bCPxEcx93dHyHqf8LIuPfYBTVp7v6T+ntLKI q1HI3INqvjpMdcbOtbPSAXqXci6kIK2Y6v5gfXD5v3qI0LDW81wL5mFV5vUvRT0p cUc8AxYoxjsK7E+JXGBmihdrGgO6GXxfyRIcR5eHZCHRqRA78wPP0fBIj0CwrnY= =xyJ5 -----END PGP SIGNATURE-----

1 0

[flashproxy] Not running using gnash
by Okhin 23 Dec '11

23 Dec '11

Hello, I was trying to run flashproxy using gnash following the RTMFP part of the tutorial located here: https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README I do not use the gnash-plugin embedded in a browser, but the CLI tool gnash packaged with debian (and invoking it like this, as a standard user: gnash swfcat.swf -p client=1 -p debug=1 I've got the following output with the connector.py script: $ ./connector.py 127.0.0.1:9001 127.0.0.1:9002 2011-12-22 15:34:07 Local connection from 127.0.0.1:54335. 2011-12-22 15:34:07 SOCKS request from 127.0.0.1:54335. 2011-12-22 15:34:07 handle_socks_request 2011-12-22 15:34:07 Got SOCKS request for 127.0.0.1:9001. 2011-12-22 15:34:07 handle_local_connection 2011-12-22 15:34:07 locals (1): [u'127.0.0.1:54335'] 2011-12-22 15:34:07 remotes (0): [] 2011-12-22 15:34:07 Data from unconnected local 127.0.0.1:54335 (141 bytes). 2011-12-22 15:34:07 locals (1): [u'127.0.0.1:54335'] 2011-12-22 15:34:07 remotes (0): [] 2011-12-22 15:34:33 Local connection from 127.0.0.1:54336. 2011-12-22 15:34:33 SOCKS request from 127.0.0.1:54336. 2011-12-22 15:34:33 handle_socks_request 2011-12-22 15:34:33 Couldn't unpack SOCKS4 header. 2011-12-22 15:34:33 locals (1): [u'127.0.0.1:54335'] 2011-12-22 15:34:33 remotes (0): [] 2011-12-22 15:34:56 EOF from unconnected local 127.0.0.1:54335 with 141 bytes buffered. 2011-12-22 15:34:56 locals (0): [] 2011-12-22 15:34:56 remotes (0): [] And I enlcosed a gnash debug logfile to this mail. I'm running a squeeze with this kernel: $ uname -ar Linux desktop 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64 GNU/Linux Regards, Okhin

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev December 2011