November 2011 - tor-dev - lists.torproject.org

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 14 May '12

14 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ò 27 Mar '12

27 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

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

Tor on TV (hemm, on WDTV!)
by Fabio Pietrosanti (naif) 15 Dec '11

15 Dec '11

Hi all, i got a WDTV Live (http://support.wdc.com/product/install.asp?groupid=1003&lang=en) that's part of bigger family of consumer mediaplayer from Western Digital (http://support.wdc.com/product/install.asp?level1=10&lang=en) It seems it can run Tor without any major issue. There is a very nice hacked firmware community around WDTV users, that's a very cheap hardware (retail price 70-80EUR). What's about making a "promotional" campaign like for the Tor Cloud to have people running Tor Relay "right on their TV" ? I mean, the "hacked firmware" installation process of WDTV works that way: - Plug an USB Key formatted FAT32 with 3 files (boot, kernel, image) on WDTV - Poweron So it may be possible to make a campaign where users are invited to "run their tor relay" on their TV in 3 simple steps: - Get a USB Key - Load that files on it - Plug to your WDTV - Poweron your WDTV You are now helping poor sirian, iranian and chinese censored people. That way even the average fat guy sitting on his couch drinking beer and eating wing chicken can support freedom of speech. That kind of user can just "poweron" the WDTV and with his "remote control" after seeing his favorite telefilm on paytv, can just "zap" to see how his Tor Router is working: On TV! This could be defined as the "very lazy Tor user" who doesn't even want to use a computer, but just do TV zapping :P So, the idea could be to do a custom hacked firmware of WDTV and a WDTV Apps that you can "click" via remote control, seeing the statistics of your Tor Relay. # uname -a Linux WDTVLIVE 2.6.22.19-19-4 #28 PREEMPT Mon Mar 22 20:08:14 CST 2010 mips GNU/Linux # tor --version Jan 01 15:41:37.533 [notice] Tor v0.2.2.32 (git-877e17749725ab88). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux mips) Tor version 0.2.2.32 (git-877e17749725ab88). # free total used free shared buffers Mem: 199056 193664 5392 0 10832 Swap: 0 0 0 Total: 199056 193664 5392 # cat /proc/cpuinfo system type : Sigma Designs TangoX processor : 0 cpu model : MIPS 24K V7.12 FPU V0.0 Initial BogoMIPS : 332.59 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes ASEs implemented : mips16 shadow register sets : 1 VCED exceptions : not available VCEI exceptions : not available System bus frequency : 333000000 Hz CPU frequency : 499500000 Hz DSP frequency : 333000000 Hz -naif

4 6

Automatically retrieve and store information about bridges
by Sebastian Hahn 01 Dec '11

01 Dec '11

Filename: xxx-store-bridge-information.txt Title: Automatically retrieve and store information about bridges Author: Sebastian Hahn Created: 16-Nov-2011 Status: Open Target: 0.2.[45].x Overview: Currently, tor already stores some information about the bridges it is configured to use locally, but doesn't make great use of the stored data. This data is the Tor configuration information about the bridge (IP address, port, and optionally fingerprint) and the bridge descriptor which gets stored along with the other descriptors a Tor client fetches, as well as an "EntryGuard" line in the state file. That line includes the Tor version we used to add the bridge, and a slightly randomized timestamp (up to a month in the past of the real date). The descriptor data also includes some more accurate timestamps about when the descriptor was fetched. The information we give out about bridges via bridgedb currently only includes the IP address and port, because giving out the fingerprint as well might mean that Tor clients make direct connections to the bridge authority, since we didn't design Tor's UpdateBridgesFromAuthority behaviour correctly. Motivation: The only way to let Tor know about a change affecting the bridge (IP address or port change) is to either ask the bridge authority directly, or reconfigure Tor. The former requires making a non-anonymized direct connection to the bridge authority Tonga and asking it for the current descriptor of the bridge with a given fingerprint - this is unsafe and also requires prior knowledge of the fingerprint. The latter requires user intervention, first to learn that there was an update and second to actually teach Tor about the change. This is way too complicated for most users, and should be unnecessary while the user has at least one bridge that remains working: Tonga can give out bridge descriptors when asked for the descriptor for a certain fingerprint, and Tor clients learn the fingerprint either from their torrc file or from the first connection they make to a bridge. For some users, however, this option is not what they want: They might use private bridges or have special security concerns, which would make them want to connect to the IP addresses specified in their configuration only, and not tell Tonga about the set of bridges they know about, even through a Tor circuit. Also see https://blog.torproject.org/blog/different-ways-use-bridge for more information about the different types of bridge users. Design: Tor should provide a new configuration option that allows bridge users to indicate that they wish to contact Tonga anonymously and learn about updates for the bridges that they know about, but can't currently reach. Once those updates have been received, the clients would then hold on to the new information in their state file, and use it across restarts for connection attempts. The option UpdateBridgesFromAuthority should be removed or recycled for this purpose, as it is currently dangerous to set (it makes direct connections to the bridge authority, thus leaking that a user is about to use bridges). Recycling the option is probably the better choice, because current users of the option get a surprising and never useful behaviour. On the other hand, users who downgrade their Tors might get the old behaviour by accident. If configured with this option, tor would make an anonymized connection to Tonga to ask for the descriptors of bridges that it cannot currently connect to, once every few hours. Making more frequent requests would likely not help, as bridge information doesn't typically change that frequently, and may overload Tonga. This information needs to be stored in the state file: - An exact copy of the Bridge stanza in the torrc file, so that tor can detect when the bridge is unconfigured/the configuration is changed - The IP address, port, and fingerprint we last used when making a successful connection to the bridge, if this differs from/supplements the configured data. - The IP address, port, and fingerprint we learned from the bridge authority, if this differs from both the configured data and the data we used for the last successful connection. We don't store more data in the state file to avoid leaking too much if the state file falls into the hands of an adversary. Security implications: Storing sensitive data on disk is risky when the computer one uses gets into the wrong hands, and state file entries can be used to identify times the user was online. This is already a problem for the Bridge lines in a user's configuration file, but by storing more information about bridges some timings can be deduced. Another risk is that this allows long-term tracking of users when the set of bridges a user knows about is known to the attacker, and the set is unique. This is not very hard to achieve for bridgedb, as users typically make requests to it non-anomymized and bridgedb can selectively pick bridges to report. By combining the data about descriptor fetches on Tonga and this fingerprint, a usage pattern can be established. Also, bridgedb could give out a made-up fingerprint to a user that requested bridges, thus easily creating a unique set. Users of private bridges should not set this option, as it will leak the fingerprints of their bridges to Tonga. This is not a huge concern, as Tonga doesn't know about those descriptors, but private bridge users will likely want to avoid leaking the existence of their bridge. We might want to figure out a way to indicate that a bridge is private on the Bridge line in the configuration, so fetching the descriptor from Tonga is disabled for those automatically. This warrants more discussion to find a solution that doesn't require bridge users to understand the trade-offs of setting a configuration option. One idea is to indicate that a bridge is private by a special flag in its bridge descriptor, so clients can avoid leaking those to the bridge authority automatically. Also, Bridge lines for private bridges shouldn't include the fingerprint so that users don't accidentally leak the fingerprint to the bridge authority before they have talked to the bridge. Specification: No change/addition to the current specification is necessary, as the data that gets stored at clients is not covered by the specification. This document is supposed to serve as a basis for discussion and to provide hints for implementors. Compatibility: Tonga is already set up to send out descriptors requested by clients, so the bridge authority side doesn't need any changes. The new configuration options governing the behaviour of Tor would be incompatible with previous versions, so the torrc needs to be adapted. The state file changes should not affect older versions.

2 1

Proposal: Bridge Detection Resistance against MITM-capable Adversaries
by George Kadianakis 01 Dec '11

01 Dec '11

Filename: XXX-mitm-bridge-detection-resistance.txt Title: Bridge Detection Resistance against MITM-capable Adversaries Author: George Kadianakis Created: 07 Nov 2011 Status: Open 1. Overview Proposals 187, 189 and 190 make the first steps toward scanning resistant bridges. They attempt to block attacks from censoring adversaries who provoke bridges into speaking the Tor protocol. An attack vector that hasn't been explored in those previous proposals is that of an adversary capable of performing Man In The Middle attacks to Tor clients. At the moment, Tor clients using the v3 link protocol have no way to detect such an MITM attack, and will gladly send an VERSIONS or an AUTHORIZE cell to the MITMed connection, thereby revealing the Tor protocol and thus the bridge. This proposal introduces a way for clients to detect an MITMed SSL connection, allowing them to protect against the above attack. 2. Motivation When the v3 link handshake protocol is performed, Tor's SSL handshake is performed with the server sending a self-signed certificate and the client blindly accepting it. This allows the adversary to perform an MITM attack. A Tor client must detect the MITM attack before he initializes the Tor protocol by sending a VERSIONS or an AUTHORIZE cell. A good moment to detect such an MITM attack is during the SSL handshake. To achieve that, bridge operators provide their bridge users with a hash digest of the public-key certificate their bridge is using for SSL. Bridge clients store that hash digest locally and associate it with that specific bridge. Bridge clients who have "pinned" a bridge to a certificate "fingerprint" can thereafter validate that their SSL connection peer is the intended bridge. Of course, the hash digest must be provided to users out-of-band and before the actual SSL handshake. Usually, the bridge operator gives the hash digest to her bridge users along with the rest of the bridge credentials, like the bridge's address and port. 3. Security implications Bridge clients who have pinned a bridge to a certificate fingerprint will be able to detect an MITMing adversary in timely fashion. If after detection they act as an innocuous Internet client, they can successfully remove suspicion from the SSL connection and subvert bridge detection. Pinning a certificate fingerprint and detecting an MITMing attacker does not automatically aleviate suspicions from the bridge or the client. Clients must have a behavior to follow after detecting the MITM attack so that they look like innocent Netizens. This proposal does not try to specify such a behavior. Implementation and use of this scheme does not render bridges and clients immune to scanning or DPI attacks. This scheme should be used along with bridge client authorization schemes like the ones detailed in proposal 190. 4. Tor Implementation 4.1. Certificate fingerprint creation The certificate fingerprints used on this scheme MUST be computed by applying the SHA256 cryptographic hash function upon the ASN.1 DER encoding of a public-key certificate. 4.2. Bridge side implementation Tor bridge implementations SHOULD provide a command line option that exports a fully equipped Bridge line containing the bridge address and port, the link certificate fingerprint and any other enabled Bridge options, so that bridge operators can easily send it to their users. In the case of expiring SSL certificates, Tor bridge implementations SHOULD warn the bridge operator a sensible amount of time before the expiration, so that she can warn her clients and potentially rotate the certificate herself. 4.3. Client side implementation Tor client implementations MUST extend their Bridge line format to support bridge SSL certificate fingerprints. The new format is: Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \ ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>] where <fingerprint> is the bridge's SSL certificate fingerprint in hexademical encoding. Tor clients who use bridges and want to pin their SSL certificates must specify the bridge's SSL certificate fingerprint as in: Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187 4.4. Implementation prerequisites Tor bridges currently rotate their SSL certificates every 2 hours. This not only acts as a fingerprint for the bridges, but it also acts as a blocker for this proposal. Tor trac ticket #4390 and proposal YYY were created to resolve this issue. 5. Acknowledgements Thanks to Robert Ransom for his great help and suggestions on devising this scheme and writing this proposal!

5 6