- tor-dev - lists.torproject.org

Orbot's inclusion of Privoxy (was: [tor-commits] r24630: {} adding binaries to res/raw folder (in projects/android/trunk/Orbot/res: . raw))
by Fabian Keil 17 Apr '11

17 Apr '11

Nathan Freitas <nathan(a)freitas.net> wrote: > Author: n8fr8 > Date: 2011-04-15 16:38:53 +0000 (Fri, 15 Apr 2011) > New Revision: 24630 > Log: > adding binaries to res/raw folder > ___________________________________________________________________ > Added: svn:mime-type > + application/octet-stream > > Added: projects/android/trunk/Orbot/res/raw/privoxy > =================================================================== > (Binary files differ) This seems to be (or based on) Privoxy 3.0.12 released in 2009. What's the rationale for not using a more recent version? Is this vanilla Privoxy or are there any custom patches? I get the impression that you are currently distributing the Privoxy binary as part of Orbot without even mentioning the license. Is that correct, or am I missing something? > Property changes on: projects/android/trunk/Orbot/res/raw/privoxy > ___________________________________________________________________ > Added: svn:executable > + * > Added: svn:mime-type > + application/octet-stream > > Added: projects/android/trunk/Orbot/res/raw/privoxy_config > =================================================================== > --- projects/android/trunk/Orbot/res/raw/privoxy_config (rev 0) > +++ projects/android/trunk/Orbot/res/raw/privoxy_config 2011-04-15 16:38:53 UTC (rev 24630) > @@ -0,0 +1,27 @@ > +# Generally, this file goes in /etc/privoxy/config > +# > +# Tor listens as a SOCKS4a proxy here: > +forward-socks4a / 127.0.0.1:9050 . Privoxy 3.0.12 already supports SOCKS5 which allows superior error messages in case of connection failures. Note that this requires the templates to be available and according to https://trac.torproject.org/projects/tor/ticket/2168 at least some of them aren't. > +confdir /data/data/org.torproject.android > +logdir /data/data/org.torproject.android > +# actionsfile standard # Internal purpose, recommended > +#actionsfile default.action # Main actions file > +#actionsfile user.action # User customizations > +#filterfile default.filter > + > +# Don't log interesting things, only startup messages, warnings and errors > +#logfile logfile > +#jarfile jarfile FEATURE_COOKIE_JAR shouldn't be supported in the vanilla 3.0.12 release. It has been removed in 3.0.11 due to being useless. > +#debug 1 > +#debug 0 # show each GET/POST/CONNECT request debug 0 has no effect. > +#debug 4096 # Startup banner and warnings > +#debug 8192 # Errors - *we highly recommended enabling this* > + > +#user-manual /usr/share/doc/privoxy/user-manual > +listen-address 127.0.0.1:8118 > +toggle 1 > +accept-intercepted-requests 1 Are the iptables rules used documented somewhere? Did you run into any issues with Privoxy on Android in general? Are the considerations that lead to the use of Privoxy documented somewhere? Thanks Fabian

2 2

Re: [tor-dev] [tor-commits] r24618: {website} Update Vidalia's project page (website/trunk/projects/en)
by Fabian Keil 14 Apr '11

14 Apr '11

Tomas Touceda <chiiph(a)gentoo.org> wrote: > Author: chiiph > Date: 2011-04-13 19:55:14 +0000 (Wed, 13 Apr 2011) > New Revision: 24618 > > Modified: > website/trunk/projects/en/vidalia.wml > Log: > Update Vidalia's project page > > Modified: website/trunk/projects/en/vidalia.wml > =================================================================== > --- website/trunk/projects/en/vidalia.wml 2011-04-13 18:58:21 UTC (rev 24617) > +++ website/trunk/projects/en/vidalia.wml 2011-04-13 19:55:14 UTC (rev 24618) > @@ -55,26 +55,26 @@ > - <a href="../dist/vidalia/vidalia-0.2.10.tar.gz">Source Tarball</a> > - (<a href="../dist/vidalia/vidalia-0.2.10.tar.gz.asc">sig</a>) > + <a href="../dist/vidalia/vidalia-0.2.12.tar.gz">Source Tarball</a> > + (<a href="../dist/vidalia/vidalia-0.2.12.tar.gz.sig">sig</a>) > </li> I'm having trouble locating the new signing key. Any pointers? Thanks. Fabian

3 3

Request for website commit review
by Robert Ransom 13 Apr '11

13 Apr '11

Please review Tor Subversion commits 24619, 24620, and 24621, then update the website. Regarding r24619: This change should be self-explanatory. Regarding r24620: I confirmed Robert Hogan's OpenPGP fingerprint on <https://trac.torproject.org/projects/tor/ticket/2883>. Regarding r24621: I obtained Tomás Touceda's OpenPGP fingerprint from his Tor LDAP account request on <https://trac.torproject.org/projects/tor/ticket/2621>, and I verified that the key with that fingerprint signed the Git tag vidalia-0.2.12 in <git://git.torproject.org/vidalia.git> and the release tarball at <https://www.torproject.org/dist/vidalia/vidalia-0.2.12.tar.gz>. I believe that these changes are appropriate, but they need to be reviewed before they are put onto The Tor Project's website. Robert Ransom

1 0

Redirecting network traffic to tor
by rp 08 Apr '11

08 Apr '11

Hi, I've become interested in one problem stated on tor web pages which deals with redirecting all traffic to tor (in windows). Redirecting traffic to tor seems to seek the goal of preventing traffic leaks. Openvpn does it's tunneling by rerouting all traffic to virtual network device and by changing dns resolver to the one on the remote tunnel side. Using openvpn's code, there is one possible way to prevent trafic leaks - by initializing fake route for all network traffic except for tor's, so only tor traffic can leave to the network. To try it, I have written simple .so library, that is linked to openvpn and uses openvpn code to manipulate routes (and possibly dns settings). Library gets loaded with tor using LD_PRELOAD and hooks connect and close calls on sockets. It works in the following way: 1) default route is overriden with fake one - now no traffic except dns can leave (assuming dns server is default gateway) 2) with each tor's connect, a route is added so traffic is routed through old route and not fake one, on close call the route is deleted - now only tor traffic and dns can leave 3) dns is set up to use tor's resolver - now only tor traffic will leave (assuming dns is properly redirected) 4) local connections fe. from web browser to local privoxy and from local privoxy to tor socks proxy are working, so this could be in principle used to help user with web browser gain more safety. The drawback is that to manipulate routes, one needs admin privileges. But this shouldn't be a problem - LD_PRELOAD way of doing things was the fastest to try this out. Although this is rather crude, it should prevent traffic leaks. What do you think about this? Could it be to some use? I have already tested all points except number 3), which would need more work, so before it I have to ask for your opinions - whether this is a waste of time or not. Please let me know. Roman PS: sorry for the noise with messages to various lists - i've got somewhat excited that there is a possibility for me to help with something useful..

2 1

Nick+Roger IRC chat time for developers, next Tuesday+Wednesday, 2-6pm eastern
by Nick Mathewson 08 Apr '11

08 Apr '11

Hi, all! Frequently, developers (including Nick and Roger) block on having both Nick and Roger online at the same time. We're trying to solve this by scheduling time to make sure that we're online and available to work with others on stuff that's blocking on is. We'll be on the development IRC channel (#tor-dev on OFTC) on March 8 and 9, from 1400 to 1800 EST (1900-2300 UTC, if I can add right). If you're doing something developmenty that's blocking on one or both of us, please stop by and have a chat. peace, -- Nick

2 1

Improved circuit-setup protocol [was: Re: Designing and implementing improved circuit-setup protocol [was: GSoC 2011]]
by Nick Mathewson 08 Apr '11

08 Apr '11

On Thu, Mar 31, 2011 at 5:52 AM, Robert Ransom <rransom.8774(a)gmail.com> wrote: Hi! I'm going to wait on a full review of your create/extend proposal till it's done, but I though I could potentially answer some questions and offer some comments: 1) I think CREATE cells need to get a field asking for a specific way of handling RELAY cells. If we ever update the relay crypto (that is, the stuff described in 5.5 and 6.1 today) to do something other than AES128_CTR for the encryption, SHA1 for the digest, we'll need a way to ask for it. I suppose that we could do that via adding a new handshake type for a new desired link protocol, but it seems like the two could be more or less orthogonal. 2) I don't get the rationale behind the variable-length type names. Elsewhere in our protocol we'd just use a 1- or 2-byte type field. Do we win a lot by letting these be longer? 3) By convention, everything in our protocol is in "network" (big-endian) byte-order. 4) There needs to be an authenticated way for the client to know which handshake types and link specifier types a given node supports. This could be as simple as a series of statements like "Tor versions xyz and later will support handshake type Y", or as complex as advertising them in router descriptors. 5) I like the idea of separating the link specifiers from the handshake type in EXTENDED cells. 6) I also think it'd be smart to figure out the actual link specifier and handshake types that we want to move to before we decide that we are confident that this format is right. Those can be a different proposal, though. 7) Here's a first cut of what I think might go in a link specifier format: * V4Address -- an ipv4 address, set to 0 if there is no IPv4 address for the node [4 bytes] * V4ORPort [2 bytes] * V6Address -- an ipv6 address, set to 0 if there is no IPv6 address for the node [16 bytes] * V6ORPort [2 bytes] * SHA256 of RSA1024 identity key [32 bytes] When we decide what longer identity keys should look like, we can add a new link specifier format that supports those. 8) This is totally back-of-the-envelope stuff, but it might be a good starting point for crypto discussion. Here's a first cut of what I think might go in an improved RSA handshake: * First 8 bytes of the SHA256 hash of the onion key [8 bytes] (This is here so that onion key rotation can work without having to sometimes try the wrong onion key incorrectly.) * PK-encrypted: * Padding [PK_PAD_LEN bytes] * SHA256 hash of all remaining fields. [32 bytes] * Symmetric key seed [16 bytes] * The first part of g^x. [as much will fit in the PK-encrypted portion] * Symmetrically encrypted: * The rest of g^x. * 0 bytes for padding. Here's a first cut of what I think might go in a hypothetical diffie-hellman based handshake, for use with something like Curve25519. (I'm using g^x and g^y notation here as if this were diffie-hellman in Z_p, since I don't yet trust myself to write ECC stuff correctly. I'm assuming that the node's public onion key is g^x.) * SHA256 of all remaining fields. [32 bytes] * First 8 bytes of the SHA256 hash of the onion key (8 bytes) * g^y1 [DH_LEN bytes] * Encrypted using a symmetric key based on g^(x*y1): * g^y2 [DH_LEN bytes] * 0 bytes for padding In both cases, we'll want a new key derivation function. yrs, -- Nick

4 7

[Patch] src/test.c
by Gisle Vanem 07 Apr '11

07 Apr '11

I don't think it's a good idea to use hard-coded paths. Even in a test source-file. Easy patch: --- Git-latest\src\test\test.c Wed Mar 30 11:58:28 2011 +++ src\test\test.c Thu Mar 31 14:06:14 2011 @@ -86,7 +86,7 @@ #ifdef MS_WINDOWS // XXXX tor_snprintf(temp_dir, sizeof(temp_dir), - "c:\\windows\\temp\\tor_test_%d", (int)getpid()); + "%s\\tor_test_%d", getenv("TEMP"), (int)getpid()); r = mkdir(temp_dir); #else tor_snprintf(temp_dir, sizeof(temp_dir), "/tmp/tor_test_%d", (int) getpid()); ---------- --gv

3 5

Embedding Parrot in Tor as GSoC Project
by Jonathan "Duke" Leto 07 Apr '11

07 Apr '11

Howdy, Parrot recently added a GSoC proposal idea to embed Parrot into Tor. It would be great to get the feedback from Tor developers. Also, this could be under the Parrot or the Tor GSoC project, whichever makes the most sense. The proposal idea could use more detail, but the high-level view that I imagine is: 1) Allow Parrot to talk to libtor (this will use NCI - Native Call Interface) via PIR 2) Ability to create Parrot interpreter objects from within Tor via C 3) Write glue code for a High Level Language (HLL) to talk to libtor There are various HLL's to choose from: Lua, TCL, Perl 6, Winxed, NQP and others. Duke Thanks for your help, Duke [0] http://trac.parrot.org/parrot/wiki/GSoc2011 -- Jonathan "Duke" Leto jonathan(a)leto.net http://leto.net

4 6

GSoC - Torbutton for Thunderbird
by Sukhbir Singh 05 Apr '11

05 Apr '11

Hi! I am interested in participating in Google's Summer of Code this year and implementing the Torbutton equivalent for Thunderbird [0]. I have been discussing the project with Mike Perry and we feel that it is possible to implement this. The first step was removing the hostname Thunderbird puts in the outgoing message header, which we easily fixed. That gave us the initial motivation to pursue this further. There are a number of issue that still remain, however we feel that those can be easily worked out. We have put all probable solutions to Torbutton requirements from [1] in the attachment with this mail and are looking for your suggestions/ comments about this. We have not submitted an application for this to Google yet; I intend to do that after gauging the response towards this proposal from the mailing list. Let's hope that we can make this a success, -- Thanks, Sukhbir Singh [0] - https://www.torproject.org/getinvolved/volunteer.html.en#torbuttonForThunde… [1] - https://www.torproject.org/torbutton/en/design/#requirements Attachment - Plain text

2 1

Torbutton for Thunderbird
by Sukhbir Singh 04 Apr '11

04 Apr '11

Hi! I am interested in participating in Google's Summer of Code this year and implementing the Torbutton equivalent for Thunderbird [0]. I have been discussing the project with Mike Perry and we feel that it is possible to implement this. The first step was removing the hostname Thunderbird puts in the outgoing message header, which we easily fixed. That gave us the initial motivation to pursue this further. There are a number of issue that still remain, however we feel that those can be easily worked out. We have put all probable solutions to Torbutton requirements from [1] in the attachment with this mail and are looking for your suggestions/ comments about this. We have not submitted an application for this to Google yet; I intend to do that after gauging the response towards this proposal from the mailing list. Let's hope that we can make this a success, -- Thanks, Sukhbir Singh [0] - https://www.torproject.org/getinvolved/volunteer.html.en#torbuttonForThunde… [1] - https://www.torproject.org/torbutton/en/design/#requirements Attachment - Plain text

1 0