One thing I left out completely, sorry: Self signed certs. Obviously, these work with any of the scenarios where the user has their own commercial cert, and they can be auto-configured by the software on the box when it is first used, thus providing significant security without any central repository or administrative burden.
I left them out because Michiel and I felt the browser warnings make this a non-starter for most users, but I should have included it for completeness. Sorry. :-) On Sun, Jul 8, 2012 at 7:43 PM, Bjarni Rúnar Einarsson <b...@pagekite.net> wrote: > On Sat, Jul 7, 2012 at 1:25 PM, Michiel de Jong <mich...@unhosted.org> wrote: >> On Sat, Jul 7, 2012 at 2:47 PM, Michael Rauch <l...@miranet.ch> wrote: >>> - with PageKite, this probably leads to registering a domain name for a box. >>> as this is how the regular web works, normal browser/http-client can access >>> the page/service. >> >> or subdomain, which saves money. >> >> we could use per-box startssl certs instead of certs on the proxy, but >> if the proxy is the apt server anyway then that does not really >> increase security, and it's annoying that you have to renew them each >> year. > ... > > Michiel and I discussed this and related issues on IRC a bit > yesterday, and he asked me to summarize the conclusions. So here > goes... > > Goals: > * Be able to host content on a FreedomBox which is part of the web > * Be as independent as possible > * Avoid single-points of failure, security and reliability-wise > > Non-goals: > * Resist attacks/censorship by "government-grade" opponents > > The techniques we consider available to us, are traditional static > IPs, PageKite and Tor/Tor2web. We specifically have Unhosted data in > mind and HTTPS is considered a requirement for that. > > After talking back and forth a bit, we came up a few scenarios which > the box can support relatively easily, which should suit different > users' needs to varying degrees: > > == Scenario One: Traditional Web == > > 1. Use has a public IP address > 2. User purchases their own domain name, configures it > 3. User obtains SSL certificates > > Pros: This is the traditional way hosting on the web has worked, and > it is still arguably the most efficient way to publish content. Very > decentralized (user depends on DNS provider, security of SSL vendor > and their own ISP, none of which have to be the same for everyone). > > Cons: Relatively high barrier, user must be quite technical. No > anonymity. Can not be preconfigured. Most users have at most 1 public > IP, so at only FreedomBox per household can serve content at a time. > > User costs: Domain registration and SSL cert (recurring, estimated > $15/year, cheap domain and free StartSSL cert) > > > == Scenario Two: Independent PageKite == > > Same as Scenario One, except instead of a public IP, the user connects > to a PageKite relay to expose their web server (using their own > cert/domain and end-to-end HTTPS). > > Pros: Mostly compatible with public web. Works for almost all users, > slightly less technical as local network config isn't an issue. > PageKite relay service could be provided either by the pagekite.net > service or a network of peers, user could migrate from one to another > at will. Provides weak anonymity, as the domain could be registered > anonymously and the PageKite provider provides single layer of > misdirection. > > Cons: High barrier, technical user. End-to-end HTTPS encryption over > PageKite is not supported by some older browsers. A peer-operated > PageKite relay network does not exist, so currently the only option is > to pay pagekite.net (about $3/month) or run your own relay on a VPS > ($5-20/month). > > User costs: Domain registration and SSL cert, PageKite subscription > (recurring, estimated $50/year (see below, re. PK pricing)) > > > == Scenario Three: Prepackaged Domain/SSL/PageKite == > > A variation on the above two, where instead of the user registering > their own domain and SSL certificate, both are provided preconfigured > on the FreedomBox itself by the distributor. A PageKite account could > be included/preconfigured as well. > > Pros: A "plug and play" solution, especially if PageKite is included. > Compatible with the public web. > > Cons: Requires the user have a public IP. The FreedomBox distributor > becomes a "single point of attack" as they have a central list of > which domain belongs to which user. The distributor is also in a > position which allows them to issue new certs and MITM attack users > without their knowledge. > > User costs: Domain registration and SSL cert, maybe PageKite > subscription (recurring, estimated $15-50/year). First year maybe > included in price of the box? > > > == Scenario Four: Prepackaged PageKite/MITM SSL === > > Same as Scenario three, but without including a domain name or cert > (uses a subdomain from the PageKite service or some other friendly > org.) The boxes will be configured to relay through servers which do > "man in the middle" SSL using a wild-card certificate. > > Pros: Plug and play. Weak anonymity. Mostly web compatible. > > Cons: User depends on the PageKite service for their identity (domain) > and security. > > User costs: PageKite subscription (recurring, estimated $36/year). > First year maybe included in price of the box? > > (Note: This number can be massaged a bit as I control the PageKite > pricing scheme and I want to support these projects for idealistic > reasons - I just need to not be losing lots of money on this. If we > guarantee users aren't transferring massive amounts of bandwidth, this > number can go down quite a bit.) > > > == Scenario Five: Tor/Tor2web == > > This scenario assumes the box's services are published as Tor Hidden > Services only. > > Pros: Plug and play. Strong anonymity. > > Cons: Slow. URLs are not user friendly. Compatible with the public web > via tor2web.org. > > It looks like tor2web.org only provides wild-card based MITM SSL, > which means using them makes the security/privacy of the solution > comparable to PageKite MITM (although the anonymity is obviously far > stronger). > > User costs: $0/year, as Tor is volunteer operated and government funded. > > ...... > > That's it. Did I miss anything? :-) > > The major conclusion from our chat, was that options can be combined > and it may make sense to provide an "easy to get started" option with > a clear migration path towards more independence for those who prefer. > > So we can give the users something that "just works" and educate them > on extra steps they can take to make it "better" for whatever their > needs may be. It's the classic engineering cop-out, let the user > choose. :-) > > With that strategy, it makes sense to start with options Four+Five > preconfigured (Tor and PageKite), and provide instructions and an easy > migration path to move to options Two or One, which are the best from > an independence point of view. Some users may however choose to > disable Four and use Five only, if they are concerned with anonymity. > Other users may be mostly concerned with costs and choose One or Five > for that reason. > > It is my (possibly biased) opinion that option Three (the prepackaged > domains and SSL certs) should probably be discarded. It provides IMO > a false sense of security, as due to the way domain registration and > SSL certificates are handled, the issuer of the box will have a > central database of all users and central control and a massive > administrative burden - they will not only be able to issue new certs > whenever they want, they will be required to do so to handle renewals. > It just doesn't seem like a scalable solution. > > -- > Bjarni R. Einarsson > Founder, lead developer of PageKite. > > Make localhost servers visible to the world: https://pagekite.net/ -- Bjarni R. Einarsson Founder, lead developer of PageKite. Make localhost servers visible to the world: https://pagekite.net/ _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss