Differences between revisions 4 and 5
Revision 4 as of 2012-09-09 23:59:05
Size: 14497
Editor: PaulWise
Comment: fix language header
Revision 5 as of 2012-09-10 00:10:44
Size: 14491
Editor: PaulWise
Comment: use Debian URLs
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
 * http://www.mail-archive.com/freedombox-discuss@lists.alioth.debian.org/msg03734.html

 * htt
p://www.mail-archive.com/freedombox-discuss@lists.alioth.debian.org/msg03615.html
 * http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-July/004264.html

 * http://
lists.alioth.debian.org/pipermail/freedombox-discuss/2012-June/004145.html

Translation(s): none


Connection methods describe how users connect to ?FreedomBoxes from other ?FreedomBoxes or the outside Internet. We're trying to describe the different situations and how to solve the problems those situations create.

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

Proxying

Hosts can't receive any incoming connections, so they use intermediate hosts to MITM the connection.

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.

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.

Scenario 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).

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

  • minimal permanent storage in all participating ?FreedomBoxes. Trivial ongoing overhead for your friend sites. Web accesses from the world go straight to your box. Can convert transparently to the Webproxy Redirect mode below, or to the Friends Web Cache mode below.

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

  • assigned. Must find one or two friends. Must register those friends' domain names with your domain provider as your NS servers.

Scenario Webproxy Redirect

Same setup as above, except you don't even have a publicly reachable dynamic IP address. 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.

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

  • minimal permanent storage in all participating ?FreedomBoxes. Can convert transparently to the DNS Redirect mode above, or to the Friends Web Cache mode below.

Cons: Must find one or two friends. Must register those friends' domain names

  • with your domain provider as your NS servers. Your friends must be willing to have ALL your web traffic go via their ISP connection.

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.

Scenario 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).

Pros: Relatively low setup overhead. Requires minimal permanent storage in all

  • participating ?FreedomBoxes. Can convert transparently to the DNS Redirect mode above, or to the Webproxy Redirect mode above. Uses only half the bandwidth of the Webproxy Redirect mode, and improves the latency of accesses to your website.

Cons: Must find one or two friends. Must register those friends' domain names

  • with your domain provider as your NS servers. Your friends must be willing to have ALL your web traffic go via their ISP connection. Requires some temporary storage (RAM or Flash) in your friends'

    ?FreedomBoxes. Has complications and reduces security for SSL web accesses.

Overall

- 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.


CategoryFreedomBox