Wiki

• FrontPage
• RecentChanges
• FindPage
• HelpContents
• FreedomBuddy

Should be merged with ?FreedomBox/FreedomBuddy and placed under the name ?FreedomBox/FreedomBuddy.

introduction

?FreedomBuddy is is the first customised piece of software for the FreedomBox. designed to let users negotiate services without interference from third parties, preventing man-in-the-middle attacks by using pre-shared keys. Santiago is designed to let users negotiate services without third party interference. By sending OpenPGP signed and encrypted messages over ?HTTPS (or other protocols) between parties, I hope to reduce or even prevent MITM attacks. ?FreedomBuddy can also use the ?Tor network as a proxy (with Python 2.7 or later), allowing this negotiation to happen very quietly.

It's designed to operate as a sort of distributed DNSSEC that lets only the people you trust find you.

?FreedomBuddy aims to be accessible to less technical users. ?Santiago is the old name for the ?FreedomBuddy system.

usage

Want to know where someone's hosting a service for you?

• https://localhost:8080/where/(key)/(service) (The reply's JSON, reply format will be confiurable shortly.)

Want to request a service from somebody?

• https://localhost:8080/learn/(key)/(service) (You get no response.)

Want to host a service for somebody?

• https://localhost:8080/provide/(key)/(service) (Again, you get no response.)

code

?FreedomBuddy currently lives at ?Github.

• https://github.com/nickdaly/plinth/tree/santiago

Setup instructions are included in the Freedombox discussion list.

• http://lists.alioth.debian.org/pipermail/freedombox-discuss/2012-May/003750.html

problem

First, a short history lesson in by way of explanation: A few years ago, Comcast started blocking Lotus Notes for no apparent reason. Users were negotiating connections between their computers and Comcast was censoring the messages. To simplify things terribly, Alice would try to send Bob some new notes. Bob would tell Alice to send them along but that acceptance would be censored: Alice never received Bob's reply and notes were never exchanged.

solution

Santiago avoids this issue by encrypting the messages that negotiate connections: now, neither Comcast nor your nosy next-door neighbor will know what services you're negotiating, keeping out the people who have no business poking into your business. Securing the connection process allows you to set up an encrypted connection to your friend that other services can use, making it still harder for third parties to interfere in your communication.

I'm going to host a ?FreedomBuddy node as a ?Tor Onion service. That will let my buddies find me online to use the wiki I'm sharing with them, even as we both move constantly (through meatspace and the network).

How would this work?

Tor Onion Services (or other protocols, maybe I2P, GNUnet, etc) can act as static IP addresses. So, if I use that to host the ?FreedomBuddy service, my friends will be able to find me, because that location is my unchanging, cryptographic identity.

We could stop right here and have no need for the ?FreedomBuddy service, but there's one functional problem: communicating over Tor is really slow. So, we can use the ?FreedomBuddy system to exchange our current IP addresses (for any service), and connect directly to one another, without going through any sort of proxy. This sort of connection, while less anonymous, is usually much faster.

?PGP

?FreedomBuddy relies on the user having a set of friends' trusted PGP keys. Finally, since we already have a whitelist of permitted users (through their PGP keys), you could configure each service to allow only whitelisted users to connect.

tor

If you use a ?Tor Onion Service as your Santiago service address, that can act as static IP address, allowing you to negotiate with your friends even as you both move around and change IP addresses.

limitations

TLS

Complete indistinguishability for both client and server against an active attacker who is willing to break some handshakes to identify at least one of the parties involved is a seriously difficult (possibly intractable) problem. For one thing, the TLS handshake currently leaks a lot of identifiable information about the server at least, as well as the capabilities and extension offered by the client.

ISP control

This is no communication panacea, the folks in control of your internet connection could still cut it off for exceeding your bandwidth cap, for example. However, it does make it significantly harder to determine what services are being negotiated.

identity and pre-shared key

The pre-shared key bit might help to reduce the technical density of the problem, making it more accessible to grandmothers than, say, a custom VPN ethernet interface: people understand identity much better than they understand technical issues. That's not to say that people even understand identity well. But, without going deep into the philosophy, most folks seem to have an intuitive understanding of the subject.

prerequisites

Testing it out it takes a bit of setup:

This was all tested on Debian Stable, so I know it works on Python 2.6. Other versions may work differently.

You need a PGP key. You probably want to make a new password-less key specifically for Santiago.

Santiago's running as a service, and you won't always be there to enter the password when the gnupg-agent times out and locks the keyring again. At that point, Santiago will block while waiting for (or fail without) the password.

You need [python-gnupg](http://code.google.com/p/python-gnupg). Make sure it's either in your PYTHONPATH, or edit the start.sh and test.sh files so that it can be found.

You need a production.cfg or test.cfg file with contents like the following:

• [pgpprocessor] keyid = (your 40-character key identifier)

You need an SSL certificate (the ssl-cert package is required). Run the following as root, changing the group as necessary:

• # make-ssl-cert generate-default-snakeoil # make-ssl-cert /usr/share/ssl-cert/ssleay.cnf santiago.crt # chgrp 1000 santiago.crt # chmod g+r santiago.crt

See /usr/share/doc/apache2.2-common/README.Debian.gz for more details.

Either set up a Tor listener on port 8118, or set the proxy port to "None" or 80, if you're running Python 2.7 or later.

Run make once in the Plinth root directory to create the config files you need.

Running bash start.sh in a console will set up a Santiago service that communicates with itself. You can see the Santiago service learn about the "https://somestuff" location (it'll appear in the "consuming" dictionary) if you navigate to:

• https://localhost:8080/query?service=santiago&host=(your key ID)

It'll give you a warning about an untrusted certificate, but since you just made that certificate, ignore the warning.

After you load the page, you won't see anything. That's by design. You'll need to watch the debug messages (look for one reading "Success!") or Ctrl+C out of the server to drop into PDB where you can examine the santiago.consuming dictionary.

CategoryFreedomBox