Matt Hamer, founder of Attribyte, has been posting on mth·ology since 1999.

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.

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

ad initium

Fri, Sep 3, 1999

mthology

Domain Name: mthology.com

Created on..............: 1999-09-03

Prior to this registration, mth · ology was, quite literally, a “home page” published from /home/mhamer on a dial-up account at swbell.net. At the turn of the millennium, all the known weblogs, including mthology, could be listed on a single HTML page. I suppose I’m allowed to retain my weblog nation™ citizenship only because I continue to work in its Department of Interior.