March 2014 - tor-dev - lists.torproject.org

[RELEASE] Torsocks 2.0.0-rc4
by David Goulet 04 Mar '14

04 Mar '14

Hi everyone! After a big code review from Nick and help from a lot of people contributing and testing, this is the release candidate 4 for the new torsocks. Hopefully this is the last stretched before pushing this effort upstream but for that we need help with code/documentation review (again) and of course more and more testing! Multiple Signed-off on the code would be great so please go at it, ask questions, contribute! and let's make this new Torsocks awesomer! :) Some pointers on critical part of the code. --> src/lib/connect.c and close.c --> src/lib/getaddrinfo.c and gethostbyname.c --> src/lib/torsocks.c Also see the configuration file that has changed. --> doc/torsocks.conf If you are on OS X or/and BSD, please help make it work on those platforms. It's quite easy to break compatibility thus help make sure we didn't break it up :). https://github.com/dgoulet/torsocks.git Tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc4.tar.gz Big thanks to all! David

5 7

(no subject)
by Samual Carman 04 Mar '14

04 Mar '14

-- hello i have some questioner regarding helping the development of tor contact me off list if possible thank yuo the wyer

1 0

Search Engine for Hidden services
by Prakash kumar 03 Mar '14

03 Mar '14

Sir I am Prakash kumar from G. B. Pant Engineering College, Delhi, India.I am a 2nd year computer science and engineering student. I want to work on the idea "search engine for hidden services". I have a basic knowledge of how search engines work. I want to know which language we will use for this project. And also what is the next step from here? Please guide me. github: github.com/prakash09 facebook:https://www.facebook.com/prakashkumar09 Thank you Regards, Prakash Kumar

1 0

IRC meeting on Fri, Mar 7, 17:00 UTC to discuss TIMB's next external milestone
by Karsten Loesing 03 Mar '14

03 Mar '14

Hi everyone, we're going to have an IRC meeting to discuss next steps for the Tor Instant Messaging Bundle (TIMB): Friday, March 7, at 17:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140307T17 The main topic will be the upcoming external milestone on March 31, 2014 and what we hope to have achieved by then. We'll also talk about (ab-)using Trac as project management system for this project. If people want to read up on what this is all about, here's the current wiki page for this project: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB Talk to you on Friday! Volunteers welcome! All the best, Karsten

1 0

Proposal 228: Cross-certifying identity keys with onion keys
by Nick Mathewson 03 Mar '14

03 Mar '14

Here's a proposal that's been kicking around on my laptop for a while. I cleaned it up to use the revised certificate format from the revised proposal 220. My math and crypto claims might be incorrect here; I'm sure hoping somebody will tell me if they are. Filename: 228-cross-certification-onionkeys.txt Title: Cross-certifying identity keys with onion keys Author: Nick Mathewson Created: 25 February 2014 Status: Open 0. Abstract In current Tor router descriptor designs, routers prove ownership of an identity key (by signing the router descriptors), but not of their onion keys. This document describes a method for them to do so. 1. Introduction. Signing router descriptors with identity keys prevents attackers from impersonating a server and advertising their own onion keys and IP addresses. That's good. But there's nothing in Tor right now that effectively stops you (an attacker) from listing somebody else's public onion key in your descriptor. If you do, you can't actually recover any keys negotiated using that key, and you can't MITM circuits made with that key (since you don't have the private key). You _could_ do something weird in the TAP protocol where you . Nonetheless, it's probably undesirable that this is possible at all. Just because it isn't obvious today how to exploit this doesn't mean it will never be possible. 2. Cross-certifying identities with onion keys 2.1. What to certify Once proposal 220 is implemented, we'll sign our Ed25519 identity key as described in proposal 220. Since the Ed25519 identity key certifies the RSA key, there's no strict need to certify both separately. On the other hand, this proposal may be implemented before proposal 220. If it is, we'll need a way for it to certify the RSA1024 key too. 2.2. TAP onion keys We add to each router descriptor a new element, "onion-key-crosscert", containing a RSA signature of: A SHA1 hash of the identity key [20 bytes] The Ed25519 identity key, if any [32 bytes] If there is no ed25519 identity key, or if in some future version there is no RSA identity key, the corresponding field must be zero-filled. Parties verifying this signature MUST allow additional data beyond the 52 bytes listed above. 2.3. ntor onion keys Here, we need to convert the ntor key to an ed25519 key for signing. See the appendix A for how to do that. We'll also need to transmit a sign bit. We can add an element "ntor-onion-key-crosscert", containing an Ed25519 certificate in the format from proposal 220 section 2.1, with a sign indicator to indicate which ed25519 public key to use to check the key: "ntor-onion-key-crosscert" SP SIGNBIT SP CERT NL SIGNBIT = "0" / "1" Note that this cert format has 32 bytes of of redundant data, since it includes the identity key an extra time. That seems okay to me. The TYPE field in this certificate should be set to [0A] - ntor onion key cross-certifying ntor identity key 3. Authority behavior Authorities should reject any router descriptor with an invalid onion-key-crosscert element or ntor-onion-key-crosscert element. Both elements should be required on any cert containing an ed25519 identity key. See section 3.1 of proposal 220 for rules requiring routers to eventually have ed25519 keys. 4. Performance impact Routers do not generate new descriptors frequently enough for them to need to Checking an extra ed25519 signature when parsing a descriptor is very cheap, since we can use batch signature checking. The point decompression algorithm will require us to calculate 1/(u+1), which costs as much as an exponentiation in GF(2^255-19). Checking an RSA1024 signature is also cheap, since we use small public exponents. Adding an extra RSA signature and an extra ed25519 signature to each descriptor will make each descriptor, after compression, about 128+100 bytes longer. (Compressed base64-encoded random bytes are about as long as the original random bytes.) Most clients don't download raw descriptors, though, so it shouldn't matter too much. A. Converting a curve25519 public key to an ed25519 public key Given a curve25519 x-coordinate (u), we can get the y coordinate of the ed25519 key using y = (u-1)/(u+1) and then we can apply the usual ed25519 point decomporession algorithm to find the x coordinate of the ed25519 point to check signatures with. Note that we need the sign of the X coordinate to do this operation; otherwise, we'll have two possible X coordinates that might have correspond to the key. Therefore, we need the 'sign' of the X coordinate, as used by the ed25519 key expansion algorithm. To get the sign, the easiest way is to take the same private key, feed it to the ed25519 public key generation algorithm, and see what the sign is. B. Security notes It would be very bad for security if we provided a diffie-hellman oracle for our curve25519 ntor keys. Fortunately, we don't, since nobody else can influence the certificate contents.

4 4

Weekly Tor dev meeting: Wednesday March 5, 20:00 UTC
by Nick Mathewson 03 Mar '14

03 Mar '14

Hi, all! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) Unlike last week, we're going to try doing the weekly meeting on Wednesday, so it can go right after the TBB meeting. Also, I'm going to say the date and time again in my message body, so that people who skim over the subject line can find it: Wednesday March 5, 20:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

1 0

HOWTO use Lantern as a pluggable transport
by David Fifield 03 Mar '14

03 Mar '14

I met today with some developers of Lantern (https://getlantern.org/, https://github.com/getlantern/lantern) Lantern acts as an HTTP proxy and proxies your traffic through trusted friends. We found that we had the pieces necessary to make Lantern a pluggable transport of Tor; that is, use Lantern as a transport for Tor traffic where Tor is blocked but Lantern is not. Here's what we did to make it work. Lantern is an HTTP proxy. As luck would have it, I have lately been working on a transport that encodes data in HTTP requests (https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html) meek was designed for a completely different purpose--tunneling traffic through App Engine--but it turned out to be almost perfect for the Lantern case, too. The only thing it was missing was support for an upstream HTTP proxy. We used the attached patch to add proxy support and hardcode Lantern's proxy port of 8787. meek normally connects to App Engine, and uses a TLS trick to make it look like it is going to www.google.com. The meek-client program connects App Engine, and then App Engine forwards traffic to the bridge. The configuration looks like this: ClientTransportPlugin meek exec meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com With Lantern it's a bit different. We don't need to do the TLS fronting trick because we use Lantern as an opaque HTTP-carrying transport. Instead of going through App Engine, we tell meek-client to make requests directly to the Tor bridge (where "directly" means "directly through the Lantern proxy"). ClientTransportPlugin meek exec meek-client --url=http://tor1.bamsoftware.com:7002/ And that's all. We downloaded one of the experimental meek bundles from https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-1/, copied in the patched meek-client binary, and made the above change to the ClientTransportPlugin line in torrc-defaults. With Lantern already running and configured on the same machine, we started tor and it bootstrapped. I'll take the proxy patch and modify it so that the proxy address is not hardcoded, so that you can configure it from the command line. It could also be useful for users who need pluggable transports but are stuck behind an HTTP proxy. Special thanks to Ox from Lantern who pair-programmed this with me. David Fifield

1 1

How to test Linux capabilities & pluggable transports
by George Kadianakis 02 Mar '14

02 Mar '14

Hello David, the other day you asked for a quick way to test Linux capabilities and pluggable transports (to combine #7875 and #8195). What you probably want to do, is write a small script that prints the active Linux capabilities, spawn it as a pluggable transport, and check its output to see if the capabilities we wanted it to inherit are active. Here is an example of how to do this. I'm using a python script here, but you can do whatever you want. Use this torrc (only the final line really matters): """ SocksPort 0 ORPort 6666 BridgeRelay 1 PublishServerDescriptor 0 ServerTransportPlugin cap exec /usr/bin/python /home/user/cap.py """ where cap.py can be: """ #!/usr/bin/python print "test test" """ If you start up tor with that torrc ($ ./src/or/tor -f my_torrc), you will get: """ Mar 02 12:54:43.000 [notice] Unknown line received by managed proxy (test test). """ in your Tor output. You can use these lines to debug your capabilities. Otherwise, you can log to a file and read that file instead. Of course in cap.py, you will probably want to print your capabilities, or bind to a port < 1024, or something like that. Feel free to ask any questions you have.

1 0

Call for testing/review: obfsclient-0.0.1rc1
by Yawning Angel 02 Mar '14

02 Mar '14

Hello all, Due to a moment of surprising productivity, I have a release candidate of obfsclient available now. For those of you that missed the last thread regarding this, it is a C++11 client implementation of obfs2, obfs3, and ScrambleSuit that works as a drop in replacement for obfsproxy. Notable changes since the last time I posted: * ScrambleSuit code is now up to spec. * Packet length and Inter-packet Arrival Times are randomized. * Session Ticket Handshake is supported. * obfsclient will give up on handshaking after 60 seconds. * Needed because obfsproxy servers do not close the connection for certain protocols. * SIGINT is hooked and handled per the pt spec. * Some dumb bugs were fixed. Places where obfsclient behaves differently from obfsproxy: * Current production obfsproxy releases disable Scramblesuit IAT obfuscation. obfsclient also uses slightly different logic for sending with it enabled. (May change for final release) * WELL512 is used instead of MT for the ScrambleSuit packet length obfuscation. * obfsclient gives up when the handshaking stalls. * The SOCKS5 response is sent post obfuscation protocol handshake instead of before. * obfsclient uses SOCKS5 instead of SOCKS4. * The ScrambleSuit Session Ticket store is a plain text file. Things that are not bugs: * ScrambleSuit requires the client side tor to be 0.2.5.x. * The code will not build if the compiler is from the stone age. To what I assume will be a sigh of relief from Fabian, I tested on FreeBSD as well this time. The systems used for testing are in the release notes. Where: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1-rc1 Thanks in advance, -- Yawning Angel

3 4

Damian's Status Report - February 2014
by Damian Johnson 02 Mar '14

02 Mar '14

It was great meeting everyone in Reykjavík! February largely went toward GSoC prep. Thanks to everybody that sent me project ideas! https://blog.torproject.org/blog/tor-google-summer-code-2014 This left a lot less time than I'd like for coding. The only noteworthy changes this month were... * Added a new 'stem.util.test_tools' module for easily running Pyflakes and PEP8 checks... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/util/test_tools.py Stem, ExitMap, and arm all do these checks as part of their tests so this let them shed quite a bit of boilerplate. Want these checks for your own project? It's easy, so give it a try! https://gitweb.torproject.org/user/atagar/exitmap.git/blob/HEAD:/run_tests.… * Stem tutorial example for checking the Tor exits you're using for your connections... https://stem.torproject.org/tutorials/to_russia_with_love.html#determine-th… * Couple new Controller methods for checking where Tor is listening for connections of a given type... https://stem.torproject.org/api/control.html#stem.control.Listener https://stem.torproject.org/api/control.html#stem.control.Controller.get_po… https://stem.torproject.org/api/control.html#stem.control.Controller.get_li… >>> for listener_type in stem.control.Listener: ... ports = map(str, controller.get_ports(listener_type)) ... print "%s ports: %s" % (listener_type, ', '.join(ports)) ... OR ports: DIR ports: SOCKS ports: 9050 TRANS ports: NATD ports: DNS ports: CONTROL ports: 2779 * Gave Sphinx's aafig module a try to see if it could improve our API overviews... https://www.atagar.com/transfer/stem/overview_before.png https://www.atagar.com/transfer/stem/overview_after.png In the end I decided against it since this doesn't add much, and it causes us to render the overview as a svg (so users can't copy/paste function names). * Sent Philipp some improvements for ExitMap... https://lists.torproject.org/pipermail/tor-dev/2014-February/006162.html Cheers! -Damian

1 0