- tor-dev - lists.torproject.org

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 24 Dec '11

24 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 24 Dec '11

24 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