- tor-dev - lists.torproject.org

Port of python Tor controller library to C++
by Nguyen, Giang Truong Khoa 19 Jan '12

19 Jan '12

Hi, As part of my research, I am porting Mike Perry's python Tor controller library (pytorctl) to C++. Though the work is not exactly Tor development, tor-dev seems the most appropriate mailing list to let others know that I have put my code up on Google Code at http://code.google.com/p/cpptorctl/, in case it can be useful to someone. - Giang

2 1

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

Filtering of DA and bootstrap
by Fabio Pietrosanti (naif) 17 Jan '12

17 Jan '12

Hi all, in a network where the Directory Authority hard-coded in Tor code are filtered a Tor client cannot bootstrap. But as far as i understood there are (hundreds?) of Tor DA Mirror. If so, packaging the Tor clients periodically, bundling the latest consensus with the software, would provide higher chance for a client to bootstrap, finding an unfiltered Tor DA Mirror. Is this assumption true? Fabio

2 1

Size issues with Orbot statically linking OpenSSL
by Nathan Freitas 17 Jan '12

17 Jan '12

With the recent problems related to SSLv3 with versions of OpenSSL less than 1.0.0f, we have been investigating how to deal with this on Android for Orbot. Historically, we have used the version of OpenSSL provided by the Android device itself, which has ranged from 0.9.8 to 1.0.0e (the latest on ICS 4.0). We have now produced a build of OpenSSL 1.0.0f with the necessary Android patches, and statically linked this into the Tor binary we ship inside of Orbot. (We already do this for LibEvent, since that is not included in Android itself). With both OpenSSL and LibEvent linked, the Tor binary increases from 3MB to about 8MB. 8MB is not terrible, but once you include the Orbot app, Privoxy and other files, we are getting into the 10MB+ range. I think this is all fine, and we can enable users to run the app from a secured partition on their external storage, but I did just want to run this by all of you to see if there are any options for limiting the size of libssl.a and libcrypto.a, and the resulting Tor binary. Thx! +n8fr8

4 6

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

Sanitizing IPv6 addresses in bridge descriptors
by Karsten Loesing 16 Jan '12

16 Jan '12

Hi Linus, Ian, list, now that we have bridges running on IPv6 addresses, some bridge operators enabled that feature on their public bridges and published descriptors to the bridge authority. I wonder how to sanitize these addresses for metrics data. (Currently, lines containing IPv6 addresses are simply discarded in the sanitized output.) Here's how we sanitize IPv4 addresses (from https://metrics.torproject.org/formats.html#bridgedesc) > Replace IP address with IP address hash: Of course, the IP address > needs to be removed, too. It is replaced with 10.x.x.x with x.x.x > being the 3 byte output of H(IP address | bridge identity | > secret)[:3]. The input IP address is the 4-byte long binary > representation of the bridge's current IP address. The bridge > identity is the 20-byte long binary representation of the bridge's > long-term identity fingerprint. The secret is a 31-byte long secure > random string that changes once per month for all descriptors and > statuses published in that month. H() is SHA-256. The [:3] operator > means that we pick the 3 most significant bytes of the result. The idea is that it should be hard to derive the original IPv6 address from the sanitized address. At the same time it should be easy to notice whether the address of a given bridge has changed within the same month. Here's my plan for IPv6 addresses: - Shorter secret: For the hash function input, use the 16 byte long binary representation of the bridge's current IP address, the 20 bytes of the fingerprint, but only a 19 byte long secure random string that changes once per month. The idea is to keep the input to one SHA block (447 bits) as suggested by Ian on January 2, 2011 on this list: (16 + 20 + 19) * 8 = 440. - Alternative to shorter secret: Use the same 31 byte long secret and live with the fact that the hash input now spans two SHA blocks. Maybe use a 75 byte long secret to have an input of two SHA blocks. - Write 3 bytes of the sanitized IPv6 address in [::] notation. We're writing sanitized IPv4 addresses as 10.x.x.x. Is there a counterpart for IPv6 addresses? It should be obvious that these are "private" addresses, but I'd like to keep the notation unchanged to keep parsing tools simple. - Alternative to using 3 bytes: Should we use fewer or more bytes from the SHA-256 output for IPv6 addresses? Thanks, Karsten

3 5

Transitioning to new crypto (again, but with substance)
by Watson Ladd 14 Jan '12

14 Jan '12

Dear all, After thinking hard about the issues involved with new cryptography in Tor I came to the following idea for a somewhat reasonable upgrade path for OP's and OR's that preserves everyone's privacy and security at all points (to the extent that this is possible: new connections are by new clients). The only issue is what actually goes out on the wire needs to be though through. First note that the connection between the identity used to ensure EXTEND cells go over canonical connections and the keys actually presented by two OR's that have formed a connection can be pretty much arbitrary: it isn't necessary for the client to know what it is. So we could have each OR have an identity key that stays 1024 bit RSA for old ORs while newer ORs trust some snazzy new elliptic curve key, while using the same 1024 bits to form the identity. Note that if we use elliptic curves to secure the endpoints,(and don't mind incompatibility with old clients) the RSA key doesn't even need to be an RSA key. Also note that the Tor directory spec permits new types of lines. In particular we could have a curve-ident-key line and a curve-onionkey line each containing base-64 encoded keys, and a curve-sig line that's a signature of the rest of the entry, except for the RSA signature. The RSA signature would be as normal. To an old client this looks exactly like an old style directory entry. To a new client this looks like the elliptic curve key is the root of trust. This is OK: fiddling with an RSA signature doesn't let you fool a new client into thinking things about identities, because the identity is derived from the RSA key which is signed with the curve-ident-key. The onion-key is trusted by both the curve-ident-key and the RSA identity key. It is still possible to selectively invalidate one signature, but that signature is the RSA signature: the curve-ident-signature is also covered by the RSA signature. This would have the effect of ensuring that only new clients can connect to the OR: we could require that new clients still check the RSA signature to prevent this. Lastly comes the problem of EXTEND cells. All the OR before the new extension has to do is copy what is given to it without caring about the version. To signal versions we can just use length: 64 bytes vs. 128 bytes. Sadly this signals what version a client is, but an OR can guess anyway by how it was connected to if it lists both descriptors. One thing I have not taken on is the use of the new keys in the TLS negotiations.We could extend the CERTS and AUTH cells to include them as possible types, and this is possibly the best solution. I also haven't addressed the problem of UDP transport: TLS has issues where instead of sending another packet to be processed by the next router it resends a dropped packet, holding up the queue. I've probably missed a lot of issues here, but hopefully this moves the conversation forward. Sincerely, Watson Ladd

2 2

Extending deadline for small features in 0.2.3.x by one week (to the 13th)
by Nick Mathewson 11 Jan '12

11 Jan '12

Hi, all! Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13. This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly tiny and obviously correct. Barring exceptional circumstances, any large features must wait for 0.2.4.x, as must any features that don't get merged by Friday. Once this window closes, only bugfixes will be okay for 0.2.3.x. As before, I'm going to leave the definitions of "exceptional", "large", and "feature" a little vague, and err on the side of getting a good 0.2.3.x release candidate done soon. happy hacking, -- Nick

3 5

A way to block chinese active probe
by Fabio Pietrosanti (naif) 10 Jan '12

10 Jan '12

Hi all, here's a second chinese-probe discrimination behavior that should allow to detect them, and block it. http://pastebin.com/RNcNDYcw Like the TCP SYN one, this blocking tricks is based on the fact that the OS & software they run on their server pool to make active-tor-probing have to be highly optimized, as they need to manage a huge amount of outbound connections. Does anyone would like to re-test this behaviour (also for Windows/OSX) and in case make a small patch for tor. Now i made testing with iptables && -j TARPIT . It would be nice to have in Tor a set of configurable Timeout? As any active probe present and future could have some timing issue, not being able to perfectly emulate the same conditions of a client, as active probes run on servers (and server get optimized if need to do high traffic). -naif

1 0

Re: [tor-dev] Browser-based proxies for circumvention
by Kevin Dyer 08 Jan '12

08 Jan '12

>>> A sample session goes like this: >>> 1. The user starts a connector and a Tor client. The connector sends its >>> address to the facilitator, so that a proxy will know where to >>> connect to. (We call this step "rendezvous.") >>> 2. A flash proxy appears in a browser and asks the facilitator for an >>> address. >>> 3. The facilitator sends a remembered client address to the proxy. >>> 4. The proxy connects to the client address. The client's connector >>> receives the connection. >>> 5. The proxy connects to a Tor relay, then begins copying data between >>> its two sockets. >> >> Where is the list of all facilitators? > > There is only one (not that there couldn't be more), and its address is > hardcoded into the proxy badge. I think I am confused about something: Why is it difficult for the censor to enumerate, and then block, the facilitators? -Kevin

2 1