Fwd: [tor-talk] Cloak Tor Router

coderman coderman at gmail.com
Sat Nov 1 12:45:26 PDT 2014


---------- Forwarded message ----------
From: coderman <coderman at gmail.com>
Date: Sat, 1 Nov 2014 12:42:41 -0700
Subject: Re: [tor-talk] Cloak Tor Router

On 11/1/14, Lars Boegild Thomsen <lth at reclaim-your-privacy.com> wrote:
> ... We - the team behind Cloak - and me (the
> networking and embedded Linux guy in the team) are genuinely concerned about
> privacy and we really would like this product to ...

first question, did you contact Tor Project Inc. about this for their
input? (if yes, what was their take on your aims?)



> 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.)

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

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



> 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 :)

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



> 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.
https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy and
iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP and all the
other intricacies...



> ... 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? :)


> 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 :)


> 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.


> 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.

the suggestions others have made that i second:
- block accidental Tor over Tor setups.
- provide a Tor Browser on the supported platforms with TOR_TRANSPROXY=1
- 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.

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 :)

---

regarding your other information:

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.

---

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

best regards,



More information about the cypherpunks mailing list