- tor-dev - lists.torproject.org

unscribe
by 曹文明 01 Jan '12

01 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

BridgeDB IPv6 Support (!)
by Aaron 17 Dec '11

17 Dec '11

code is here: https://gitweb.torproject.org/user/aagbsn/bridgedb.git/shortlog/refs/heads/… running code is here: https://tor.extc.org/ and here (ipv6): https://tor.extc.org/ipv6 None of the bridges at these addresses are valid, except by coincidence. Any feedback or questions are very welcome. Thanks! --Aaron

1 0