Re: [tor-talk] Cloak Tor Router

[Lars Boegild Thomsen <lth@xxxxxxxxxxxxxxxxxxxxxxxx>]

On Saturday 01 November 2014 12:42:41 coderman wrote:
> On 11/1/14, Lars Boegild Thomsen <lth@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> first question, did you contact Tor Project Inc. about this for their
> input? (if yes, what was their take on your aims?)

No, we haven't done that yet apart from me trying to start this discussion here on the mailing list (which is the recommended way according to https://www.torproject.org/about/contact.html.en).  I (and Adrian - the project leader on Kickstarter) will be happy to engage in any discussion on or off list.

> > The first step was to isolate the Tor/Cloak related stuff from my internal
> > source tree and actually put a builtable source online on Github. That is
> > currently available here: https://github.com/ReclaimYourPrivacy.
> the majority of these repositories are forks of existing public
> projects, but not clearly so. (e.g. cloak-routing is a selection of
> specific OpenWRT packages, eschalot, etc.)

Some of them (currently cloak, cloak-luci, cloak-packages) are forks with changes, cloak-management and cloak-routing are not modified and cloak-cloak (yeah I know - that one came out silly) is addons that are not part of OpenWrt or override something in OpenWrt.  I have added a note on each repository that clearly states the upstream.

> what do you think of branching from upstream repositories, and keeping
> your changes in a manner that upstream would be encouraged to
> incorporate?

That would be the preferred approach except:

1. When I started working with OpenWrt they still used Subversion with NO git interface.

2. The main OpenWrt git repository is still hosted on git.openwrt.org and not on Github.

In fact they only moved to Github a few month back (I think Luci is about a month back).

I have contributed a bit of code to OpenWrt in the past and believe me I wish they would accept pull requests.  They don't - they expect a patch on a mailing list.  So yes, the current approach is not ideal at all but is a result of some legacy (as in OpenWrt using Subversion until not long ago) and perhaps also my own struggles with Git (I have used Git for a couple of years and it still messes with my brain occasionally).

I regard Cloak as 100 % Open Source and it will remain so.  As long as I am the only one working on it I guess it will run in the best way I can think of.  If more people want to join or contribute in that development that approach can and will be adjusted as better options show up.

Just to clarify how I am currently working on Cloak:

1. My primary (origin) repository is an internal Git server (legacy from OpenWrt using Subversion)

2. I regularly pull/merge the official OpenWrt repositories into my own 

3. The branch master is pushed to Github

Currently it is really hard to keep up with OpenWrt as they are in a transition phase.  I actually think most will end up on Github and if/when it does I will probably make a proper fork on Github and use those as primary repositories.

> i have more feedback on code itself, but this is foremost to mention.

You are welcome!

> > Second step was to document the hardware development to convince everybody
> > (hopefully) that we _are_ actually capable of having a device such as this
> > manufactured at a competitive price. Most of that documentation went on our
> > web-site (https://reclaim-your-privacy.com) and schematics/PCB design on
> > Github (same url as before).
> i approve of open hardware approach very much :)

As open as hardware can ever be :)  We were careful not to use the term "open source hardware" because it makes little sense.  Doing electronics is like a lego kit but there will always be parts where you have to trust the specifications from the supplier.

> perhaps useful to identify what is open (like PCB) and what is not (Atheros)

Thanx - that is a great suggestion and we will definitely do that.  The short story right here is:

Obviously you are _never_ going to get Qualcomm Atheros to provide their design details.  Same goes for all the other IC's (flash, RAM).

At this very moment there are some issues/unknowns regarding the Dragino HE module.  Schematics will be available but the PCB design probably not (working on a clear statement on that one).

Everything developed specifically for the Cloak device will be on Github - schematics and PCB.

Arduino Yun is suffering the same issue as the Dragino HE module - and that issue is Qualcomm Atheros insistance on NDA's for accessing their reference designs (it is known as AP121 - a google search for "ap121 ar9331" should provide tons of links to the schematics most in Chinese).

> > I had already (9 month back) come up with some sensible firewall rules that
> > would pretty much force all TCP traffic through Tor and since I had been
> > running it for 9 month it was at that time fairly well tested
> obviously this is not difficult, but it is also more complicated than
> just "some sensible rules". e.g.

No it is not complicated to make the rules, but it is somewhat complicated to determine which rules are the best balance between actually providing a degree of privacy and usability.

One example I have been thinking about a lot is my media player.  I've got a cheap as chips media player device connected to my TV an that device is actually quite chatty on the network.  It regularly phones home and it pull various data off the Internet - movie posters, descriptions, plots etc.  It can also be used with various online services - youtube for example.  Nowhere have I provided any login information.  I think for a device like that it makes sense just to force everything it tried to do on the Internet through Tor and pretty much let it do whatever it wants (since blocking some of the ports would probably render the device either useless or crippled).  That is obviously an extreme end of the possible use cases - a device that is more or less completely out of my control.

Another example I have mentioned in another mail is that I - while being Danish - have lived most of my life in countries that are - let's just say - significantly less democratic than Denmark.  In general I would say that there is a point in ensuring my Internet Service Provider hasn't got a clue what I am doing.  What they don't know they can't be forced to tell anyone.

The current version of the default configuration is simple - allow DNS but route through Tor, allow all TCP but route through Tor, disallow UDP.  That should probably be changed to a positive list instead - so specifically allow a list of services that benefit from being used through Tor.

One suggestion I could make is this.  Currently the Cloak defaults to two networks: open and cloaked.  The open one is - well - open.  The cloaked route all TCP traffic through Tor - end of.  How would it sound if we made 3 networks instead:

1. Open
2. Cloaked
3. Isolated

Where 1 and 2 were as now (perhaps with Cloaked a bit more locked down) and 3 only allowing https.  That combined of course with CLEAR documentation to the end user of the consequences of using either network.  That approach would be easy to implement, relatively easy to explain and offer a choice to the end user.

> > ... at that time we
> > could generate a random root password and WiFi key, flash that to a small
> > dedicated R/O partition on the flash, print it on a label attached to the
> > box (along with Serial number and MAC address).
> it would also be great if you could introduce some per-device unique
> entropy seed, obtained from a strong hardware based random number
> generator. (how better to signal your interest in utmost privacy, even
> if practical benefit is less concrete? :)

Now, that one is interesting!  And that is definitely something we could easily do (provided of course we get funded on Kickstarter which to be fair doesn't look all that promising at the moment).  I think - and I hope you will agree with me - that this is not worth spending a fortune on.  There _are_ xxxx certified random generator IC's out there, but they would probably double the cost of the device and you would still have to trust the vendor (and trust that we don't get screwed somewhere in the supply chain and end up with a Chinese fake).  Some approaches (that could all easily be achived within the current budget without adding significant cost to the device):

1. A random key is generated at production time from a well defined and generally accepted source and written to the read-only partition in each device.  It will stay there for the life of the device but it will be unique and unpredictable for each device.  

2. Use the radio calibration data as seed.  At production time each device is calibrated to compensate for tolerances in various HF components.  I have yet to see two devices where this calibration data is exactly the same and it would certainly be very hard to predict it.  This data could be used to as seed - possibly combined with 1.

3. A White Noise on-board generator

There are multiple ways of doing this relatively simple typically based on a transistor base-emitter break down voltage or some random oscillator - examples:

http://holdenc.altervista.org/avalanche/
http://www.tonbandstimmen.de/evpmaker/random-bit-generator/index_e.htm
http://iank.org/trng.html

Again, none of these are true random number generators but they are certainly quite impossible to predict - especially combined with 1 and/or 2

I would love to implement any or all of these in the Cloak device but I will need some input on which method would be the best in relation to Tor.

> > First of all, I would like to hear more opinions about the value of a device
> > such as this.
> the concept of a portable Tor proxy hardware router that fits in your
> pocket is great, in my not so unbiased opinion :)

Now, that is a very very good start :)  I hope we (and others that might join this discussion) can reach a consensus on which balance between privacy and usability is the best.

> > I realize that most technically adept people will frown on a a
> > "toy" such as the Cloak,
> what technical people will frown on is the way the device is presented
> to users, and if users are placed into risk by technical errors.

I understand and appreciate that fully.

> > but this device is really not meant for anybody who
> > can install the Tor software on their own or someone who can install Tor on
> > a Rasberry Pi.
> that's fine; i believe it is possible to make a device that is
> transparently usable that also doesn't put users at needless risk, if
> that is what you are getting at.

That is exactly what I am getting at.  It would be next to impossible to make a solution that off-the-shelf would fit and/or suit all.  But the Cloak device is intended to be as open as possible and certainly fully documented (in English) with an Open Source firmware that anybody with the technical skills can modify to suit them perfectly.  The tricky part is to make a sensible default off-the-shelf setting that is suitable for those who do not know the details about Tor.

> the suggestions others have made that i second:
> - block accidental Tor over Tor setups.

This one is interesting in that I really didn't think of that at all.  I will need some input there.  Is that at all possible at a network level.  I would assume it's the bootstrap of Tor that needs to be prevented?

> - provide automated builds, so that users can keep their device up to
> date easily, or use a built-in mechanism to obtain and install the
> latest easily.

I was writing about this in an earlier email.  It is a little bit tricky for a device such as this.  I personally find it hard to accept the idea of fully automatic updates, but I am quite open for ideas on how to do this best.

> in general, some guidelines that me as a technical person would like to see:
> - the device should fail safe, rather than fail open: if i
> accidentally connect my friend's windows XP laptop to your device, it
> should block rather than allow all by default.
> - support robust stream isolation, beyond what may be default. perhaps
> IsolateDestAddr and IsolateByClientAddr on TransPort (this does not
> yet exist, but you could code it to the benefit of all Transparent
> proxy consumers :)

Unfortunately I don't think Tor itself would benefit from my coding skills :)

> from your kickstarter, "We commit to establish and operate new exit
> nodes, to ensure that we are pulling our weight. Tor is currently at
> approx 2000 users per exit node. For every 1000 devices we ship, we
> will establish a new dedicated exit node. "
> why the focus on number of exit nodes, instead of contributed exit
> capacity?  you're measuring the wrong thing here.

Ah that one.  My original thought was that the best approach would be to donate a percentage of each sales to the Tor Project and if that is the preferred way for the Tor Project AND the Kickstarter project is successful we can most certainly do that in the future.  Unfortunately that approach was probably not acceptable to Kickstarter (they specifically disallow contributing to charities and we simply didn't have the time to figure out if contributing to Tor Project was considered a charity or the Tor Project actually wanted this approach or not).

Another issue was/is a simple matter of economics.  When we realized that we needed to do something I immediately established one exit node.  The primary reason is to get experience running those.  I _know_ there will be bitching from the service provider, but I don't exactly know how much.  Based on anonabox we were absolutely paranoid NOT getting caught with our pants down in a lie, so we had to put a promise there that we were absolutely certain we could keep.  The message I had hoped to send with the above was: "We know that a device such as the Cloak will put an extra load on the Tor network and we have every intention of compensating for that extra load."

Have you got an estimate of the average exit capacity needed per Tor user?

> i have more feedback, but your responses to these questions will help
> me determine how much time i can contribute to an evaluation.

Every second is greatly appreciated!

-- 
Lars Boegild Thomsen
https://reclaim-your-privacy.com
Jabber/XMPP: lth@xxxxxxxxxxxxxxxxxxxxxxxx
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk