- tor-dev - lists.torproject.org

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

14 Jan '12

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

2 2

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

11 Jan '12

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

3 5

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

10 Jan '12

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

1 0

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

08 Jan '12

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

2 1

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