Opened 9 years ago

Closed 4 years ago

#3453 closed task (wontfix)

Torouter desires and features

Reported by: ioerror Owned by: ioerror
Priority: Medium Milestone:
Component: Archived/Torouter Version: Tor: unspecified
Severity: Normal Keywords: torouter tor-fw-helper upnp natpmp debian
Cc: phobos, arma, ficus@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


This is the bug for discussion - please be verbose!

We need to discuss what features are possible and what features are desirable. The core of the Torouter is to create a box that when installed on any network, a new bridge is added to the Tor network, if connections are allowed to the bridge.

The possibilities with the DreamPlug hardware are currently being examined in #3374 - the features of the DreamPlug are largely working without issue.

phobos suggests that it should be a Tor bridge and a NAT device:

Phobos has also stated that the UI for this router is SSH and a text editor; any user who wants a better UI should use a B3 for now.

I'm rather keen to enable the open wifi that transparently routes Tor traffic for clients (such as my Google Chrome CR-48 laptop or an iPhone) that do not support a native Tor client, yet.

I think it should be ipv6 ready but probably not ship with ipv6 until we've ironed out the ipv6 designs for Tor.

I think we should assume that eth0 will be the default network uplink and that the network must provide us with a DHCP lease. Anything else requires editing the config.

I'd like to take advantage of the hardware crypto acceleration in the DreamPlug at some point - it will require some OpenSSL patches. More info in #3374.

I think that the bluetooth should probably be disabled by default, the usb ports should remain active, the eSata should remain active, the audio should remain active and if possible, the SD card should be available. It would be nice to be able to export a config to a usb or SD card. These should only make it more interesting for developers and people who want to help expand on the device.

So - the golden questions - What do you want to see in a Torouter based on the DreamPlug hardware? What would make it worthwhile for you to buy such a device and to run one on your network? What kind of network would you put the device on? Would it be behind a NAT with UPnP or NAT-PMP? Would it be your new NAT device entirely?

I'd like to survey people and get a sense of what features are positive incentives and what people find compelling as a reason to have such a device - anyone with suggestions on how to conduct such a survey, I'm all ears.

Child Tickets

Change History (7)

comment:1 Changed 9 years ago by eljh

I think torouter is really on the right track. There will always be a trade off between simplicity and flexibility. I think the approach taken so far, where torouter attempts to be intelligently autoconfiguring, is the way to go for now. The reality is, in the field, stuff that just works is infinitely more useful than stuff that needs to be babysat--particularly since there are often not techies around.

comment:2 Changed 9 years ago by atagar

One thought on something that I'd like to see is for the torouter to automatically configure itself to...

  • be a bridge at first start or if its external ip changes (ie, the ISP issues a new one)
  • become a middle hop relay if our ip has been static for a long while and we aren't getting used as a bridge

Hopefully this would let us make use of fresh, unblocked ips for counter censorship while also keeping us from wasting a perfectly good relay when it gets blocked. Actually, I'd really like this option to be in tor itself...

Cheers! -Damian

comment:3 Changed 9 years ago by phobos

I'd like to keep the Dreamplug separate from the B3. Call them torouter dreamplug and torouter b3 for now.

My goal is to have the B3 be as user friendly as possible. Mostly because the B3 market already expect that, and we've invested some time and effort into making Tor integrate with it. Think of this as the torouter-stable.

As for the dreamplug, I'm encouraged if we can provide an open dev playground for all. Think of this as the torouter-alpha. We have 10 dreamplugs with jtag boards we can ship when we're ready. I would also like it if we could coordinate, but not depend upon the freedombox progress.

The original idea of the torouter is that it's the gateway to the internet. It has a public IP address that is accessible from the world. There would be no need for nat/pmp if there is an external interface already.

Security and Updates
For the dreamplug, we seem to be focusing on security at all costs. We should be careful not to develop a device that is too brittle. We haven't focused on updates for the dreamplug, nor figured out a way to integrate with the larger Debian repos and community. We haven't thought about usability at all.  I think we need some more structured thought processes around the dreamplug torouter. 

For the B3, we seem to assume we're going to use a bunch of existing repos or run our own. Running our own repos until we can integrate with debian-arm upstream seems a smarter plan.

Transparent Tor

I'm not convinced transparent tor needs to be a key feature of either torouter hardware.  My concern is that this is going to encourage people do to unsafe things over tor.  Even if it isn't encouraged, people will use technologies that cannot be properly secured and merely push the risks from their local network and ISP to exit relays.  The costs to the user could be high.  Perhaps tor could block known plaintext ports by default and/or send these through the local IP per iptables rulesets, thereby bypassing tor.

Bridge or Relay-by-default

At a minimum, the torouter should be a relay by default.  A setup screen could ask the user if they want to help censored users access the Internet (bridge config), or either of a non-exit and exit relay configuration. This set of options lacks a tor client-only config on purpose. 

comment:4 Changed 9 years ago by ioerror

From the wiki - we need to discuss and decide on these for the alpha testing phase:

Goals of the Torouter project

The goals of this project include the following:

  • Provide a solid platform for running a Tor bridge with minimal effort
    • Allow for upgrading to be a middle relay or an Exit relay
      • This will not be an exit relay by default, it will only be a bridge by default
  • Provide a closed high security (WPA2) wireless network that does not route traffic through Tor
  • Provide an open wireless network that is transparently routed through Tor
    • We plan to inject a pop-up page that will confirm informed consent is given before users actually use the Tor network
    • The pop-up page must state very clearly that using a Tor transparent proxy does not make their Internet traffic anonymous
    • We also plan to set the Wifi gateway's MAC address to be constant (to prevent application layer attacks that leverage SkyHook or similar systems from disclosing physical locations)
  • Provide the ability to easily host a Tor Hidden Service
  • Provide a standard OpenWRT Tor web configuration extension system (no console access should be required)
    • We would also like to support tor-arm if the user is console inclined
  • Roll all work back into packages and contribute it back into the OpenWRT software ecosystem
    • We want to normalize the packages and ensure OpenWRT has our support
  • Provide a hardened, stripped down OpenWRT build that we specifically support
    • We may want to offer a pre-flashed router that will be sold that benefits OpenWRT and the Tor Project

comment:5 Changed 8 years ago by ficus

Cc: phobos runa arma ficus@… added; phobos runa arma removed

I updated the wiki page to the following; any comments?


In general: demonstrate, document, and streamline mechanisms for individuals
with always-on internet connections to participate in and support both the Tor
onion routing network and Tor Project initiatives.


  1. Provide an accessible mechanism for friendly non-expert "general internet users" to opt-in and participate in the Tor network as a bridge with minimal effort.
  1. Provide an accessible mechanism to *informed and committed* individuals to opt-in and and participate as a middle relay or an exit relay.
  1. Provide a generic mechanism for publishing HTTP content via a Tor hidden service.
  1. Provide a platform from which to potentially run OONI (Open Observatory of Network Interference) node software.

Additionally, implement a transparently Tor-ifying always-on network gateway to
experimentally provide (limited) onion routing benefits to downstream devices.
This last goal is controversial, and the serious scenarios where this would be
useful seem very limited (devices
must highly trust the gateway, the local network could be malicious and/or
monitored, etc). Some speculative use cases:

  • Creating demonstration/outreach networks
  • Accessing hidden services with no concern for client-end anonymity
  • Publicly sharing wireless internet access with less chance of being accountable for the actions of guests (perhaps not legally advisable)
  • For a single operator in control of the entire local network, and having properly "anonymized" all downstream software to not leak identifying information, could have usability improvements for mobile devices which would not need to re-initialize connectivity to the onion network.

comment:6 Changed 8 years ago by runa

Cc: runa removed

comment:7 Changed 4 years ago by irl

Resolution: wontfix
Severity: Normal
Status: newclosed

This project is no longer active. Closing as no longer relevant. See also: #20747.

Note: See TracTickets for help on using tickets.