Harboured

Harboured stands for "Harboured: automated repetitive backups of used remotely enclosed data" and, as such, is a recursive acronym. The idea is to develop a firewall-piercing, user-friendly way to send your data to a safe location to be backed up or, to put it in the words of the original README: using one publicly available service (a CGI program running on an HTTP server) Harboured allows a client and a back-up server to communicate with eachother and remotely back up local data, while both the client and the server are behind firewalls.

Introduction

The problem is the well-known, ever-recurring problem of losing data andd not having back ups for that data. The solution is to have an integral back-up of that data somewhere off-site. The problem now becomes how to get the data to back up to that other location. The answer is over the internet, going through the local firewall and the remote one.
The general idea is to have the client - the machine to back up the data from - and the server - the machine to back up the data to - call the coordinator on a regular basis. The coordinator authenticates the two machines and, if the two machines can't connect to eachother directly, serves as a bridge for the data.

Authentication

The authentication protocol to be used by the two machines is a hand-shake protocol derived from SSHv2. Only the client and the server need to be authenticated: while the coordinator does see all the data come by, only the session data is visible to it. The data passed between the client and the server is encrypted so only the server can read what the client sends it and vice versa. It doesn't make much sense to try to crack the coordinator, as all it can do is stop a back-up from occuring (in which case the user will be duly notified).
The general idea is that the client machine generates a public key which is passed to the server manually. That public key is used in authentication. If the server can't produce a challenge with the public key or the client can't respond to the challenge, the two can't be authenticated. Because the protocol uses pretty strong encryption, the chances that the coordinator can fake it are very slim.
Chances are also very slim that a back-up server would both get its hands on the client's public key and be able to produce the proper fingerprint to be trusted by the client.
Finally, a compromized client would not be very helpful as data is only sent to the server, not from it. To restore backed-up data (in case of a catastrophic event) you'd have to ask the administrator of the remote backup server..