[Freedombox-discuss] FreedomBox/Unhosted/PageKite for Access Innovation Prize 2012

Sun Jul 8 19:51:42 UTC 2012

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 <bre at pagekite.net> wrote:
> On Sat, Jul 7, 2012 at 1:25 PM, Michiel de Jong <michiel at unhosted.org> wrote:
>> On Sat, Jul 7, 2012 at 2:47 PM, Michael Rauch <l15t at 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/