spiped - Encrypted and Authenticated Pipes
Sun, Aug 11, 2013
What technology would you choose to securely and transparently connect two services on a public network? SSH tunnel? VPN? Your services speak HTTP? How about SSL + Basic Auth? The rarely-used SSL + client certificates? I’m certain you’ve guessed that my answer is going to be, “none of the above; use spiped.” All the other options have more complicated set-up and code complexity.
spiped - encrypted and authenticated pipes
The security of spiped depends on two things: your ability to share and protect a secret key on the servers that need to be connected, and your trust in the open-source code written by Dr. Colin Percival. If you don’t follow cryptography, you probably don’t know beans about Colin Percival. Why do I trust the security of my applications to his code? Let’s get one thing out of the way first: I don’t really trust myself to write crypto or to cook up my own protocols with crypto primitives; nor should you. Any of the above options are far better than trying to add this stuff to your application.
I’m now going to try to convince you that spiped is easier to use and at least as secure, or possibly more secure than the other options I’ve presented. Colin Percival was the FreeBSD security officer for seven years. He offers bug-bounties, even for documentation errors. As part of his research and in support of his excellent backup service for “the truly paranoid”, Tarsnap, he invented the scrypt key derivation function. If you want to keep your passphrase-protected keys safe from the NSA and foreign governments with the capability to mount attacks with “custom-designed parallel circuits”1, scrypt is probably your best bet. I suspect that spiped is also quite secure against similar adversaries.
As part of my work for Gawker, I’ve been building a prototype search application with Akka. Last week, I wanted to test “remoting” between a development machine in my office and a remote server. I’m not comfortable exposing an unsecured Akka communications port to the outside world. Sure, Akka supports SSL. Do I really want to create a trust-store? Self-signed certificates? No, thank you. Here’s how I used spiped instead.
dd if=/dev/urandom bs=32 count=1 of=keyfile
Securely copy keyfile to the remote server
Local: /usr/local/bin/spiped -e -s '[127.0.0.1]:2562' -t [123.45.6.789]:2562 -k keyfile
Remote: /usr/local/bin/spiped -d -s [123.45.6.789]:2562 -t '[127.0.0.1]:2562' -k keyfile
That’s it. With no configuration change, my local Akka application is communicating securely with remote actors. I know that ssh -L would allow me to do exactly the same thing. Why might spiped be better? I think I’ll let spiped’s author answer this question.
To use spiped, you’ll have to compile it yourself. On my Debian-based system this was pretty simple:
sudo apt-get install build-essential
sudo apt-get install libssl-dev
make install
I’ve been using spiped to provide transparent, secure connections between production systems since its release in 2011 with absolutely no problems. Here are a few ways I’ve used it:
- To secure IPMI. IPMI is configured to listen on a private address. Spiped runs on a gateway server with a public IP. I trust the security of spiped far more than a random/probably old IPMI implementation.
- As a secure reporting pipe for sending metrics from various systems to a cloud-based graphite installation.
- To provide authentication and transport security for connecting cloud-based components to co-located servers communicating with HTTP-based APIs. For example, I’ve designed, and am running, a distributed crawling framework with various bots manged by a centralized coordination service. All internal communication is secured by spiped.
1Stronger Key Derivation via Sequential Memory-Hard Functions (PDF)