[tor-dev] The Torouter and the DreamPlug

[Jacob Appelbaum]

On Fri, Jun 10, 2011 at 3:54 PM, Runa A. Sandvik <runa.sandvik at gmail.com>wrote:

> On Fri, Jun 10, 2011 at 12:55 PM,  <andrew at torproject.org> wrote:
> > On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik at gmail.com wrote
> 2.9K bytes in 75 lines about:
> > : The whole point with the Torouter is to allow more people to run a
> > : bridge or a relay, so I see a web interface as something mandatory. So
> > : yeah, we'd have to make sure that the interface is secure.
> >
> > Right, so we have two torouters, an expert model which is the dreamplug,
> > and a non-expert model which is the excito.
> >
> > Experts use ssh and follow some instructions for configuring their
> > device.  Plus, they get some cheap hardware to do whatever else they
> > want to do with it.
>
> Do you think we should ship the plugs as they are, or should we
> re-flash and harden first?
>
>
I think we should re-flash with an OS that makes hardening a priority. We
should only harden the OS in the sense that we should strip out anything
that we do not require for our uses. Debian and Ubuntu both have compiler
hardening flags enabled by default but in general, I'd consider Ubuntu's
userspace to be proactively improved and their kernel ships with quite a few
security improvements. I'm not sure about the kernel status for Debian or
who is proactively working on security in Debian.

In either case, the very old version of Ubuntu on the DreamPlugs is worse
than modern Debian or modern Ubuntu; we should not ship the plugs without an
OS update at the *very* least.

I think that we should probably setup a hidden service on each one and
ensure that we can remotely administrate them with the consent of the
testers. This will help us to perhaps make some of these choices differently
down the road.

I think the user experience should be that they plug in the router, it
auto-configures the upstream firewall/NAT device if possible and that's it.
If the NAT device can't be configured, I propose we use some common ports so
that our instructions to people are basically generic and easy for everyone
to follow.

> Non-experts get the excito with the web interface: point, click,
> > configured, done.
> >
> > I have 10 dreamplugs with US power config arriving soon.  Once Excito
> > has their new version ready, we can get 10 of those.  Then we find 20
> > volunteers willing to test the default configs and provide feedback.  In
> > exchange, they get to help censored users and get free hardware.
>
> We should probably discuss how we want users to provide feedback and
> what kind of data we'd like to see (i.e. we want more feedback than
> just "yay, it works" or "it doesn't work and I'm giving up").
>
>
I think a mailing list and an open bug report or ten is a good idea. Also, a
wiki page that explains how the devices operate from a user perspective.
This page should be different from the how-we-build-it wiki page.


> > Rather than arguing about web interfaces that do not exist, we should be
> > figuring out how to update the routers, make sure new tor packages are
> > updated timely, and how to handle support issues from the simple "it
> > doesn't work, at all" through "your router ate my cat and soured my
> > milk".
>
> We're going to need a web interface sooner or later, and I guess users
> will also start asking about client mode and a hidden service at some
> point. But we don't need all that to kick off the test phase.
>
>
Well, I think we can easily push out a wifi network that is transparently
sent via Tor and if users want that, we can provide it easily. I do not
think we should offer a remote client other than this without some security
discussions.

Again, I think we should enable OpenSSH on localhost and add a hidden
service to connect to it. This should enable us to remotely test things on a
router and see where it fails.

We don't need a web service when we launch, although I do believe it is good
to discuss the requirements.


> How to update the routers:
>
> - Excito: they roll out their own software updates and users can
> point-and-click to update via the interface.
>
>
They do not yet have a Tor package with tor-fw-helper, we need to make some
packages of 0.2.3.x for this to happen, I think. Perhaps weasel can tell us
of the best way to make this happen? I suspect we'll need to use a B3 device
as a build machine and we'll also need the explicitly have packages for
these devices.


> - DreamPlug: good question, I wonder if users would have to re-flash
> with a new image.
>

The users should not do anything about re-flashing. We will have about two
dozen and we should just reflash them, it's easy.


>
> Make sure new Tor packages are updated timely:
>
> - Excito: we'll need to drop them an email whenever there are new
> packages available so that they can update the Excito package repo.
> Users can also add the torproject Debian repo to their
> /etc/apt/sources.list if they don't want to wait for Excito.
>
>
I think we should ask Excito to ship with our repo or commit to pulling in
our packages for their repo. Will they do this?


> - DreamPlug: default OS is Ubuntu, so I guess users will want to add
> the torproject Debian repo to their /etc/apt/sources.list. Or we can
> do it for them.
>
>
The user should not consider this a general purpose Ubuntu device, they
should consider it a Tor bridge/router device that happens to run Ubuntu or
Debian. We should configure it for them and they shouldn't have to think
about it beyond perhaps removing bandwidth limits. :-)

We should probably include apticron and automatically update packages on
these routers. I trust the Debian Q&A process and I do not believe it will
result in bricked routers; anything less will result in a lot of collective
sysadmin time that none of us have and that we should not expect our users
to even comprehend unless they *want* to understand it.

How to handle support issues:
>
> We should probably set up a mailing list, such as torouter at lists... I
> already have a B3 and a DreamPlug, so I should be able to reply to
> most (if not all) of the support requests.
>
>
That sounds good. I will also help with this list.

All the best,
Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110610/ced602c6/attachment-0001.htm>