January 2012 - tor-dev - lists.torproject.org

DNS/DNSSEC resolving in Tor (PoC implementation)
by Ondrej Mikle 01 Feb '12

01 Feb '12

Hi, I decided to give it a shot in implementing full DNS/DNSSEC resolution support for Tor, here's the branch: https://github.com/hiviah/tor ATM the biggest limitation is that reply DNS packet must fit in a single cell (i.e. max size is RELAY_PAYLOAD_SIZE). How it's implemented: There's new command SOCKS_COMMAND_RESOLVE_FULL for SOCKS interface and new cells RELAY_COMMAND_RESOLVE(D)_FULL. The RESOLVE_FULL cell contains query string and RR-type, RESOLVED_FULL just the DNS packet in wire format. Resolving is implemented via libunbound on the relay's side, ldns parses packet on client's side. The tor-resolve now uses the new SOCKS command and accepts -t parameter with RR-type (numeric, default 1 - RR-type 'A'), e.g.: ./src/tools/tor-resolve -t 28 lupa.cz localhost:10050 Packet size: 319 Flags: qr: 1, aa: 0, tc: 0, rd: 1, cd: 0, ra: 1, ad: 1 -- Rcode: NOERROR -- Opcode: QUERY -- Question section lupa.cz. IN AAAA -- Answer section lupa.cz. 600 IN AAAA 2001:67c:68::7b lupa.cz. 600 IN RRSIG AAAA 5 2 600 20121022235305 20111023235305 8130 lupa.cz. wFdVqKCEh4Nmac3v5K9y6HT+aIBAtF4Q9QIqHjlAl/ljp4m5TKkgKCF083zFTMh0LqfwdODfQdSNTKAwO55hyw== -- Authority section lupa.cz. 600 IN NS ns.iinfo.cz. lupa.cz. 600 IN NS ns6.adminit.cz. lupa.cz. 600 IN RRSIG NS 5 2 600 20121022235305 20111023235305 8130 lupa.cz. SpqkpBlK1dzrfACHh3yfUp01Vr/w9qzVYQms4RDXNQZW1Hwr5WYMHIuGrFEgOOrjyg1vB01HENXJf4i2ISx51g== -- Additional section Other implementation notes: - some checks like whether private address is resolved are missing (also a whitelist of allowed RR-types might be implemented) - in the SOCKS5 request, RR-type is hacked onto port number - in SOCKS5 reply, high byte of length is hacked onto SOCKS5 reserved byte - libunbound supports async resolving, for now synchronous is used - there are more details, grep FIXDNS in code - Makefile.am's have -lldns and -lunbound hardwired - new code may not be pretty at some places (getting to know Tor code) Also, this seems to be a bug in relay.c:connection_edge_process_relay_cell_not_open(), the RELAY_COMMAND_RESOLVED case: answer_len = cell->payload[RELAY_HEADER_SIZE+1]; if (rh->length < 2 || answer_len+2>rh->length) {...} Payload is accessed before checking bounds. Ondrej

5 12

Improving the tests
by Esteban Manchado Velázquez 01 Feb '12

01 Feb '12

Hey guys, I wanted to try and help a bit, but I'm not exactly a C wizard or know much about networking code. However, I am an experienced developer, do understand C and have quite a bit of experience with automated testing. Luckily, according to https://www.torproject.org/getinvolved/volunteer.html.en#unitTesting, it seems you guys could use someone spending some time with the tests :-) I'm sure it's going to take me a while to get my head around the code and the tests, but I can give it a shot and see what happens. How do I get started? Any suggestions? -- Esteban

3 2

Fwd: Tor Transports
by K. Macy 30 Jan '12

30 Jan '12

I felt it premature to publicly discuss using my user level network stack as the basis for a tor transport given the number of potential candidates and the issues that I raise below. However, Sebastian felt strongly that it belongs on tor-dev. Cheers ---------- Forwarded message ---------- From: K. Macy <kmacy(a)freebsd.org> Date: Sat, Jan 21, 2012 at 3:05 PM Subject: Re: Tor Transports On Fri, Jan 20, 2012 at 11:35 PM, Steven Murdoch <Steven.Murdoch(a)cl.cam.ac.uk> wrote: > Hi All, > > One hop-by-hop transport protocol we will likely be considering for an alternative Tor transport is TCP, and Kip Macy (a FreeBSD developer, Cc'd) has been working on porting the FreeBSD network stack to userspace, with the Tor use-case in mind. Unlike many other attempts though, maintainability has been a primary concern, so we should be able to keep in sync with the FreeBSD stack with manageable effort. > > Another advantage of this approach is that we will get IPSec for free, which could be very useful if we decide DTLS is not the way to go. > > The FreeBSD network stack is extremely well tested, so we are in a good position from that respect. One downside is that the code size might be large (unless we can find a way to do some clever link-time optimization away of dead code). > > His code is here: http://gitorious.org/~kmm/freebsd/kmm-sandbox/commits/work/svn_trunk_libple… It obviously also supports SCTP to whatever extent that FreeBSD does. The author of the RFCs and of the reference SCTP stack on all operating systems except Linux is a FreeBSD committer. Another reason why I chose to take this approach is you get all of the kernel firewall bits "for free." Thus one could envision supporting transparent proxying in the application itself to allow for transparent Tor usage in an OS independent manner. I have a few additional comments to add to set expectations appropriately. 1) I have a prototype "safe" BPF API whereby an unprivileged application can only receive and send packets on a single or pre-specified set of IP addresses and only advertise its private stack's MAC address. Without this functionality one needs to either layer the stack on top of kernel UDP (perfectly reasonable approach, just requires writing another simple virtual NIC driver) or running as root, whereby plebeian networking becomes a misnomer - a patrician poseur as it were. Having even such a simple kernel module goes against the grain of Tor conventions of not doing anything as root (although configuring things like transparent proxying require a certain amount of futzing as root). 2) The libc shim is written with the idea that it overrides the relevant libc symbols by means of LD_PRELOAD. The library differentiates between "kernel descriptors" for files, unix sockets, or anything outside the scope of the network stack and "user descriptors". For example, when a kernel descriptor is passed to write() libplebnet will call _write() with the arguments and the call should functional as it normally does. 3) At this instant libplebnet does not support localhost communication over TCP/UDP. I believe that the most efficient way of supporting this would be by means of directing those packets to a tap device. 3) Without a (most likely) substantial amount of work to share user level network state across address spaces, the apache style (pre-)forked process with shared accept socket does not work. I have not given it any thought as I don't see a use case for it. 4) Stack configuration was, to my surprise at least, the biggest hurdle. The UNIX APIs for configuring network stack state are anything but user friendly. To enable continued use of the standard tools (ifconfig, route, arp, etc) I wrote a separate library called libplebconf which one would LD_PRELOAD with the pid of the the process to be configured set as an environment variable. At startup libplebnet creates a thread which listens on a unix socket at "/tmp/<pid>" and accepts as messages serialized system calls to the various configuration calls that the aforementioned programs use. To simplify things a bit I've added an additional environment variable with the path to an rc.conf which gets executed at startup to configure the process using libplebnet's ip and route. Most of this will be moot in the event that you choose to cut out layer 3 and interface directly between your L4 of choice and DTLS. I haven't given any thought to how to eliminate this complexity in the event that you choose to use FreeBSD's IPSEC. To avoid boring most readers I have kept the discussion rather superficial. Nonetheless, I hope that this missive clarifies matters more than it confuses them. Cheers, Kip

3 3

Fwd: Re: [tor-talk] Bridge: Why not just stateless TCP socket proxy / forwarders?
by Fabio Pietrosanti (naif) 30 Jan '12

30 Jan '12

Maybe this question is more appropriate for tor-dev mailing list? How to submit a certain IP:Port to BridgeDB without using Tor? -naif -------- Original Message -------- Subject: Re: [tor-talk] Bridge: Why not just stateless TCP socket proxy / forwarders? Date: Mon, 16 Jan 2012 09:29:41 +0100 From: Fabio Pietrosanti (naif) <lists(a)infosecurity.ch> To: tor-talk(a)lists.torproject.org On 1/15/12 11:54 PM, andrew(a)torproject.org wrote: > On Sun, Jan 15, 2012 at 04:58:56PM +0100, lists(a)infosecurity.ch wrote 0.3K bytes in 11 lines about: > : does Bridge really need to be Tor Servers? > : Why they can't be just be simpler TCP socket proxy? > > We've been through this already. ;) No, a bridge is > just a way to reach the tor network from a tor client, > it can be any proxy or tcp forwarder. I refer you to > https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses > again. Specifically, approach four and five. So, if a third party would like independently to: - develop a TCP forwarder (very simple code) - submit to the BridgeDB - decide to which host to connect back which would be the step do be done from technical standpoint of view? Because that way it would be possible for a lot of third party to develop very lightweight "Tor TCP Proxy" that doesn't have inside other than the basic logic to do the TCP Proxy. Is the availability for third party software/script for that goals considered? Tnx! -naif

2 1

Proposal 190: Password-based Bridge Client Authorization
by George Kadianakis 27 Jan '12

27 Jan '12

Filename: 190-password-bridge-authorization.txt Title: Password-based Bridge Client Authorization Author: George Kadianakis Created: 04 Nov 2011 Status: Open 1. Overview Proposals 187 and 189 introduced the AUTHORIZE and AUTHORIZED cells. Their purpose is to make bridge relays scanning resistant against censoring adversaries capable of probing hosts to observe whether they speak the Tor protocol. This proposal specifies a bridge client authorization scheme based on a shared password between the bridge user and bridge operator. 2. Motivation A proper bridge client authorization scheme should: - request information from a client that only an authorized bridge client would know. - ensure that the shared secret sent by the bridge client during the authorization can only be read and validated by the proper bridge relay. This is important since the v3 link handshake which authenticates the bridge to the client is carried out *after* the bridge client authorization, which means that when the AUTHORIZE cell is sent, the client might be actually speaking to a Man In The Middle. The bridge client authorization scheme presented in this proposal is based on a shared password and attempts to satisfy both of the above requirements. 3. Design If the AuthMethod of an AUTHORIZE cell is '0x1', the client wants to become authorized using a shared secret based on a password. The short name of this authorization scheme is 'BRIDGE_AUTH_PSK'. 3.1. Notation '||', denotes concatenation. 'HMAC(k, m)', is the Hash-based Message Authentication Code of message 'm' using 'k' as the secret key. 'H(m)', is a cryptographic hash function applied on a message 'm'. 'HASH_LEN', is the output size of the hash function 'H'. 3.2. Shared secret format A bridge client and a bridge relay willing to use this authorization scheme, should have already exchanged out-of-band (for example, during the bridge credentials exchange) a shared password. In this case, the shared secret of this scheme becomes: shared_secret = H( H(bridge_identity_key) || ":" || password) where: 'bridge_identity_key', is the PKCS#1 ASN1 encoding of the bridge's public identity key. '":"', is the colon character (0x3a in UTF-8). 'password', is the bridge password. 3.3. Password-based authorization AUTHORIZE cell format In password-based authorization, the MethodFields field of the AUTHORIZE cell becomes: 'HMAC(shared_secret, tls_cert)' [HASH_LEN octets] where: 'HMAC(shared_secret, tls_cert), is the HMAC construction of the TLS certificate of the bridge relay, using the shared secret of section 3.2 as the secret key. 3.4. Password-based authorization notes Bridge implementations MUST reject clients who provide malformed AUTHORIZE cells or HMAC values that do not verify the appropriate TLS certificate. Bridge implementations SHOULD provide an easy way to create and change the bridge shared secret. 3.5. Security arguments An adversary who does not know the 'shared_secret' of a bridge cannot construct an HMAC that verifies its TLS certificate when used with the correct 'shared_secret'. An adversary who attempts to MITM the TLS connection of a bridge user to steal the 'shared_secret' will instead steal an HMAC value created by the 'tls_cert' of the TLS certificate that the attacker used to MITM the TLS connection. Replaying that 'shared_secret' value to the actual bridge will fail to verify the correct 'tls_cert'. The two above paragraphs resolve the requirements of the 'Motivation' section. Furthermore, an adversary who compromises a bridge, steals the shared secret and attempts to replay it to other bridges of the same bridge operator will fail since each shared secret has a digest of the bridge's identity key baked in it. The bridge's identity key digest also serves as a salt to counter rainbow table precomputation attacks. 4. Tor implementation The Tor implementation of the above scheme uses SHA256 as the hash function 'H'. SHA256 also makes HASH_LEN equal to 32. 5. Discussion 5.1. Do we need more authorization schemes? Probably yes. The centuries-old problem with passwords is that humans can't get their passwords right. To avoid problems associated with the human condition, schemes based on public key cryptography and certificates can be used. A public and well tested protocol that can be used as the basis of a future authorization scheme is the SSH "publickey" authorization protocol. 5.2. What should actually happen when a bridge rejects an AUTHORIZE cell? When a bridge detects a badly formed or malicious AUTHORIZE cell, it should assume that the other side is an adversary scanning for bridges. The bridge should then act accordingly to avoid detection. This proposal does not try to specify how a bridge can avoid detection by an adversary. 6. Acknowledgements Without Nick Mathewson and Robert Ransom this proposal would actually be specifying a useless and broken authentication scheme. Thanks!

5 12

Simulating a slow connection
by Adam Katz 27 Jan '12

27 Jan '12

Hi all I've noticed the "Simulator for slow Internet connections " project on the volunteer page and I have relevant experience. Who can I contact to lend a hand?

4 7

Using Tor w/o GeoIP
by Nathan Freitas 23 Jan '12

23 Jan '12

Is it the geoip database only required if you are specifying Exit/Entrances nodes by country code? I am thinking about not fully unpacking it into Android storage, unless the user activates those option in Orbot. This will save quite a bit of internal storage space. Thanks! +n8fr8

2 3

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 21 Jan '12

21 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