mirror of
https://github.com/freedombox/FreedomBox.git
synced 2026-05-13 10:30:16 +00:00
Remove roadmap and design as they have no place in this package.
This commit is contained in:
James Vasile
parent
14a7a21536
commit
78d8ac5ff0
@ -7,7 +7,7 @@ PDFLATEX=pdflatex
|
|||||||
# List text files in the order in which you want them to appear in the
|
# List text files in the order in which you want them to appear in the
|
||||||
# complete manual:
|
# complete manual:
|
||||||
SOURCES=README.mdwn INSTALL.mdwn themes.mdwn hacking.mdwn TODO.mdwn modules.mdwn scripts.mdwn faq.mdwn COPYING.mdwn colophon.mdwn
|
SOURCES=README.mdwn INSTALL.mdwn themes.mdwn hacking.mdwn TODO.mdwn modules.mdwn scripts.mdwn faq.mdwn COPYING.mdwn colophon.mdwn
|
||||||
OTHER=design.mdwn roadmap.mdwn
|
OTHER=
|
||||||
TODO_SOURCES=$(patsubst TODO.mdwn,,$(SOURCES))
|
TODO_SOURCES=$(patsubst TODO.mdwn,,$(SOURCES))
|
||||||
MAN_SOURCES=$(patsubst COPYING.mdwn,copyright_notice00,$(SOURCES))
|
MAN_SOURCES=$(patsubst COPYING.mdwn,copyright_notice00,$(SOURCES))
|
||||||
|
|
||||||
|
|||||||
196
doc/design.mdwn
196
doc/design.mdwn
@ -1,196 +0,0 @@
|
|||||||
# Freedom Box Design and Architecture
|
|
||||||
|
|
||||||
This article describes and documents architectural considerations for
|
|
||||||
my vision of Freedom Box. It is not specific to the user interface
|
|
||||||
and instead contains thoughts about the Freedom Box as a whole.
|
|
||||||
|
|
||||||
The major immediate design problems that I see are authentication, ip
|
|
||||||
addressing, and backup. I'm sure there are others.
|
|
||||||
|
|
||||||
If the Freedom Box front end pulls together basic pieces and
|
|
||||||
configures them properly, we'll have the start of the freedom stack.
|
|
||||||
Then we can build things like free social networking applications on
|
|
||||||
top.
|
|
||||||
|
|
||||||
## Design Goals
|
|
||||||
|
|
||||||
The target hardware for this project is the
|
|
||||||
[GuruPlug](http://www.globalscaletechnologies.com/t-guruplugdetails.aspx).
|
|
||||||
It has low power consumption, two wired network interfaces, one
|
|
||||||
wireless hostapd-capable interface (802.11b), and two usb slots for
|
|
||||||
connecting external drives and peripherals. The hardware target might
|
|
||||||
change if a better unit becomes available (for example, with 802.11n
|
|
||||||
or USB 3 capability). The GuruPlug is reputed to have availability
|
|
||||||
problems involving shipping delays, and targetting a unit that cannot
|
|
||||||
satsify high demand might be an issue.
|
|
||||||
|
|
||||||
Freedom Boxes are not giant honking servers. They are small boxes
|
|
||||||
that do perform a lot of functions. They are not heavily resourced.
|
|
||||||
So keep things small and light.
|
|
||||||
|
|
||||||
By the same token, there is no need to scale up to thousands of users.
|
|
||||||
A box should happily serve a person and her family, maybe an extended
|
|
||||||
group of friends. Call it 100 people at the most.
|
|
||||||
|
|
||||||
The target user for this project is the home consumer of network
|
|
||||||
appliances. It ranges from the most basic user (the kind of person
|
|
||||||
who might have spent all of three minutes setting up her LinkSys
|
|
||||||
WRT54G) to the home enthusiast who wants a local file server for media
|
|
||||||
and backups, print server and dns service.
|
|
||||||
|
|
||||||
|
|
||||||
## Authentication
|
|
||||||
|
|
||||||
Authentication in the context of the Freedom Box is a diffiult
|
|
||||||
problem. You need to be able to trust your box, and it needs to be
|
|
||||||
able to trust you. What's more, security must withstand forgotten
|
|
||||||
passwords, server destruction, changing email addresses and any other
|
|
||||||
possible disaster scenario.
|
|
||||||
|
|
||||||
In addition, your friends (and their boxes) need to trust your box
|
|
||||||
when it acts on your behalf, even if it does so when you're not around
|
|
||||||
to enter passphrases or otherwise confirm agency. But even as it
|
|
||||||
needs to operate in your absence, it can't itself have authority to
|
|
||||||
access all your data, because you might lack exclusive physical
|
|
||||||
control of the box (e.g. if you have a roommate). If the box can act
|
|
||||||
as you without limits, anybody who takes control of the box takes
|
|
||||||
control of your online identity.
|
|
||||||
|
|
||||||
What's more, security should be high. Freedom Boxes might contain
|
|
||||||
emails or other sensitive documents. The box mediates network
|
|
||||||
traffic, which means rooting it would allow an attacker to spy on or
|
|
||||||
even change traffic. Demonstrating control of an email address should
|
|
||||||
not be enough to gain access to the box and its admin functions.
|
|
||||||
|
|
||||||
### Passphrases
|
|
||||||
|
|
||||||
Most users habitually think of passwords. We need to force them to
|
|
||||||
think of passphrases. It starts by using 'passphrase' in the
|
|
||||||
literature. Second, we need to encourage users to pick phrases, and
|
|
||||||
prompts should urge them to do so. We also need minimum password
|
|
||||||
lengths and maybe even a requirement of at least a few spaces.
|
|
||||||
|
|
||||||
Even better than passphrases are passfiles. We should keep a lookout
|
|
||||||
for ways to use files instead of phrases when securing the Freedom
|
|
||||||
Box.
|
|
||||||
|
|
||||||
### A Scheme for Secure Web Login
|
|
||||||
|
|
||||||
Passphrases should
|
|
||||||
[never be stored in plain text](http://www.codinghorror.com/blog/2007/09/rainbow-hash-cracking.html).
|
|
||||||
[MD5 is too fast for passphrases.](http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html)
|
|
||||||
Therefore, my current plan for secure website login involves bcrypt:
|
|
||||||
|
|
||||||
The server sends the client a permanent salt, PS, a random session
|
|
||||||
salt, SS and a number of rounds, R. It brcypts the password using PS
|
|
||||||
and stores the result, B.
|
|
||||||
|
|
||||||
The browser
|
|
||||||
[bcrypts the passphrase using javascript](https://code.google.com/p/javascript-bcrypt/)
|
|
||||||
and PS. Then, it bcrypts that result with SS. It does R rounds of
|
|
||||||
bcrypt with S. The browser then sends the result, C, back to the
|
|
||||||
server.
|
|
||||||
|
|
||||||
The server retrieves bcrypts its stored, hashed passphrase and does R
|
|
||||||
rounds of bcrypt on it with SS. If that matches C, the passphrase is
|
|
||||||
a match.
|
|
||||||
|
|
||||||
The server must be able to keep track of sessions, as it needs to
|
|
||||||
remember SS between giving it to the client and getting it back. The
|
|
||||||
Server cannot rely on the client to remind it of SS. This would allow
|
|
||||||
an attacker to dictate SS and leave the server vulnerable to replay
|
|
||||||
attacks.
|
|
||||||
|
|
||||||
This scheme has the dual advantage of not storing any cleartext
|
|
||||||
passphrases and also never sending any cleartext passphrases between
|
|
||||||
client and server.
|
|
||||||
|
|
||||||
TODO: consult a security expert as to the strength of this scheme
|
|
||||||
|
|
||||||
### Other Schemes
|
|
||||||
|
|
||||||
#### Monkeysphere
|
|
||||||
|
|
||||||
[Monkeysphere](http://web.monkeysphere.info/) is a promising project.
|
|
||||||
Monkeysphere's major win is that it avoids the clunkiness of SSL
|
|
||||||
certificate authorities. That's huge, except it replaces the
|
|
||||||
certificate authority structure with the PGP web of trust. Relying on
|
|
||||||
the web of trust is a good idea
|
|
||||||
([much better than relying on SSL certificate authorities](http://www.crypto.com/blog/spycerts/)),
|
|
||||||
except that new users might not have joined the web. It also requires
|
|
||||||
a bunch of GPG infrastructure that might be difficult to setup
|
|
||||||
automatically and with little user intervention.
|
|
||||||
|
|
||||||
As of this writing, it does not appear to support Windows or Macintosh
|
|
||||||
clients, making it unsuitable for this project.
|
|
||||||
|
|
||||||
#### Secure Remote Password
|
|
||||||
|
|
||||||
[SRP](http://srp.stanford.edu/) is an interesting technique. Patents
|
|
||||||
are a concern. What does it buy us that my scheme, above does not?
|
|
||||||
|
|
||||||
There is a
|
|
||||||
[python implementation](http://members.tripod.com/professor_tom/archives/srpsocket.html),
|
|
||||||
although it is not clear that it has been through the crucible. Even
|
|
||||||
if SRP is solid, this implementation might be flawed.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Finding Each Other
|
|
||||||
|
|
||||||
### Dynamic DNS
|
|
||||||
|
|
||||||
Each box might need multiple dynamic DNS pointers. Every box is going
|
|
||||||
to require its own set of dynamic names. For example, my Freedom Box
|
|
||||||
might be known as both `fb.hackervisions.org` and
|
|
||||||
`james.softwarefreedom.org`. My work colleagues might know me as
|
|
||||||
`james@james.softwarefreedom.org` while my friends might reach me at
|
|
||||||
`james@fb.hackervisions.org`. By default, when contacts come in via
|
|
||||||
different names, my box might be smart enough to treat those contacts
|
|
||||||
differently.
|
|
||||||
|
|
||||||
If I share this box with my partner, Emily, she might be
|
|
||||||
`emily@jv187.fboxes.columbia.edu`, in which case my box will need
|
|
||||||
another dynamic DNS pointer.
|
|
||||||
|
|
||||||
### Mesh Networking
|
|
||||||
|
|
||||||
Freedom Boxes should be meshed. Rather than run in infrastructure
|
|
||||||
mode, they should route for each other and create strong local meshes
|
|
||||||
that will carry data for anybody that passes through.
|
|
||||||
|
|
||||||
There are some problems, though.
|
|
||||||
|
|
||||||
* I'm not sure how well nodes in ad-hoc mesh mode interact with
|
|
||||||
others in infrastructure mode.
|
|
||||||
|
|
||||||
* The Freedom Box only has one wireless radio, which will drastically
|
|
||||||
hurt speed.
|
|
||||||
|
|
||||||
* Routing can be difficult when connecting mesh network nodes to the WAN.
|
|
||||||
|
|
||||||
## Backup
|
|
||||||
|
|
||||||
Everybody should automatically and redundantly store encrypted backups
|
|
||||||
on their friend's freedom boxes. Recovery should not assume you kept
|
|
||||||
your key or know a password. We can recover the decryption key by
|
|
||||||
having a bunch of friends encrypt the key in various combinations. If
|
|
||||||
enough of my friends get together, they can decrypt it for me.
|
|
||||||
Optionally, a passphrase can serve to slow my friends down if they
|
|
||||||
turn against me. Maybe it takes 5 friends acting in concert to
|
|
||||||
recover my key, but only 3 to recover a version protected by the
|
|
||||||
passphrase.
|
|
||||||
|
|
||||||
## Push vs Pull
|
|
||||||
|
|
||||||
For a social network, real time communication is key. Asynch
|
|
||||||
communication is good, but sometimes people just want to bash comments
|
|
||||||
back and forth. For that, you need push, which is just a web fetch
|
|
||||||
meaning "pull my rss feed".
|
|
||||||
|
|
||||||
If, however, you have a lot of friends and they have a lot of friends,
|
|
||||||
your extended network can be large, resulting in many "pull my rss
|
|
||||||
feed" commands. We should only process push requests for friends to
|
|
||||||
reduce load. You really don't need real time updates of the social
|
|
||||||
networking activity of strangers. Friends of friends is as far out as
|
|
||||||
things should ever go.
|
|
||||||
@ -1,65 +0,0 @@
|
|||||||
# Plinth Roadmap
|
|
||||||
|
|
||||||
## 0.1 Basic Wireless Access Point
|
|
||||||
|
|
||||||
* <strike>Basic/Expert mode toggle</strike>
|
|
||||||
* SSH access
|
|
||||||
* Connect to WAN via DHCP and static IP
|
|
||||||
* Offer DHCP on wired and wireless interfaces
|
|
||||||
* WEP
|
|
||||||
* WPA2
|
|
||||||
* Bridge WAN and LAN
|
|
||||||
|
|
||||||
## 0.2 Basic Wireless Router
|
|
||||||
|
|
||||||
* NAT
|
|
||||||
* DMZ
|
|
||||||
* Port forwarding and triggering
|
|
||||||
* dhcp server (on by default, expert can disable)
|
|
||||||
* dns server
|
|
||||||
* MAC address filtering
|
|
||||||
* NTP client
|
|
||||||
|
|
||||||
## 0.3 Advanced Wireless Router
|
|
||||||
|
|
||||||
* dynamic dns - This is special. See the notes in the section on
|
|
||||||
[dynamic DNS](#dynamic-dns) for details.
|
|
||||||
* UPnP
|
|
||||||
* Cron
|
|
||||||
* Tx power management
|
|
||||||
|
|
||||||
## 0.4 File Server, More Routing Features
|
|
||||||
|
|
||||||
* boxbackupd
|
|
||||||
* NFS
|
|
||||||
* Samba
|
|
||||||
* Auto mount usb volumes and create samba shares for them
|
|
||||||
* TOR
|
|
||||||
* Ad blocking web proxy
|
|
||||||
* HTTPS everywhere (on by default, experts can disable)
|
|
||||||
|
|
||||||
## 0.5 Print Server and Backups
|
|
||||||
|
|
||||||
* Social backup to friend's boxes via ddns and boxbackup
|
|
||||||
* printer discovery and sharing via samba and cups
|
|
||||||
|
|
||||||
## 1.0 Plinth Lives!
|
|
||||||
|
|
||||||
* Complete user documentation for every basic and expert menu item
|
|
||||||
* Package management complete
|
|
||||||
|
|
||||||
## Unscheduled Features
|
|
||||||
|
|
||||||
There are a variety of other features to be implemented, but they are
|
|
||||||
of lower priority than all the tasks scheduled above.
|
|
||||||
|
|
||||||
* NTP Server
|
|
||||||
* Provide virtual networks and multiple SSIDs
|
|
||||||
* Radius Server
|
|
||||||
* QoS
|
|
||||||
* file explorer
|
|
||||||
* Mesh networking
|
|
||||||
* Chaining boxes so the furthest upstream knows to route messages down
|
|
||||||
the chain (e.g. if you and your roommate both have your own box, you
|
|
||||||
just plug one into the other).
|
|
||||||
* Bit Torrent / onion router integration
|
|
||||||
Loading…
x
Reference in New Issue
Block a user