Connection methods describe how someone connects from one FreedomBox over the Internet to another. A FreedomBox machine running in someone's home may not be accessible from the Internet. The home network will probably have a dynamic IP address and it may be hidden behind a firewall running on the ISP's router. A FreedomBox on this home network can't receive incoming connections, so how can another FreedomBox talk to it?

We're trying to describe the different situations and how to solve the problems those situations create.

Many solutions involve proxying. A host can't receive any incoming connections, so it uses intermediate hosts to MITM (Man In The Middle) the connection. Proxies come in several flavours, such as peer proxies and dedicated proxies. Peer proxies are worse for privacy than dedicated proxies because the need to share standard ports conflicts with the use of end-to-end encryption.

This page is mostly a copy from a series of emails and needs lots of editing.

Traditional Web Proxying

  1. Use has a public IP address
  2. User purchases their own domain name, configures it
  3. User obtains SSL certificates


This is the traditional way web hosting on the Internet has worked.

have to be the same for everyone).



Domain registration and SSL cert (recurring, estimated $15/year, cheap domain and free StartSSL cert)

Independent PageKite proxying

This is similar to traditional web proxying. Instead of a public IP, the user connects to a PageKite relay to expose their web server. This requires using their own cert/domain and end-to-end HTTPS.

The PageKite relay service is provided either by the service or a network of peers. A peer-operated PageKite relay network does not yet exist, so currently the only option is to pay




Domain registration and SSL cert. PageKite subscription (recurring, estimated $50/year $3/month ? (see below, re. PK pricing)) or run your own relay on a VPS ($5-20/month).

Prepackaged Domain, SSL and PageKite

A variation on the web proxying and Independant PageKite proxying, 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.

The FreedomBox distributor has a central list of which domain belongs to which user. The distributor is also in a position to issue new certs.


Compatible with the public web.


new certs and MITM attack users without their knowledge.


Domain registration and SSL cert, maybe PageKite subscription (recurring, estimated $15-50/year). First year maybe included in price of the box?

Prepackaged PageKite and MITM SSL

Prepackaged PageKite. No domain name or cert is included. This uses a subdomain from the PageKite service or some other friendly org. The boxes will be configured to relay through servers which do MITM SSL using a wild-card certificate.



PageKite service for their identity (domain) and security.


PageKite subscription (recurring, estimated $36/year). First year maybe included in price of the box?

(Note from Bjarni RĂșnar Einarsson : 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.)


This scenario assumes the box's services are published as ?Tor Hidden Services only. Compatible with the public web via

It looks like 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).




$0/year, as ?Tor is volunteer operated and government funded.

Peer (Friend-to-Friend) Proxying

Alice asks Bob to act as a peer proxy. She points her DNS MX record to Bob's domain name, and Bob temporarily reconfigures his mail server to accept mail for Alice's domain as well as his own.

When Carol wants to send mail to Alice, she looks up Alice's MX record, gets Bob's domain name, looks up Bob's A record, gets Bob's IP address, and connects on the standard SMTP port. At this point Bob doesn't know whether the connection is for him or Alice.

Carol knows she's talking to Bob's mail server because Alice's MX record resolved to Bob's domain, so Carol and Bob can start TLS using Bob's certificate. But a TLS connection between Carol and Bob doesn't prevent Bob from reading Alice's mail.

Dedicated (Third-Party) Proxying

With a PageKite-style proxy, the provider can dynamically allocate a separate proxy IP address to each user. Alice points her MX record at her domain name and her A record at her proxy's IP address. Carol connects to the proxy's SMTP port and the proxy forwards the connection to Alice. Carol and Alice can start TLS using Alice's certificate, which prevents the proxy from reading Alice's email.

There's a similar situation with HTTP - Alice and Bob can share a port for HTTP (by using virtual hosts) but not for HTTPS.

DNS Redirect

Offer an option to host your website on your freedombox, with a dynamic IP address, that is reached via one, two, or more friends' freedomboxes' static IP addresses who serve up your domain records.

Domain records (also known as your "DNS zone") describe what IP addresses your web server (and other servers) are located on, the domain names of the servers that serve up your DNS zone, and possibly public keys and signatures that secure this and other information. In the standard DNS protocol, these records can be changed dynamically and are globally cached for high performance and reliability. (This is how the Internet already works.)

Our software would provide both server and client implementations of a domain name server / redirector. If you have a static IP address, your FreedomBox can host a domain server, which serves up your own domain name(s), and also serves up the name(s) of friends. This DNS server would accept dynamic updates from your friends' ?FreedomBoxes, which would revise the IP address in the zone.

The client software that runs in your FreedomBox would merely publish these dynamic updates (to your friends' ?FreedomBoxes) whenever your FreedomBox's public IP address changed. These updates would be cryptographically signed to avoid unwanted changes.

By choosing more than one friend to host your domain zone, you would avoid single points of failure.

Web accesses would come directly from the world to your dynamically-addressed FreedomBox.

Even friends who don't have a static IP address can improve your reachability/reliability, if they have a dynamic and publicly reachable IP address. You should start with one friend with a static IP address as an "anchor" site.

Once browsers support DNS-signed SSL certificates using the IETF DANE TLS protocol, the same software can securely publish your public key without making you interact with an SSL certificate provider (reducing the setup costs and making more of it automatable).


Relatively low setup overhead. Works with SSL or without. Requires


Requires that you have at least ONE public IP address, dynamically



Webproxy Redirect

If you don't have a publicly reachable dynamic IP address then DNS Redirect won't work for you. All you have is a NAT address and your NAT redirector is completely oblivious to all attempts to punch a hole through it.

So you find two or more friends and they serve up your DNS records as before, but each of them advertise the entire set of friends' IP addresses as the address of your web site. And each of them runs a web proxy that relays any incoming web accesses from their box, out over their ISP, to your box, using the PageKite protocol.

FreedomBox software would again provide both the server software and the client software for this.

Your FreedomBox would at all times keep a TCP connection up to each friend's FreedomBox so that web accesses can be relayed to you down that TCP connection.

Incoming web accesses from the world would go at random to any of your friends' ?FreedomBoxes. Those boxes would relay the traffic to yours. If you or the world can't reach some of your friends, those friends' proxies would not answer, and clients would try another address, making it possible to reach you anyway.

As in DNS Redirect mode, can also publish IETF DANE TLS keys to eventually avoid SSL certificate setup overhead.

We could ship a FreedomBox with just one of these modes working, and then upgrade the software to transparently switch to the lower overhead mode whenever your FreedomBox is on a publicly reachable IP address. Indeed, both modes could be combined: Your DNS zone could publish both your dynamic IP address (if you have one), and the static (or dynamic) IP addresses of your friends. Accesses made from the world that randomly pick your own IP address would go directly; access that pick your friends' addresses would go via proxies at your friends.


Relatively low setup overhead. Works with SSL or without. Requires




Friends' Web Cache

Setup for this scenario is the same as in Web Redirect: Your box is on the Internet, and can call out to public IP addresses, and maybe it even has a dynamic or static IP address of its own.

In this scenario, again you pick one, two, or more friends who publish your DNS records, let you update the addresses in your DNS zone with your publicly reachable IP address if you have one, and also publish the whole collection of your friends' IP addresses as your web address.

Your friends run a PageKite proxy that relays any incoming web access to your FreedomBox. But this time that proxy also caches web page contents, using the standard HTTP web cacheing protocol, so that a second access to a page that Friend 1 has already served up, will not need to go to your box, but can be served up directly from Friend 1's box to many web requesters until it times out. If you have a small web site, your friends end up cacheing the whole thing, such that accesses no longer have to go to your FreedomBox, saving 50% of the Internet traffic that is used in Scenario Webproxy Redirect.

Your friends' ?FreedomBoxes would remember the pages that they have proxied, temporarily, either in RAM or in nonvolatile storage. They are free to throw away these cached pages at any time; when they do, the next access to that page goes back to being proxied to your FreedomBox.

There are complications for SSL web accesses. The simplest thing to do is to always proxy them (only cache non-SSL accesses). To enable cacheing for SSL accesses, two obvious approaches appear: either your friends' ?FreedomBoxes would need to store a temporary or permanent copy of your private key (so they could negotiate an SSL session on your website's behalf), with obvious security issues; or your friends could proxy the SSL/TLS session setup, and then be handed the secret key for just that SSL/TLS session, such that they could impersonate your web server (sending answers from their cache) only to that client (also with obvious security problems, but lesser ones).





Work Space





Live Help

Where To Start








To Do





Use cases





HELP & DISCUSSIONS: Mailing List - #freedombox | CONTACT Foundation | JOIN Alioth Projects, GitHub

Next call: Sunday, October 22nd at 17:00 UTC

Latest news: Stable FreedomBox images - 2017-08-05

This page is copyright its contributors and is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.