Should be merged with Freedombox/FreedomBuddy and placed under the name FreedomBox/FreedomBuddy.
?FreedomBuddy is 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.
- A UI: Because everybody likes UIs.
- JSON Output: Good for utilities relying on FBuddy.
- Zero known injection attack vulnerabilities: For either the server or its clients. I'm currently trying to debug what's going on with one unexpected output and may release a new version depending on my findings.
- Tests: But we still need more of 'em.
- Build scripts to configure VPNs automatically.
Setup instructions are included in the Freedombox discussion list.
1. If you want to test over Tor, get the Tor Browser Bundle:
2. Install pre-requisites:
- Python 2, python-gnupg (Debian Testing only)
3. You need a PGP key.
If you plan on letting ?FreedomBuddy run all the time (as a daemon), you'll probably want to make a new password-less key specifically for FBuddy. Otherwise FBuddy will block or fail while waiting for the password. If you want to control when FBuddy runs, install gnupg-agent to manage your keys and passwords while the system's running.
4. You need a production.cfg or test.cfg file with contents like
- the following:
- [pgpprocessor] keyid = (your 40-character key identifier from step 3)
5. 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.
6. 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.
7. Run make once in the Plinth root directory to create the config
- files you need.
8. Running bash start.sh in a console will set up a ?FreedomBuddy
- service. To see it in action, navigate to:
At this point it should successfully interact with other ?FreedomBuddies in the world. To serve it correctly over a Tor Hidden Service, you may need to change the protocol (see santiago.py::728) from "https" to "http" and symlink the "https" protocol directory as "http".
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.
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 hidden 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 Hidden 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.
?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.
If you use a ?Tor hidden 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.
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.
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.