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

Bjarni Rúnar Einarsson bre at pagekite.net
Sun Jul 8 19:43:25 UTC 2012


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/



More information about the Freedombox-discuss mailing list