- tor-dev - lists.torproject.org

Windows Alternative of torsocks/tsocks ?
by Fabio Pietrosanti (naif) 22 Jan '12

22 Jan '12

Hi all, does anyone know if there is a windows alternative to torsocks/tsocks? We sketched down a draft to build up an anonymous web application framework that would allow to build TorHS exposed python webapps on a desktop computer. The draft is available at https://piratenpad.de/p/AnonymousWebApplicationFramework (feel free to modify) The idea is to deliver "GlobaLeaks.exe" (but possibly other software) including Tor, with a web-application framework that include all the functionalities to handle: - Tor Hidden Service exposure - Tor outbound communication For Tor Outbound outbound connections, the idea is to wrap all the application (Python, Tornadoweb, scripts) under Torsocks/tsocks. For Mac OS X / Linux it's easy, we can use torsocks/tsocks: TorSocks: http://code.google.com/p/torsocks/ But to make this "library preload" under windows we only found: Torcap: http://www.freehaven.net/~aphex/torcap/ Freecap: http://www.freecap.ru/eng/ Does anyone know if there's something else for win32 that can just run as a commandline tool to be included in a startup script, handling the DNS Query and TCP Connect torrifying them? -naif

2 2

Re: [tor-dev] Port of python Tor controller library to C++ (Tom?s Touceda)
by Giang Nguyen 20 Jan '12

20 Jan '12

> I'm not sure if you want to work with Qt, but may be you should take a > look at Vidalia's torcontrol classes: > https://gitweb.torproject.org/vidalia.git/tree/HEAD:/src/torcontrol Thanks, Tomas, for the suggestion. I actually tried to use Vidalia's Tor control code back in late 2010 when I looked for a C/C++ controller, but I chose not to use it for several reasons: it lacked (and I think still does) the path selection, Qt is a huge dependency, and I wasn't yet familiar with Qt dev. I was sidetracked for a while -- learning Qt dev in the process -- so now Vidalia's looks pretty attractive. Since I was almost done with my port, however, I might as well try to finish it and release it.

2 1

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) 09 Jan '12

09 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

Using a conf.d instead of a monolithic config file
by warms0x 07 Jan '12

07 Jan '12

I'm looking to start developing a Tor module for Puppet, one of the primary difficulties in making things work together "nicely" is the monolithic configuration file. Has there ever been plans or discussion about using a conf.d-style directory to store configuration file fragments? It would be useful to be able to drop fragments for hidden service configurations, etc into a directory to be picked up by the Tor daemon. If I provided the patches to make this possible, would it be useful? Cheers, -warms0x

2 1

DuckDuckGo, iOS and other stuff.
by caine tighe 03 Jan '12

03 Jan '12

tor-devers, So we are currently developing v2 of DDG applications and I'm personally interested in getting you guys involved. I think that there is serious value in ensuring Tor is an option for both Android and iOS. Currently we support Tor via Orbot on Android via the HTTP/S proxy method since the SOCKS method is known to have DNS leaks. Since the applications will be distributed via the respective stores, and specifically in the case of iOS, we cannot rely on the whole rooted / jailbroken methods. I understand that there is an application Covert Browser that claims to properly leverage Tor; however, since the source is closed, I remain unconvinced. This application stands to be both an interface to DuckDuckGo for quick and secure searching as well as a Tor enabled browser. We are always looking for other ways we can help, so let us know. I'd also like to discuss donation and a few other administration things off-list. respectfully, caine

2 1

OpenSSL v1.0.1-beta1 OK with Tor v0.2.2.35
by Steve Snyder 03 Jan '12

03 Jan '12

FYI, OpenSSL v1.0.1-beta1 seems to work fine when building and running Tor v0.2.2.35 (Linux/i686). Too early to say anything about performance (critical as the crypto is the performance bottleneck in Tor) but it definitely works as a drop-in replacement for OpenSSL v1.0.0e. http://marc.info/?l=openssl-announce&m=132338836402522&w=2

1 0

Bug 4810 : Patch in bug tracker
by Erik de Castro Lopo 02 Jan '12

02 Jan '12

Hi all, I opened a new bug agains TorButton here: https://trac.torproject.org/projects/tor/ticket/4810 and have attached a patch to fix the issue. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

unscribe
by 曹文明 02 Jan '12

02 Jan '12

unscribe

1 0

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

Browser-based proxies for circumvention
by David Fifield 23 Dec '11

23 Dec '11

A few months ago, Roger wrote about ideas for getting more bridge addresses (https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses) One of the ideas is to make lightweight bridges that can run in a web browser. I and some others have been working on this for a few months. I want to promulgate our ideas and code among you developers, and ask for your opinions and suggestions. == Summary The overall idea is a little applet that can be installed on a web page. We call it a "flash proxy." As long as you have the page open in your browser, you are a proxy. These proxies may only last a few seconds or minutes, but the code we've written allows switching between active proxies in a fairly transparent manner, enough to make web browsing possible. The idea is that web browsers provide a large, diverse, and ever-changing pool of bridge addresses. A censor will not be able to block all of them in a timely manner--at least that's what we hope. This is our overview and demo page. Down at the bottom of the page is a flash proxy badge. https://crypto.stanford.edu/flashproxy/ It's called a "flash proxy," and the implementation happens to be in Flash, but the "flash" should rather make you think "quick." I'm pretty sure the same thing can be done with WebSockets or other technologies. == Howto You can easily but slightly artificially test the flash proxy transport with this command: $ tor UseBridges 1 Bridge 127.0.0.1:9001 Socks4Proxy tor-facilitator.bamsoftware.com:9999 (Make sure a flash proxy is running somewhere, and wait about 30 seconds for a connection.) What's artificial about this example is that the service at tor-facilitator.bamsoftware.com:9999 (the "connector") is something you would normally run on your own computer. We run one on the Internet for the ease of demos like this. See the instructions in the README for how to test it more realistically. We are using the torproject.org git server, so our code is $ git clone git://git.torproject.org/flashproxy.git https://gitweb.torproject.org/flashproxy.git https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README Though you need Adobe's Flash Player to *run* the flash proxy, you can *build* it using only free software (details are in the README). == Architecture Most of the architecture is dictated by a limitation of web socket technologies, namely that they can only make outgoing TCP connections, and cannot receive connections. This leads to a funny model where the proxy connects to the client, instead of the other way around. The pieces that work together are: * Tor client (e.g. /usr/sbin/tor on the local host). * Tor relay (e.g. /usr/sbin/tor on the Internet). * Flash proxy, running in someone's web browser. Imagine that there are many of these online at once, but they have a lifetime on the order of minutes. * Connector, a little program that sits between the flash proxy and the Tor client, and receives connections from the proxy. It acts as an upstream SOCKS4 proxy to Tor (but ignores whatever address Tor gives it). The connector also does the switching between proxies as they go offline. * Facilitator, which keeps track of clients that need addresses, and gives those addresses to proxies as they come online. We are running one of these at tor-facilitator.bamsoftware.com:9002. 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. Something to note is that the flash proxy doesn't do any crypto. It is just a dumb pipe for ciphertext. There are still three relay hops after the proxy. (But the proxy effectively gets to pick the first hop.) == Objections Doesn't this shift the problem from bridges begin blocked to the facilitator being blocked, since the client has to send its address to the facilitator? The short answer is yes, we expect the facilitator to be permanently blocked by IP address, so the client must find a covert, uncensorable channel over which to rendezvous. The good news is that we've turned a big problem--how to make all your Tor traffic unblockable--into a small problem--how to make a one-time, write-only connection of a dozen bytes unblockable. This lesser constraint opens up new possibilities, for example you could email your address to someone you know and have them rendezvous on your behalf, even though you couldn't push all your Tor traffic over such a channel. Isn't blocking by protocol/DPI still possible? Yes, there are many components to circumvention, and bridge creation is just one part. Against such a censor it will be necessary to layer some kind of obfuscation, but that's an issue of its own. It also may be a revealing signature for a client IP address to receive lots of incoming connections, but how much this stands out we don't know yet. == Shortcomings I should mention that the implementation doesn't live up to everything I've stated above. The "rendezvous" step is just an HTTP POST to the facilitator. Also, the connector re-registers itself unnecessarily: that should happen only once, and thereafter the facilitator should remember it. == Next steps Here are the next things I'd like to accomplish: * Get the proxy installed on more blogs and web pages. Currently it's only on the demo page and on my web site, which only provide enough proxies to have service about 60% of the time. * Implement a bona fide rendezvous protocol. Though this is somewhat separable from flash proxies themselves, it's essential for a complete working system. We have done a couple of limited prototypes; please ask me if you are interested in or have knowledge of this. * Build an installer for client programs. * Try a plain JavaScript proxy. Unfortunately this has been very much a spare-time project for me. I'd love to share some of this development with anyone who's interested. I've had a couple of people contact me about possibly supporting development in various ways. But what I'd like most of all are your comments and ideas. I really want to invite discussion on the architecture, with the goal of making it robust and secure. Though the system is already partly usable, I still consider it a research project, not a finished product. Circumvention is such a big topic I haven't covered all the details in this message, so I value your clarifying questions. David Fifield

3 3

Drafting a proposal for mnemonic onion URLs
by Sai 21 Dec '11

21 Dec '11

Howdy all. I would like to make a mnemonic translation method for onion URLs. Not as in a full petname system with registration and so forth, just a "four little words" style way of rendering and entering existing 80-bit hashes in a way that is memorable to not just detect partial-overlap fuzzing attacks but actually memorize and produce the URL directly. I'm not yet ready to make a formal proposal for serious review, but here is an edit-authorized link to a draft document which has a bit more detail. Feel free to edit and comment there. https://docs.google.com/document/d/1IFMnMGh8ZqJIXYBhZOK4IW5KKG0fTatpTJiTS67… I'll update tor-dev when I feel it's ready for review as an actual draft proposal; it's certainly not there yet. This is just meant as a courtesy notice in case you're interested enough to help make it, and following up from a discussion earlier today on tor-assistants. Cheers, Sai

2 2

Is Taking Checksum of Packet Payloads a Vulnerability?
by Daniel Cohen 19 Dec '11

19 Dec '11

Hi, I am new to Tor, but after reading about its design, and reading a few research papers on its vulnerabilities (specifically timing attacks), I had the following thought: Suppose Alice is connecting to Bob via Tor, using HTTPS encryption. She sends a packet to the Tor entry node (call it En). The packet travels through the network, emerges from an exit node (call it Ex), and arrives at Bob. Alice => En => Tor Network => Ex => Bob Now suppose that Alice's connection is being monitored, as well as a group of the exit nodes (which are either hostile or having their packets sniffed). When the encrypted packet leaves Alice on its way to En, it is sniffed, and a checksum is made of its encrypted payload. The packet then continues through the network as usual, and emerges from an exit node. It appears to me that the attacker need only check packets coming out of exit nodes to see if their payload checksums match that of the packet observed leaving Alice. Unlike timing attacks, which require a reasonable number of packets to confirm Alice's identity, this attack would require only one, since checksums have an almost 0% chance of collision. If a packet with the same payload checksum as Alice's is discovered, it almost certainly originated from her. Is this a problem with Tor's architecture? If so, has this issue already been addressed? Thanks, Daniel Cohen

5 4

Python SSL/TLS Security enhancement
by Fabio Pietrosanti (naif) 19 Dec '11

19 Dec '11

Hi all, following the new Tor2web development based on Python by hellais (ongoing http://github.com/hellais/tor2web) we realized that the Python SSL binding are quite crap. We opened a set of Tickets on Python Issue tracker where i think that the Tor Project Community (that use a lot Python) could contribute and/or give out ideas. Having a secure Python SSL/TLS binding can be very valuable: Python SSL stack doesn't support DH ciphers http://bugs.python.org/issue13626 Python SSL stack doesn't support Elliptic Curve ciphers http://bugs.python.org/issue13627 Python SSL stack doesn't support ordering of Ciphers http://bugs.python.org/issue13635 Python SSL stack doesn't support Compression configuration http://bugs.python.org/issue13634 In particular one idea, following the assessment of implementation, would be to provide to Python a default set of secure ciphers, considering performance and compatibility issues where i think that the Tor Project knowledge could be helpful: Python SSL Stack doesn't have a Secure Default set of ciphers http://bugs.python.org/issue13636 Defining a method of selection that can convince the Python project to be "Secure by default" (yet compatible and high performance) without leaving enable by default SSLv2 or DES 40bit ciphers. Hope in some contribution and testing -naif p.s. basically DHE,ECDHE, Ordered ciphers are needed for tor2web

1 0

common/aes.c troubles
by Gisle Vanem 19 Dec '11

19 Dec '11

In common/aes.c: #include "orconfig.h" #include <openssl/opensslv.h> ... #include <openssl/aes.h> .. #include "compat.h" By default <winsock.h> is included in <windows.h> when WIN32_LEAN_AND_MEAN is not defined. But this is defined too late; in compat.h. So when <e_os.h> in OpenSSL pulls in <winsock.h> and <winsock2.h> gets included in compat.h, I'm getting lots of warnings and redefinitions errors. E.g. g:\VC_2010\SDK\include\winsock.h(787) : see declaration of 'inet_ntoa' g:\VC_2010\SDK\include\winsock2.h(1815) : error C2375: 'listen' : redefinition; different linkage An easy fix would be to move "#define WIN32_LEAN_AND_MEAN" into win32/orconfg.h: diff --git a/src/common/compat.h b/src/common/compat.h index a228a46..5c66a11 100644 --- a/src/common/compat.h +++ b/src/common/compat.h @@ -15,7 +15,9 @@ #ifndef _WIN32_WINNT #define _WIN32_WINNT 0x400 #endif +#ifndef WIN32_LEAN_AND_MEAN #define WIN32_LEAN_AND_MEAN +#endif #if defined(_MSC_VER) && (_MSC_VER < 1300) #include <winsock.h> #else diff --git a/src/win32/orconfig.h b/src/win32/orconfig.h index e51b638..b9fe31f 100644 --- a/src/win32/orconfig.h +++ b/src/win32/orconfig.h @@ -5,6 +5,7 @@ /* Windows-only defines. */ #define MS_WINDOWS #define MS_WIN32 +#define WIN32_LEAN_AND_MEAN #define CONFDIR "" /* Define to 1 if you have the <arpa/inet.h> header file. */ How about it? --gv

2 3

Re: [tor-dev] [tor-announce] Tor 0.2.2.35 is released (security patches)
by Fabio Pietrosanti (naif) 17 Dec '11

17 Dec '11

Should we think to have all tor-users that run a version minor than X, go automatically off-the-network? I mean, if we have let's say 10% of outdated users, it means that 10% of the network can be compromised with a single remote exploit. I mean, running a Tor node today it's a responsibility. If a node maintainer it not going to update within a possibly defined grace period, it should imho get kicked-out from the network. Has been this concept already considered somehow? I mean, at least if a node is not updated for example, it would never be able to achieve a certain "status" or functionalities. For example never become a Guard node or never became an Exit Node? -naif On 12/16/11 7:19 PM, Roger Dingledine wrote: > Tor 0.2.2.35 fixes a critical heap-overflow security issue in Tor's > buffers code. Absolutely everybody should upgrade. > > The bug relied on an incorrect calculation when making data continuous > in one of our IO buffers, if the first chunk of the buffer was > misaligned by just the wrong amount. The miscalculation would allow an > attacker to overflow a piece of heap-allocated memory. To mount this > attack, the attacker would need to either open a SOCKS connection to > Tor's SocksPort (usually restricted to localhost), or target a Tor > instance configured to make its connections through a SOCKS proxy > (which Tor does not do by default). > > Good security practice requires that all heap-overflow bugs should be > presumed to be exploitable until proven otherwise, so we are treating > this as a potential code execution attack. Please upgrade immediately! > This bug does not affect bufferevents-based builds of Tor. Special > thanks to "Vektor" for reporting this issue to us! > > Tor 0.2.2.35 also fixes several bugs in previous versions, including > crash bugs for unusual configurations, and a long-term bug that > would prevent Tor from starting on Windows machines with draconian > AV software. > > With this release, we remind everyone that 0.2.0.x has reached its > formal end-of-life. Those Tor versions have many known flaws, and > nobody should be using them. You should upgrade -- ideally to the > 0.2.2.x series. If you're using a Linux or BSD and its packages are > obsolete, stop using those packages and upgrade anyway. > > The Tor 0.2.1.x series is also approaching its end-of-life: it will no > longer receive support after some time in early 2012. > > https://www.torproject.org/download/download > > Note that the tarball and git tags are signed by Nick Mathewson (gpg > key 165733EA) this time around. > > Changes in version 0.2.2.35 - 2011-12-16 > o Major bugfixes: > - Fix a heap overflow bug that could occur when trying to pull > data into the first chunk of a buffer, when that chunk had > already had some data drained from it. Fixes CVE-2011-2778; > bugfix on 0.2.0.16-alpha. Reported by "Vektor". > - Initialize Libevent with the EVENT_BASE_FLAG_NOLOCK flag enabled, so > that it doesn't attempt to allocate a socketpair. This could cause > some problems on Windows systems with overzealous firewalls. Fix for > bug 4457; workaround for Libevent versions 2.0.1-alpha through > 2.0.15-stable. > - If we mark an OR connection for close based on a cell we process, > don't process any further cells on it. We already avoid further > reads on marked-for-close connections, but now we also discard the > cells we'd already read. Fixes bug 4299; bugfix on 0.2.0.10-alpha, > which was the first version where we might mark a connection for > close based on processing a cell on it. > - Correctly sanity-check that we don't underflow on a memory > allocation (and then assert) for hidden service introduction > point decryption. Bug discovered by Dan Rosenberg. Fixes bug 4410; > bugfix on 0.2.1.5-alpha. > - Fix a memory leak when we check whether a hidden service > descriptor has any usable introduction points left. Fixes bug > 4424. Bugfix on 0.2.2.25-alpha. > - Don't crash when we're running as a relay and don't have a GeoIP > file. Bugfix on 0.2.2.34; fixes bug 4340. This backports a fix > we've had in the 0.2.3.x branch already. > - When running as a client, do not print a misleading (and plain > wrong) log message that we're collecting "directory request" > statistics: clients don't collect statistics. Also don't create a > useless (because empty) stats file in the stats/ directory. Fixes > bug 4353; bugfix on 0.2.2.34. > > o Minor bugfixes: > - Detect failure to initialize Libevent. This fix provides better > detection for future instances of bug 4457. > - Avoid frequent calls to the fairly expensive cull_wedged_cpuworkers > function. This was eating up hideously large amounts of time on some > busy servers. Fixes bug 4518; bugfix on 0.0.9.8. > - Resolve an integer overflow bug in smartlist_ensure_capacity(). > Fixes bug 4230; bugfix on Tor 0.1.0.1-rc. Based on a patch by > Mansour Moufid. > - Don't warn about unused log_mutex in log.c when building with > --disable-threads using a recent GCC. Fixes bug 4437; bugfix on > 0.1.0.6-rc which introduced --disable-threads. > - When configuring, starting, or stopping an NT service, stop > immediately after the service configuration attempt has succeeded > or failed. Fixes bug 3963; bugfix on 0.2.0.7-alpha. > - When sending a NETINFO cell, include the original address > received for the other side, not its canonical address. Found > by "troll_un"; fixes bug 4349; bugfix on 0.2.0.10-alpha. > - Fix a typo in a hibernation-related log message. Fixes bug 4331; > bugfix on 0.2.2.23-alpha; found by "tmpname0901". > - Fix a memory leak in launch_direct_bridge_descriptor_fetch() that > occurred when a client tried to fetch a descriptor for a bridge > in ExcludeNodes. Fixes bug 4383; bugfix on 0.2.2.25-alpha. > - Backport fixes for a pair of compilation warnings on Windows. > Fixes bug 4521; bugfix on 0.2.2.28-beta and on 0.2.2.29-beta. > - If we had ever tried to call tor_addr_to_str on an address of > unknown type, we would have done a strdup on an uninitialized > buffer. Now we won't. Fixes bug 4529; bugfix on 0.2.1.3-alpha. > Reported by "troll_un". > - Correctly detect and handle transient lookup failures from > tor_addr_lookup. Fixes bug 4530; bugfix on 0.2.1.5-alpha. > Reported by "troll_un". > - Fix null-pointer access that could occur if TLS allocation failed. > Fixes bug 4531; bugfix on 0.2.0.20-rc. Found by "troll_un". > - Use tor_socket_t type for listener argument to accept(). Fixes bug > 4535; bugfix on 0.2.2.28-beta. Found by "troll_un". > > o Minor features: > - Add two new config options for directory authorities: > AuthDirFastGuarantee sets a bandwidth threshold for guaranteeing the > Fast flag, and AuthDirGuardBWGuarantee sets a bandwidth threshold > that is always sufficient to satisfy the bandwidth requirement for > the Guard flag. Now it will be easier for researchers to simulate > Tor networks with different values. Resolves ticket 4484. > - When Tor ignores a hidden service specified in its configuration, > include the hidden service's directory in the warning message. > Previously, we would only tell the user that some hidden service > was ignored. Bugfix on 0.0.6; fixes bug 4426. > - Update to the December 6 2011 Maxmind GeoLite Country database. > > o Packaging changes: > - Make it easier to automate expert package builds on Windows, > by removing an absolute path from makensis.exe command. > > > > > _______________________________________________ > tor-announce mailing list > tor-announce(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce

1 0