ENHANCEMENT: Extending Gateway Functionality with Plugins

[c107886]

Hi RA, I thought I'd go ahead and suggest a couple of ideas here since the blog seems to be down at the moment.

I think it would be of great value to have the gateway extensible, by being able to support add-ons or plugins such as Obfsproxy and the recently introduced SkypeMorph. These plugins allow users to be able to combat Tor blocking and would be greatly valuable.

IMO It would be very important for people in countries that actively censor Tor to be able to hide their Tor usage.

More about SkypeMorph here:
cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf

Thanks again,

Eli

[ra--]

Making contributions easier through some kind of plugin-extensions sounds like a good idea to me. Currently the "easiest" way IMHO is to provide packages for OpenWRT in opkg[0] format which can be downloaded and installed. Do you think that this would be sufficient? I could set up a repository for hosting these packages - maybe even the "fast gateway" could be implemented this way.

The paper you referenced sounds very interesting.k

Thanks for posting your ideas here.

[0] https://code.google.com/p/opkg/

[c107886]

Yes, IMO this would ensure that gateway has a modular and clean implementation over time. Anything besides the core functionality would be an optional download in the form of a package. Another good thing that comes out of this is that if some plugins become outdated they could be individually updated without having to recompile the entire gateway app when there are no changes to the core distro or Tor.

But this leaves some questions to consider: Would these packages be maintained here by you or by the OpenWRT project? Could there be a way to automatically also keep those updated over time, instead of you having to do it manually? This could save a lot of effort and allow you to focus on new features.

As for the Fast Gateway, I was wondering if it could be presented as an internal mode of functionality within the Gateway itself where the user could switch to it by simply pressing a command number. If the regular and fast gateway are fundamentally different in design then the separate package idea is a great approach to take instead.
This brings me to the next suggestion: It would be easier to use the gateway and its added functions if they could be mapped to command numbers in the way pfSense does it, like this pic:
http://www.windowsitpro.com/content/content/100196/Figure1.jpg

I appreciate your work on this and your willingness in looking into these ideas.

---

ADDITION:
Relating to the last point about the command menu: I found what appears to be a minimalistic vidalia interface drop in, under the Arm -Anonymizing Relay Monitor - project found here:

https://www.torproject.org/projects/arm.html.en
http://www.atagar.com/arm/

It seems that the TorBox project intends to use it starting with their latest alpha and up. The problem is however that the Arm project is a one man gig - which isn't necessarily a problem until he made it clear that the code was very buggy and unstable - which can produce exploits from a security point of view.

I posted it so you can have an idea of how to do a similar implementation of a simpler command menu to accomodate any new functions that will be added. IMO you should avoid incorporating it if you can, as to keep with the principal of a minimal code base/ Trusted Computing Base, to keep attack surface as small as possible.

PS. I gave TorBox another test run when I saw the latest comments on your blog. I managed to get it to bootup by enabling the PAE/NX option, however the workstation still cannot connect to the internet. Its still a bloated fat pig nearing 200mb. I wonder what they put in there that makes it so big. How exactly are they attempting to stick with the idea that less code is safer? hm.

Anyway good job Ra. I can't wait to see what you have planned for this project.

[atagar]

The problem is however that the Arm project is a one man gig - which isn't necessarily a problem until he made it clear that the code was very buggy and unstable - which can produce exploits from a security point of view.

Wtf? Speaking as the "one man gig", citation please. Arm has a single rather substantial bug that I'm still trying to figure out [1], but besides that it's very stable and one of the best maintained projects we have. I don't generally keep an eye on GitHub so if you have an issue in the future with arm then please either file a trac ticket or send me an email.

-Damian ([email protected])

[1] https://trac.torproject.org/6439
^ you can simply use an older version if this concerns you, it's most likely a problem due to arm's new interpretor panel

[c107886]

@ Damian I appreciate the feedback and what you do for Tor. I apologize for the abrasive remarks in retrospect.
At the time I assumed that the number of bugfixes in the listed in the release log indicated that the software wasn't stable yet: http://www.atagar.com/arm/releaseNotes.php
I also misunderstood what you said in the release log for version 1.4.5 as a disclaimer for use in high availability scenarios. I will be sure to report any issues to you if any arise.

[c107886]

Ra, I found the makefiles for obfsproxy and arm in the Openwrt repo, so I thought that they might make things easier to add them into the package:

-- obfsproxy:
https://dev.openwrt.org/ticket/10947 << (obfsproxy works with Tor 0.2.3.11-alpha or later)
https://dev.openwrt.org/changeset/30430

-- arm
https://dev.openwrt.org/changeset/32722/

EDIT: obfsproxy is now inlcuded under the Attitude Adjustment package repo. Not sure about arm though, although it could be integrated and built separately.