The Torouter and the DreamPlug
Hi everyone, DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong. When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1. If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line. Thoughts? Comments? Thanks, -- Runa A. Sandvik
On Sat, May 28, 2011 at 11:52 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
When the SheevaPlug came out a couple of years ago, it shipped with a
web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
That's great news. A complex web app is just a giant PITA and huge attack surface anyhow.
If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Thoughts? Comments?
The Freedombox will likely run on the dream plug, it's the reference platform. I think we should work on ensuring that if we ship a dream plug, we ship a freedombox pre-configured to run Tor - this will likely be the case with the FB anyway: http://wiki.debian.org/FreedomBox Basically Tor needs some kind of webui package in Debian and we'd be good to go. All the best from Egypt, Jake
On Mon, May 30, 2011 at 12:21 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Sat, May 28, 2011 at 11:52 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
That's great news. A complex web app is just a giant PITA and huge attack surface anyhow.
Yeah, that's true.
If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Users who aren't familiar with the command line will probably still have a problem configuring Tor. I think that a webui package in Debian/Ubuntu is the best way to go.
Thoughts? Comments?
The Freedombox will likely run on the dream plug, it's the reference platform. I think we should work on ensuring that if we ship a dream plug, we ship a freedombox pre-configured to run Tor - this will likely be the case with the FB anyway: http://wiki.debian.org/FreedomBox Basically Tor needs some kind of webui package in Debian and we'd be good to go.
Yep, sounds good. -- Runa A. Sandvik
On Mon, May 30, 2011 at 1:35 AM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
On Mon, May 30, 2011 at 12:21 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Sat, May 28, 2011 at 11:52 PM, Runa A. Sandvik < runa.sandvik@gmail.com> wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
That's great news. A complex web app is just a giant PITA and huge attack surface anyhow.
Yeah, that's true.
If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Users who aren't familiar with the command line will probably still have a problem configuring Tor. I think that a webui package in Debian/Ubuntu is the best way to go.
Why would they have to configure anything on our router? They just need to open a port or let it happen automatically, right?
Thoughts? Comments?
The Freedombox will likely run on the dream plug, it's the reference platform. I think we should work on ensuring that if we ship a dream plug, we ship a freedombox pre-configured to run Tor - this will likely be the case with the FB anyway: http://wiki.debian.org/FreedomBox Basically Tor needs some kind of webui package in Debian and we'd be good to go.
Yep, sounds good.
-- Runa A. Sandvik _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Mon, May 30, 2011 at 12:45 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Mon, May 30, 2011 at 1:35 AM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Mon, May 30, 2011 at 12:21 AM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Sat, May 28, 2011 at 11:52 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
That's great news. A complex web app is just a giant PITA and huge attack surface anyhow.
Yeah, that's true.
If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Users who aren't familiar with the command line will probably still have a problem configuring Tor. I think that a webui package in Debian/Ubuntu is the best way to go.
Why would they have to configure anything on our router? They just need to open a port or let it happen automatically, right?
We should at least give our users the option of running a private / public bridge, non-exit relay or exit relay, just like on the Excito B3.
Thoughts? Comments?
The Freedombox will likely run on the dream plug, it's the reference platform. I think we should work on ensuring that if we ship a dream plug, we ship a freedombox pre-configured to run Tor - this will likely be the case with the FB anyway: http://wiki.debian.org/FreedomBox Basically Tor needs some kind of webui package in Debian and we'd be good to go.
Yep, sounds good.
-- Runa A. Sandvik _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-- Runa A. Sandvik
Hi, Runa A. Sandvik wrote (29 May 2011 23:35:24 GMT) :
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Users who aren't familiar with the command line will probably still have a problem configuring Tor. I think that a webui package in Debian/Ubuntu is the best way to go.
Here are my 2cts of the day. /etc/tor/torrc is currently shipped as a conffile by the Tor Debian package. This means it's a bit hard to edit it programmatically while ensuring painful and robust upgrade paths. If the configuration bits that are relevant to Torouter were managed using debconf (and possibly ucf), not only the webui's job would be a bit easier to do, but other Debian derivatives (such as the FreedomBox and Tails) could ship their customizations to the default configuration as a preseeding file rather than as a full-blown torrc forked from the default one. Using Config::Model (Debian package: libconfig-model-perl) would probably be even better on the long run, but the initial investment of writing a model might be too much for the Torouter project. What are the settings the Torouter user would want to customize? Bye, -- intrigeri <intrigeri@boum.org> | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage?
On Mon, May 30, 2011 at 02:01:14AM +0200, intrigeri wrote:
Hi,
If the configuration bits that are relevant to Torouter were managed using debconf (and possibly ucf), not only the webui's job would be a bit easier to do, but other Debian derivatives (such as the FreedomBox and Tails) could ship their customizations to the default configuration as a preseeding file rather than as a full-blown torrc forked from the default one.
Using Config::Model (Debian package: libconfig-model-perl) would probably be even better on the long run, but the initial investment of writing a model might be too much for the Torouter project.
Actually I've done some work on this area, but the feedback from my mail on (at that time) ot-talk [1] being not so positive, I've stalled a bit on this task. It's a big one as there isn't a policy on the configuration file format that guides it and assure some consistency for the torrc file you can rely on to write the rules. Plus, comments are not very well handled by config-model, which I'm not sure will help in having debconf reacting smoothly if the comments were stripped off the torrc file by config-model. This is an area were I needed some more researches, but if one of you have some hints on this, I'd be glad to hear. :) The last thread and ticket about the excito plug did raise again this topic in my mind though, but haven't found some spare time to go on with it. bert. [1] https://lists.torproject.org/pipermail/tor-talk/2011-March/thread.html#19761
On Mon, May 30, 2011 at 1:01 AM, intrigeri <intrigeri@boum.org> wrote:
Hi,
Runa A. Sandvik wrote (29 May 2011 23:35:24 GMT) :
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Users who aren't familiar with the command line will probably still have a problem configuring Tor. I think that a webui package in Debian/Ubuntu is the best way to go.
Here are my 2cts of the day.
/etc/tor/torrc is currently shipped as a conffile by the Tor Debian package. This means it's a bit hard to edit it programmatically while ensuring painful and robust upgrade paths.
You may want to look at https://trac.torproject.org/projects/tor/ticket/1922 (torrc.d-style configuration directories).
What are the settings the Torouter user would want to customize?
I think that users should, at a minimum, be able to choose whether to run a public/private bridge, non-exit relay or exit relay. This means that users should be able to set the nickname, contact info, relay port, directory port and so on. At some point, we may want to add a client mode as well. -- Runa A. Sandvik
On 05/29/2011 07:21 PM, Jacob Appelbaum wrote:
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Why not allow Vidalia running from a LAN-based computer to control it? The control port could autogenerate from the MAC address. This is not unlike how you might control an Airport Express or Extreme device, which does not offer a web UI.
On Thu, 02 Jun 2011 06:00:48 -0400 Nathan Freitas <nathan@freitas.net> wrote:
On 05/29/2011 07:21 PM, Jacob Appelbaum wrote:
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Why not allow Vidalia running from a LAN-based computer to control it? The control port could autogenerate from the MAC address.
Vidalia is not designed to control or configure a Tor process that it did not start. Robert Ransom
On 03:41 Thu 02 Jun , Robert Ransom wrote:
On Thu, 02 Jun 2011 06:00:48 -0400 Nathan Freitas <nathan@freitas.net> wrote:
On 05/29/2011 07:21 PM, Jacob Appelbaum wrote:
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Why not allow Vidalia running from a LAN-based computer to control it? The control port could autogenerate from the MAC address.
Vidalia is not designed to control or configure a Tor process that it did not start.
Actually, it is. It may not be perfect (yet :) ), but I use it like that every day. Although I haven't tested it controlling a Tor instance on another host. But either way, if the device already has a webui, controlling just Tor from another app seems not too practical. -- Tomas Touceda Gentoo Developer - Qt, Scheme, Lisp
On Thu, Jun 2, 2011 at 12:29 PM, Tomas Touceda <chiiph@gentoo.org> wrote:
On 03:41 Thu 02 Jun , Robert Ransom wrote:
On Thu, 02 Jun 2011 06:00:48 -0400 Nathan Freitas <nathan@freitas.net> wrote:
On 05/29/2011 07:21 PM, Jacob Appelbaum wrote:
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Why not allow Vidalia running from a LAN-based computer to control it? The control port could autogenerate from the MAC address.
Vidalia is not designed to control or configure a Tor process that it did not start.
Actually, it is. It may not be perfect (yet :) ), but I use it like that every day. Although I haven't tested it controlling a Tor instance on another host.
This sounds interesting. I'll give it a go and see what happens / how well it works.
But either way, if the device already has a webui, controlling just Tor from another app seems not too practical.
The issue here is that the device does not have a webui. So the question is if we need to create one, or if there are better / existing options out there. -- Runa A. Sandvik
On Thu, Jun 2, 2011 at 11:41 AM, Robert Ransom <rransom.8774@gmail.com> wrote:
On Thu, 02 Jun 2011 06:00:48 -0400 Nathan Freitas <nathan@freitas.net> wrote:
On 05/29/2011 07:21 PM, Jacob Appelbaum wrote:
Or perhaps we can just turn Tor on by default, ship tor-fw-helper and write a basic status of Tor out to a static html file?
Why not allow Vidalia running from a LAN-based computer to control it? The control port could autogenerate from the MAC address.
Vidalia is not designed to control or configure a Tor process that it did not start.
I have tested this, and it works just fine. The question is; are we happy with something that works, even if it's being used in a way that it was not designed for? If the answer is yes; We can ship plugs with Tor installed and configured (bridge by default, perhaps), and users can connect to the Tor process using Vidalia on their home computer. Users will then be able to configure Tor as a bridge, non-exit relay and exit relay, and we don't have to spend lots of time creating a web interface. -- Runa A. Sandvik
On Tue, 7 Jun 2011 21:08:48 +0100 "Runa A. Sandvik" <runa.sandvik@gmail.com> wrote:
Vidalia is not designed to control or configure a Tor process that it did not start.
I have tested this, and it works just fine. The question is; are we happy with something that works, even if it's being used in a way that it was not designed for?
Vidalia was designed to do this from the start, which is why it uses tcp/ip instead of some ephermeral file descriptor locally. The connection between their vidalia and the tor process is in plaintext. That should be the concern. -- Andrew pgp 0x74ED336B
On 06/07/2011 01:28 PM, Andrew Lewman wrote:
On Tue, 7 Jun 2011 21:08:48 +0100 "Runa A. Sandvik" <runa.sandvik@gmail.com> wrote:
Vidalia is not designed to control or configure a Tor process that it did not start.
I have tested this, and it works just fine. The question is; are we happy with something that works, even if it's being used in a way that it was not designed for?
Vidalia was designed to do this from the start, which is why it uses tcp/ip instead of some ephermeral file descriptor locally. The connection between their vidalia and the tor process is in plaintext. That should be the concern.
Yes, it should be SSL/TLS, as I've previously suggested, if we're going to use that as the controller. I still think that a web interface isn't that big of a deal if we're just shipping Debian... We just need to get a list of requirements and them hammer it out. (Though it might be neat to add a basic webserver to Tor itself. Libevent can do this but it doesn't have any concept of a CGI as far as I've seen..) All the best, Jake
On 7 Jun 2011, at 22:00, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On 06/07/2011 01:28 PM, Andrew Lewman wrote:
On Tue, 7 Jun 2011 21:08:48 +0100 "Runa A. Sandvik" <runa.sandvik@gmail.com> wrote:
Vidalia is not designed to control or configure a Tor process that it did not start.
I have tested this, and it works just fine. The question is; are we happy with something that works, even if it's being used in a way that it was not designed for?
Vidalia was designed to do this from the start, which is why it uses tcp/ip instead of some ephermeral file descriptor locally. The connection between their vidalia and the tor process is in plaintext. That should be the concern.
Yes, it should be SSL/TLS, as I've previously suggested, if we're going to use that as the controller.
Any idea about how we can do this between Vidalia and a Tor process? Would stunnel be useful in this case? We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia.
I still think that a web interface isn't that big of a deal if we're just shipping Debian...
We just need to get a list of requirements and them hammer it out.
It's not a big deal, but it will take more time to get the Torouter ready. If Vidalia can do what we want, why not use it? The user experience might be a bit better with a web interface, though. -- Runa A. Sandvik
On Tue, Jun 7, 2011 at 2:55 PM, Runa Sandvik <runa.sandvik@gmail.com> wrote:
On 7 Jun 2011, at 22:00, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On 06/07/2011 01:28 PM, Andrew Lewman wrote:
On Tue, 7 Jun 2011 21:08:48 +0100 "Runa A. Sandvik" <runa.sandvik@gmail.com> wrote:
Vidalia is not designed to control or configure a Tor process that it did not start.
I have tested this, and it works just fine. The question is; are we happy with something that works, even if it's being used in a way that it was not designed for?
Vidalia was designed to do this from the start, which is why it uses tcp/ip instead of some ephermeral file descriptor locally. The connection between their vidalia and the tor process is in plaintext. That should be the concern.
Yes, it should be SSL/TLS, as I've previously suggested, if we're going to use that as the controller.
Any idea about how we can do this between Vidalia and a Tor process? Would stunnel be useful in this case?
Vidalia needs to run a TLS server on whatever port it opens. Tor would need to know how to communicate with a TLS control port. I believe that it would be an interesting problem to try to authenticate the certificate of the remote Tor and actually one that could be solved without too much issue.
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia.
Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
I still think that a web interface isn't that big of a deal if we're just shipping Debian...
We just need to get a list of requirements and them hammer it out.
It's not a big deal, but it will take more time to get the Torouter ready. If Vidalia can do what we want, why not use it? The user experience might be a bit better with a web interface, though.
Well, I see a number of issues. One of the main issues is that you cannot safely connect to Vidalia over a network until TLS support is added to both Vidalia and Tor. Another is authentication of that connection. Yet another is that it will be extremely confusing for a user who doesn't understand what Vidalia does or why they'd need it. I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot). Adding Vidalia to the mix seems like a nice to have but I don't think it's currently up to the task... All the best, Jake
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible. I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay. I suggest we ship the excito with the web ui as the easy to use option. In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug. -- Andrew pgp 0x74ED336B
On Wed, Jun 8, 2011 at 8:02 AM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
Sure, I think that's good for a local socket but not going to help with remote control ports or a locked out password.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
I generally agree.
I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay.
That seems reasonable.
I suggest we ship the excito with the web ui as the easy to use option.
How's that web UI doing?
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
I agree. My excito is pushing a lot of data without any trouble, my dreamplug hasn't arrived. I was thinking that we should talk about clocks. I think djb solved the main problem of syncing clocks a while ago: http://cr.yp.to/clockspeed.html I think we should consider this as something we push for any embedded system with Tor. All the best, Jake
On Wed, Jun 8, 2011 at 4:02 PM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
Yeah, I was hoping the freedombox people would have something we could use. Doesn't seem like it, though. I think that, at some point, we should create a web ui for the dreamplug. But not having one right now should not be a blocker for the dreamplug-torouter.
I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay.
I guess we can set up dreamplugs as bridges by default and include a leaflet explaining the steps to take to change the configuration. Do you think we should touch the default setup of the dreamplug (it serves an open wifi by default, for example)?
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point. -- Runa A. Sandvik
On Thu, Jun 9, 2011 at 2:57 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
On Wed, Jun 8, 2011 at 4:02 PM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
Yeah, I was hoping the freedombox people would have something we could use. Doesn't seem like it, though. I think that, at some point, we should create a web ui for the dreamplug. But not having one right now should not be a blocker for the dreamplug-torouter.
Well, I'm not sure what you mean... The FB is just a Debian machine. Pick a web server, write a cgi and perhaps that will be the main interface? :-) I'd email the FBF list and ask. Perhaps the best web UI is one that is already written? Is the web UI for the Excito free software?
I suggest we ship the dreamplug with cli access only for those who want
a cheap device to be a bridge or relay.
I guess we can set up dreamplugs as bridges by default and include a leaflet explaining the steps to take to change the configuration. Do you think we should touch the default setup of the dreamplug (it serves an open wifi by default, for example)?
I believe that by default we should be shipping middle relays and we should be shipping 0.2.3.x with tor-fw-helper enabled by default as well. I think the boxes should be re-flashed to have Debian or a modern Ubuntu and locked down except with Tor and OpenSSH as listening services. We also need things to sync time and so on.
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
Is it Free Software? Can we use it on the DreamPlug until we have something else?
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point.
I think we need to talk about what we need for the OS. I suspect we need OpenSSH + Tor (tor-fw-helper, etc) + a few stock configuration files + time syncing (clockskew for example) + a randomly generated password that we uniquely key for each router in some non-silly way. Is there a trac ticket for the OS part of the Torouter? All the best, Jake
On Thu, Jun 9, 2011 at 4:55 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Thu, Jun 9, 2011 at 2:57 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Wed, Jun 8, 2011 at 4:02 PM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
Yeah, I was hoping the freedombox people would have something we could use. Doesn't seem like it, though. I think that, at some point, we should create a web ui for the dreamplug. But not having one right now should not be a blocker for the dreamplug-torouter.
Well, I'm not sure what you mean... The FB is just a Debian machine. Pick a web server, write a cgi and perhaps that will be the main interface? :-) I'd email the FBF list and ask. Perhaps the best web UI is one that is already written? Is the web UI for the Excito free software?
I was hoping there would be an existing ui what we could just plug Tor into, just like we did with the Excito B3 interface.
I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay.
I guess we can set up dreamplugs as bridges by default and include a leaflet explaining the steps to take to change the configuration. Do you think we should touch the default setup of the dreamplug (it serves an open wifi by default, for example)?
I believe that by default we should be shipping middle relays and we should be shipping 0.2.3.x with tor-fw-helper enabled by default as well. I think the boxes should be re-flashed to have Debian or a modern Ubuntu and locked down except with Tor and OpenSSH as listening services. We also need things to sync time and so on.
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
Is it Free Software? Can we use it on the DreamPlug until we have something else?
Yes, it's free software and will be available in the Excito GitHub repository when it's released (not sure if it's there already, I don't think so). The web interface is probably a bit too "heavy" (and includes a good mix of php and perl) for the dreamplug, so we should probably look for something else.
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point.
I think we need to talk about what we need for the OS. I suspect we need OpenSSH + Tor (tor-fw-helper, etc) + a few stock configuration files + time syncing (clockskew for example) + a randomly generated password that we uniquely key for each router in some non-silly way. Is there a trac ticket for the OS part of the Torouter?
There is now: https://trac.torproject.org/projects/tor/ticket/3374 We can move the discussion to #3374 if you want. -- Runa A. Sandvik
On Thu, Jun 9, 2011 at 7:34 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
On Thu, Jun 9, 2011 at 4:55 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Thu, Jun 9, 2011 at 2:57 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Wed, Jun 8, 2011 at 4:02 PM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
We would also need a way for users to easily change the hashed password. I can't remember if this is a feature that is already present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port.
I
generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
Yeah, I was hoping the freedombox people would have something we could use. Doesn't seem like it, though. I think that, at some point, we should create a web ui for the dreamplug. But not having one right now should not be a blocker for the dreamplug-torouter.
Well, I'm not sure what you mean... The FB is just a Debian machine. Pick a web server, write a cgi and perhaps that will be the main interface? :-) I'd email the FBF list and ask. Perhaps the best web UI is one that is already written? Is the web UI for the Excito free software?
I was hoping there would be an existing ui what we could just plug Tor into, just like we did with the Excito B3 interface.
I think it's fine to ship one web interface for us now and later find a good integration point with the Freedom Box later...
I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay.
I guess we can set up dreamplugs as bridges by default and include a leaflet explaining the steps to take to change the configuration. Do you think we should touch the default setup of the dreamplug (it serves an open wifi by default, for example)?
I believe that by default we should be shipping middle relays and we should be shipping 0.2.3.x with tor-fw-helper enabled by default as well. I think the boxes should be re-flashed to have Debian or a modern Ubuntu and locked down except with Tor and OpenSSH as listening services. We also need things to sync time and so on.
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
Is it Free Software? Can we use it on the DreamPlug until we have something else?
Yes, it's free software and will be available in the Excito GitHub repository when it's released (not sure if it's there already, I don't think so). The web interface is probably a bit too "heavy" (and includes a good mix of php and perl) for the dreamplug, so we should probably look for something else.
Can we rip out everything except the basics? If so, I think their web front end is perfect and it already has a Tor UI thanks to you... :-)
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point.
I think we need to talk about what we need for the OS. I suspect we need OpenSSH + Tor (tor-fw-helper, etc) + a few stock configuration files + time syncing (clockskew for example) + a randomly generated password that we uniquely key for each router in some non-silly way. Is there a trac ticket for the OS part of the Torouter?
There is now: https://trac.torproject.org/projects/tor/ticket/3374
We can move the discussion to #3374 if you want.
I'm happy to keep hammering stuff out here and the we can dump the results into the bug report. What do you think about a DreamPlug with Debian or Ubuntu? Do we have a preference? What other software do we need beyond ntp, ssh, tor and a web UI? Do we want to support a transparent Tor wifi network by default? I think Ubuntu's latest release is the best in terms of security and in theory support. It is however not as beloved as Debian for a number of solid reasons. I think NTP, OpenSSH with key auth (and perhaps fail2ban or something similar) and password auth, a very minimal web UI but still functional for real Tor configuration and that's about all we'll need. I also like the idea of a Tor wifi network by default for laptops like the CR-48 that I'm using right now. I'd kill to have a way to Torify the laptop because my main concern isn't privacy from my local network, it's data retention from the remote hosts... :-/ All the best, Jake
On Thu, Jun 09, 2011 at 07:50:09PM +0000, Jacob Appelbaum wrote:
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
Doesn't "make random people into public (middle-only) relays" have the (well maybe not "problem", but "issue"?) that when GFW blocks them, they (the random people who bought an Excito/etc.) won't be able to connect to anything in .cn any more? Although I don't _often_ connect to .cn domains, it seems unfortunate to effectively auto-ban these people from Chinese websites. - Ian
On Thu, Jun 9, 2011 at 7:57 PM, Ian Goldberg <iang@cs.uwaterloo.ca> wrote:
On Thu, Jun 09, 2011 at 07:50:09PM +0000, Jacob Appelbaum wrote:
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
Doesn't "make random people into public (middle-only) relays" have the (well maybe not "problem", but "issue"?) that when GFW blocks them, they (the random people who bought an Excito/etc.) won't be able to connect to anything in .cn any more? Although I don't _often_ connect to .cn domains, it seems unfortunate to effectively auto-ban these people from Chinese websites.
Yes, it might. It depends on which part of the GFW you're connecting through. Also, I believe the same is true for public bridge nodes as well. The main difference is that the bridges may not be as useful as the relays and I suspect they will also be less easy to troubleshoot for reach-ability reasons. In an ideal world, we'll write an enumeration of issues or benefits that arise from the different modes of helping. All the best, Jake
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/09/2011 09:57 PM, Ian Goldberg wrote:
On Thu, Jun 09, 2011 at 07:50:09PM +0000, Jacob Appelbaum wrote:
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
Doesn't "make random people into public (middle-only) relays" have the (well maybe not "problem", but "issue"?) that when GFW blocks them, they (the random people who bought an Excito/etc.) won't be able to connect to anything in .cn any more? Although I don't _often_ connect to .cn domains, it seems unfortunate to effectively auto-ban these people from Chinese websites.
I did not experience any problems connecting to .cn while using a relay IP address. I think they are just blocking an IP:port combination and not the entire IP address. ...but things might change -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk3xP14ACgkQyM26BSNOM7Zm+wEAmXNZbIQsAPhvOKTfUt9aSv4j 2SrhlQ+YagUsBDhnE3kA/2n6w8+XagJhxPXpvpX7kIxwUujp/nTa50PCZ2I7tOek =Vz+U -----END PGP SIGNATURE-----
On Thu, Jun 09, 2011 at 11:47:10PM +0200, tagnaq wrote:
Doesn't "make random people into public (middle-only) relays" have the (well maybe not "problem", but "issue"?) that when GFW blocks them, they (the random people who bought an Excito/etc.) won't be able to connect to anything in .cn any more? Although I don't _often_ connect to .cn domains, it seems unfortunate to effectively auto-ban these people from Chinese websites.
I did not experience any problems connecting to .cn while using a relay IP address. I think they are just blocking an IP:port combination and not the entire IP address. ...but things might change
Hmm. I wonder what happens if the packets are fragmented so that the TCP port information isn't in the first fragment... - Ian
On Thu, Jun 9, 2011 at 8:50 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Thu, Jun 9, 2011 at 7:34 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Thu, Jun 9, 2011 at 4:55 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Thu, Jun 9, 2011 at 2:57 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Wed, Jun 8, 2011 at 4:02 PM, Andrew Lewman <andrew@torproject.org> wrote:
On Tue, 7 Jun 2011 15:36:45 -0700 Jacob Appelbaum <jacob@appelbaum.net> wrote:
> We would also need a way for users to easily change the hashed > password. I can't remember if this is a feature that is already > present in Vidalia. Yes, we do need a way to change the password. We will also need a way to reset the password if the user is locked out of the control port. I generally think that this means we'll need a web UI... :-)
It's built into vidalia. Just click Advanced and you can change the password all you want.
I think the best thing is to make an autoconfiguring device with a web UI; we can easily rate limit Tor to something reasonable and make it a middle node by default. In all cases it stands alone and simply plugging it into a wall (power/ethernet) will provide more capacity to the network if the OR port is reachable (ala tor-fw-helper + tor + init.d scripts to start Tor on boot).
Most of me wants to wait for the freedombox people to derive their web interface, and then we can plug tor into it. I realize this could be years at the current rate of progress. If someone whips up a quick interface that isn't a security nightmare, we could use that until freedombox has something tangible.
Yeah, I was hoping the freedombox people would have something we could use. Doesn't seem like it, though. I think that, at some point, we should create a web ui for the dreamplug. But not having one right now should not be a blocker for the dreamplug-torouter.
Well, I'm not sure what you mean... The FB is just a Debian machine. Pick a web server, write a cgi and perhaps that will be the main interface? :-) I'd email the FBF list and ask. Perhaps the best web UI is one that is already written? Is the web UI for the Excito free software?
I was hoping there would be an existing ui what we could just plug Tor into, just like we did with the Excito B3 interface.
I think it's fine to ship one web interface for us now and later find a good integration point with the Freedom Box later...
Yep, I agree.
I suggest we ship the dreamplug with cli access only for those who want a cheap device to be a bridge or relay.
I guess we can set up dreamplugs as bridges by default and include a leaflet explaining the steps to take to change the configuration. Do you think we should touch the default setup of the dreamplug (it serves an open wifi by default, for example)?
I believe that by default we should be shipping middle relays and we should be shipping 0.2.3.x with tor-fw-helper enabled by default as well. I think the boxes should be re-flashed to have Debian or a modern Ubuntu and locked down except with Tor and OpenSSH as listening services. We also need things to sync time and so on.
Sounds like a plan. I prefer bridge by default, but we can discuss that later.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
Well, bridge by default is what they B3's are set up with. I also figure that a bridge sees less traffic than a relay, and so it might be more "friendly" for new users. But I like the idea of having a bunch of common configs, and we can also suggest bandwidth limits.
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
Is it Free Software? Can we use it on the DreamPlug until we have something else?
Yes, it's free software and will be available in the Excito GitHub repository when it's released (not sure if it's there already, I don't think so). The web interface is probably a bit too "heavy" (and includes a good mix of php and perl) for the dreamplug, so we should probably look for something else.
Can we rip out everything except the basics? If so, I think their web front end is perfect and it already has a Tor UI thanks to you... :-)
Maaaaybe. I haven't tried, but it can't be that hard. I'll look into it.
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point.
I think we need to talk about what we need for the OS. I suspect we need OpenSSH + Tor (tor-fw-helper, etc) + a few stock configuration files + time syncing (clockskew for example) + a randomly generated password that we uniquely key for each router in some non-silly way. Is there a trac ticket for the OS part of the Torouter?
There is now: https://trac.torproject.org/projects/tor/ticket/3374
We can move the discussion to #3374 if you want.
I'm happy to keep hammering stuff out here and the we can dump the results into the bug report.
Works for me. It's great to get feedback that will help get me started.
What do you think about a DreamPlug with Debian or Ubuntu? Do we have a preference?
Good question. I love Debian, but I'm sure Ubuntu would be great to use as well. I'll do some research and see if there is a good reason we should pick one over the other.
What other software do we need beyond ntp, ssh, tor and a web UI?
Do we want to support a transparent Tor wifi network by default?
Maybe this is something we can add later, and focus on bridge/relay support first?
I think Ubuntu's latest release is the best in terms of security and in theory support. It is however not as beloved as Debian for a number of solid reasons. I think NTP, OpenSSH with key auth (and perhaps fail2ban or something similar) and password auth, a very minimal web UI but still functional for real Tor configuration and that's about all we'll need.
Yeah, I agree.
I also like the idea of a Tor wifi network by default for laptops like the CR-48 that I'm using right now. I'd kill to have a way to Torify the laptop because my main concern isn't privacy from my local network, it's data retention from the remote hosts... :-/
I'm sure it would be useful for a number of users. I wouldn't be too difficult to include, and maybe the web interface can have an on/off button so that they can choose whether or not to enable the Tor wifi network. -- Runa A. Sandvik
I think it's fine to ship one web interface for us now and later find a good integration point with the Freedom Box later...
Yep, I agree.
Great. I'm sure that if the web UI is free software and it works well, we can see if the FB will be interested in using it.
What's the rational there? While we certainly need more bridges, I'd like to see an increase in relays and encourage more Friend of Friend bridge sharing. We should include a bunch of common configs and make it easy to setup. Also, a public relay will be much easier to help with in terms of setup, I suspect.
Well, bridge by default is what they B3's are set up with. I also figure that a bridge sees less traffic than a relay, and so it might be more "friendly" for new users. But I like the idea of having a bunch of common configs, and we can also suggest bandwidth limits.
Hrm. The B3 is certainly able to handle traffic. Also in both cases, we'll want to configure them to limit bandwidth. There is no promise that a relay or a bridge will see a certain amount of traffic if they're not configured to hibernate/rate limit/etc. I'd like a device that I can plug into a wall and it will automatically join a network, probe for upnp/natpmp and become a relay. I'd also like a hidden service so that I can connect and administrate it from anywhere in the world; though this is clearly a nice to have and not a requirement. :-)
I suggest we ship the excito with the web ui as the easy to use option.
Yep, the Tor web ui for the Excito B3 should be ready at the end of the month.
Is it Free Software? Can we use it on the DreamPlug until we have something else?
Yes, it's free software and will be available in the Excito GitHub repository when it's released (not sure if it's there already, I don't think so). The web interface is probably a bit too "heavy" (and includes a good mix of php and perl) for the dreamplug, so we should probably look for something else.
Can we rip out everything except the basics? If so, I think their web front end is perfect and it already has a Tor UI thanks to you... :-)
Maaaaybe. I haven't tried, but it can't be that hard. I'll look into it.
It seems like it may be modular from what you've said and if so, I mean, we've got the work put into the web UI already... :-)
In either case, we need to start testing, not keep thinking about what we could do. We're going to get a flood of feedback from actual people testing the excito or dreamplug.
Valid point.
I think we need to talk about what we need for the OS. I suspect we need OpenSSH + Tor (tor-fw-helper, etc) + a few stock configuration files + time syncing (clockskew for example) + a randomly generated password that we uniquely key for each router in some non-silly way. Is there a trac ticket for the OS part of the Torouter?
There is now: https://trac.torproject.org/projects/tor/ticket/3374
We can move the discussion to #3374 if you want.
I'm happy to keep hammering stuff out here and the we can dump the results into the bug report.
Works for me. It's great to get feedback that will help get me started.
I plan on hacking on it with you. In theory my DreamPlug arrives next week.
What do you think about a DreamPlug with Debian or Ubuntu? Do we have a preference?
Good question. I love Debian, but I'm sure Ubuntu would be great to use as well. I'll do some research and see if there is a good reason we should pick one over the other.
The main reason is security and possibly support on the Ubuntu front. The main reason for Debian is quite frankly, weasel. Without him, we'd be lost. :-)
What other software do we need beyond ntp, ssh, tor and a web UI?
Do we want to support a transparent Tor wifi network by default?
Maybe this is something we can add later, and focus on bridge/relay support first?
Sure, I think it's pretty much done though - I've got lots of transparent configs, etc. If we're using Debian or Ubuntu, it's dead simple and these boxes have enough memory to just run a second Tor for that purpose.
I think Ubuntu's latest release is the best in terms of security and in theory support. It is however not as beloved as Debian for a number of solid reasons. I think NTP, OpenSSH with key auth (and perhaps fail2ban or something similar) and password auth, a very minimal web UI but still functional for real Tor configuration and that's about all we'll need.
Yeah, I agree.
Ok. Great.
I also like the idea of a Tor wifi network by default for laptops like the CR-48 that I'm using right now. I'd kill to have a way to Torify the laptop because my main concern isn't privacy from my local network, it's data retention from the remote hosts... :-/
I'm sure it would be useful for a number of users. I wouldn't be too difficult to include, and maybe the web interface can have an on/off button so that they can choose whether or not to enable the Tor wifi network.
Sure - I can see the on/off button as just bringing up and down a network interface, basically. That network interface might also need ttdnsd/Tor's DNSPort/dhcpd and a custom MAC adddress... Seems straight forward, am I missing anything? All the best, Jake
On Thu, Jun 09, 2011 at 07:50:09PM +0000, jacob@appelbaum.net wrote 15K bytes in 359 lines about: : What's the rational there? While we certainly need more bridges, I'd like to Our funding for this project is to create more bridges to allow censored users to access the less-censored Internet from somewhere else in the world. It is not to create more relays. -- Andrew pgp key: 0x74ED336B
Hi Runa, On Sat, May 28, 2011 at 2:52 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
I got one of these.
When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
If we want to use the DreamPlug for the Torouter, we will have to
write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
You don't HAVE to have a web interface, but it sure does make it nice. However, SSH is really the only secure way to ensure you don't have some XSS or CSRF attack from your browser (cause that can be really bad when your browser takes over Tor... ;)
Thoughts? Comments?
I got lots of experience with these types of devices. The DreamPlug is using an ARM processor, much like the Yoggie Open Firewalls did. Maybe you heard of JanusPA(.com)...basically it was a Tor / OpenVPN Router that you could put inline on your ethernet connection, required zero config to make it work out of the box, and worked with any IPv4 device.
I have a build environment for the ARM architecture already, and I have a SheevaPlug and a DreamPlug , but I haven't put Tor on it yet due to being way overloaded with my day/night job. If you want, I could probably get all the development stuff tarball'd up and posted somewhere with basic instructions. Or I could probably just take 2 hours, do a build, and stuff it into the DreamPlug , then make a tarball of that. As for the "Freedombox", it sounds like a over-glorified JanusPA or DreamPlug or Gumstix. Getting Tor running on these things isn't difficult, and to have it automatically use Tor on boot and route all your traffic over Tor isn't that difficult either. It's setting up the build environment and testing that takes the most time. Give me a few days, maybe a week, and I'll dust off some old drives and see what I can dig up for you. I could probably save you a lot of time in Development, but your on your own to tackle the learning curve. Best Regards, Kyle
On Mon, May 30, 2011 at 4:55 AM, Kyle Williams <kyle.kwilliams@gmail.com> wrote:
Hi Runa, On Sat, May 28, 2011 at 2:52 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
Hi everyone,
DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong.
I got one of these.
Happy with it so far? Any issues with overheating or something similar?
When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1.
If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line.
You don't HAVE to have a web interface, but it sure does make it nice. However, SSH is really the only secure way to ensure you don't have some XSS or CSRF attack from your browser (cause that can be really bad when your browser takes over Tor... ;)
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.
Thoughts? Comments?
I got lots of experience with these types of devices. The DreamPlug is using an ARM processor, much like the Yoggie Open Firewalls did. Maybe you heard of JanusPA(.com)...basically it was a Tor / OpenVPN Router that you could put inline on your ethernet connection, required zero config to make it work out of the box, and worked with any IPv4 device. I have a build environment for the ARM architecture already, and I have a SheevaPlug and a DreamPlug , but I haven't put Tor on it yet due to being way overloaded with my day/night job. If you want, I could probably get all the development stuff tarball'd up and posted somewhere with basic instructions. Or I could probably just take 2 hours, do a build, and stuff it into the DreamPlug , then make a tarball of that.
What is "the development stuff"? -- Runa A. Sandvik
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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. 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. 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". -- Andrew pgp key: 0x74ED336B
On Fri, Jun 10, 2011 at 12:55 PM, <andrew@torproject.org> wrote:
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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?
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").
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. How to update the routers: - Excito: they roll out their own software updates and users can point-and-click to update via the interface. - DreamPlug: good question, I wonder if users would have to re-flash with a new image. 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. - 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. How to handle support issues: We should probably set up a mailing list, such as torouter@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. -- Runa A. Sandvik
On Fri, Jun 10, 2011 at 4:54 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Fri, Jun 10, 2011 at 12:55 PM, <andrew@torproject.org> wrote:
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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?
After a short discussion with Andrew on IRC, we agreed on the following plan; re-flash with debian, harden/lock down, install tor, test and ship.
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").
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.
How to update the routers:
- Excito: they roll out their own software updates and users can point-and-click to update via the interface.
- DreamPlug: good question, I wonder if users would have to re-flash with a new image.
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.
- 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.
How to handle support issues:
We should probably set up a mailing list, such as torouter@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.
-- Runa A. Sandvik
-- Runa A. Sandvik
On Fri, Jun 10, 2011 at 4:14 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
On Fri, Jun 10, 2011 at 4:54 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Fri, Jun 10, 2011 at 12:55 PM, <andrew@torproject.org> wrote:
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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?
After a short discussion with Andrew on IRC, we agreed on the following plan; re-flash with debian, harden/lock down, install tor, test and ship.
We should automate this into a single script that will do this with any DreamPlug. Have you currently converted any of the DreamPlug devices to Debian? If so, what's the process and where is it documented? If not, how shall we proceed with it? I'll have my DreamPlug next week and I'm happy to experiment. All the best, Jake
On Fri, Jun 10, 2011 at 5:17 PM, Jacob Appelbaum <jacob@appelbaum.net> wrote:
On Fri, Jun 10, 2011 at 4:14 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Fri, Jun 10, 2011 at 4:54 PM, Runa A. Sandvik <runa.sandvik@gmail.com> wrote:
On Fri, Jun 10, 2011 at 12:55 PM, <andrew@torproject.org> wrote:
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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?
After a short discussion with Andrew on IRC, we agreed on the following plan; re-flash with debian, harden/lock down, install tor, test and ship.
We should automate this into a single script that will do this with any DreamPlug. Have you currently converted any of the DreamPlug devices to Debian? If so, what's the process and where is it documented? If not, how shall we proceed with it? I'll have my DreamPlug next week and I'm happy to experiment.
I haven't converted my DreamPlug to Debian yet, but will try to do this over the weekend. I'll be sure to document the process as well. -- Runa A. Sandvik
I haven't converted my DreamPlug to Debian yet, but will try to do this over the weekend. I'll be sure to document the process as well.
Ok. This seems like a good starting point: http://blog.davideaves.com/archives/2011/03/21/installing_debian_gnulinux_6_... I love the intro: "Installing Debian GNU/Linux 6.0.1 (squeeze) on the DreamPlug." "After about a month of waiting the DreamPlug and JTAG module that I ordered was finally delivered. So far as a dedicated home server goes, the specs, physical size, price and longterm energy saving made it almost a no-brainer to purchase. However once it arrived it did not take me very long to realize that the preinstalled Ubuntu version on it was already obsolete and was not going to be supported. Without fully realizing what I was doing I quickly bricked the HostOS in an attempt to force a release update via a "do-release-upgrade" courtesy of the update-manager-core utilities. So there I was, frustrated, with a new brick of a system, and was forced to try to do a restore only to find out that there was no documentation out on the Internet to assist. I decided to document what all it took to get the DreamPlug back up and working and to install Debian on it, so hopefully I can save someone from all the pain and anguish I suffered while trying to get past the learning curve it took to get the system up and working.." Well, I think that settles it for me! Debian! Also: http://code.google.com/p/dreamplug/ All the best, Jake
On Fri, Jun 10, 2011 at 3:54 PM, Runa A. Sandvik <runa.sandvik@gmail.com>wrote:
On Fri, Jun 10, 2011 at 12:55 PM, <andrew@torproject.org> wrote:
On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sandvik@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@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
On Fri, 10 Jun 2011 16:15:43 +0000 Jacob Appelbaum <jacob@appelbaum.net> wrote:
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.
The Tor Project cannot ship a backdoored product of any kind, *ever*. No one would ever trust *any* of our hardware or software ever again, and rightly so. Robert Ransom
On Fri, Jun 10, 2011 at 6:27 PM, Robert Ransom <rransom.8774@gmail.com> wrote:
On Fri, 10 Jun 2011 16:15:43 +0000 Jacob Appelbaum <jacob@appelbaum.net> wrote:
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.
The Tor Project cannot ship a backdoored product of any kind, *ever*. No one would ever trust *any* of our hardware or software ever again, and rightly so.
Hi Robert, I did not suggest a backdoor! I suggested a method of remotely helping a limited number of (alpha testing) users debug reach-ability issues with their consent. We've never tested tor-fw-helper in the wild and we have never deployed something like the Torouter, we're also discussing an alpha test deployment without any user friendly UI. It is totally reasonable to explain that we're willing to help this specific, special group of people out with the bumps that will appear along the way. Please re-read what I wrote again and try to assume good faith FFS. Also, consider that if a user wasn't interested, we could simply not enable it. We're talking about hand flashing a bunch of devices, we're not talking about what we want to ship to every user on the planet someday. It's a bad idea to just mail off a bunch of hardware and hope for the best. We should provide some kind of support and help for the device during the alpha testing phase of the project. All the best, Jake
On Fri, Jun 10, 2011 at 07:12:25PM +0000, jacob@appelbaum.net wrote 1.7K bytes in 39 lines about: : I did not suggest a backdoor! I suggested a method of remotely helping This comes across as "it's not a backdoor, it's a highly secured front door that only law enforcement will have access to in order to catch criminals". : someday. It's a bad idea to just mail off a bunch of hardware and hope : for the best. We should provide some kind of support and help for the : device during the alpha testing phase of the project. Then we shouldn't ship the hardware yet. The hardware needs to stand on its own, with real users, and not have a way we can remotely access anything. -- Andrew pgp key: 0x74ED336B
andrew@torproject.org wrote:
On Fri, Jun 10, 2011 at 07:12:25PM +0000, jacob@appelbaum.net wrote 1.7K bytes in 39 lines about: : I did not suggest a backdoor! I suggested a method of remotely helping
This comes across as "it's not a backdoor, it's a highly secured front door that only law enforcement will have access to in order to catch criminals".
I think that's stretching it quite a bit. If the SSH access is documented, optional and is only intended be used with the user's consent (something Jakob stated several time already), the risk seems to be comparable to accepting binary-updates (or only checking signatures when building from source). Personally I think even if the optional SSH access would be available after the alpha testing phase, the main problem would be that it doesn't scale. How useful it would be is another question. In a lot of situations where the user reports that the "Torouter does not work" the SSH access may "not work" either ...
: someday. It's a bad idea to just mail off a bunch of hardware and hope : for the best. We should provide some kind of support and help for the : device during the alpha testing phase of the project.
Then we shouldn't ship the hardware yet. The hardware needs to stand on its own, with real users, and not have a way we can remotely access anything.
Are you objecting to auto-updates, too, then? Fabian
Fabian Keil <freebsd-listen@fabiankeil.de> wrote:
andrew@torproject.org wrote:
On Fri, Jun 10, 2011 at 07:12:25PM +0000, jacob@appelbaum.net wrote 1.7K bytes in 39 lines about: : I did not suggest a backdoor! I suggested a method of remotely helping
This comes across as "it's not a backdoor, it's a highly secured front door that only law enforcement will have access to in order to catch criminals".
I think that's stretching it quite a bit.
If the SSH access is documented, optional and is only intended be used with the user's consent (something Jakob stated several time
... Jacob ... Sorry. Fabian
On Fri, Jun 10, 2011 at 04:15:43PM +0000, jacob@appelbaum.net wrote 15K bytes in 322 lines about: : 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. Let's go back to the original point of the tor router. It is to provide a consumer-level Internet NAT/router that is a tor bridge. This way, people have a functional Internet gateway, and also give blocked users access to information via tor. The target user is someone who cannot configure tor themselves, but wants to help out with nearly zero effort. From what we're discussing, the excito is still that device. We're only attracted to the dreamplug because it's cheaper. If we're going to ship a device that is only usable to 10 people in the world, then we shouldn't waste our time and ship anything. We can simply document how to turn your dreamplug into a secure tor relay/bridge and let those so interested do it. As it is, the dreamplug is already difficult to use for 90% of the world because it's ssh only. ssh and vi only and consumer friendly generally do not go together. -- Andrew pgp key: 0x74ED336B
participants (14)
-
Andrew Lewman -
andrew＠torproject.org
-
bertagaz＠ptitcanardnoir.org -
Fabian Keil -
Ian Goldberg -
intrigeri -
Jacob Appelbaum -
Kyle Williams -
Nathan Freitas -
Robert Ransom -
Runa A. Sandvik -
Runa Sandvik
-
tagnaq -
Tomas Touceda