spiped - Encrypted and Authenticated Pipes


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 '[]:2562' -t []:2562 -k keyfile

Remote: /usr/local/bin/spiped -d -s []:2562 -t '[]: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:

1Stronger Key Derivation via Sequential Memory-Hard Functions (PDF)

« Aug 15, 2013 : Bot Building with SPS

Sep 3, 1999 : ad initium »