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/ _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss