The spiped secure pipe daemon
Three weeks ago, Bump Technologies released their new Scalable TLS Unwrapping Daemon. As someone who has written in the past about using stunnel to unwrap HTTPS connections while keeping OpenSSL away from other sensitive code, I found this quite exciting: STUD is just a few hundred lines of code, compared to almost ten thousand lines for stunnel. Since complexity is highly correlated with insecurity, I trust a simple daemon which only unwraps SSL/TLS far more than I trust a multifunctional monolith.A few days later, I was looking at my kivaloo data store, contemplating the next steps I should take with it, and I decided that it was time to add some security. After all, I'm going to be using it in Tarsnap, and the Tarsnap web server needs to access user accounting data so that people can see their account balances and recent usage; since I want the web front-end kept separate from the core backup service code, traffic will need to go over the internet. My first thought was to build this into kivaloo directly, but then I reconsidered: Why not write a generic secure pipe daemon, and keep the complexity of encryption and authentication out of kivaloo? Enter spiped.
Spiped is a tool for creating secure tunnels using a pre-shared key. You connect to a socket on one machine, and the "client-side" spiped you're running on that system opens a connection to the "server-side" spiped running on another machine, which then opens a connection to the predefined target. The two spiped daemons use the pre-shared key to securely negotiate encryption and authentication keys; and then they shuttle data back and forth. Thanks to select(2) and non-blocking network I/O, spiped can easily handle hundreds of simultaneous connections within a memory footprint of a few MB.
In effect, spiped is a replacement for 'ssh -L'; but it has a few advantages:
- You don't need to be running sshd. Given the relative complexities of the two daemons, it's vastly more likely that your server will be compromised via a vulnerability in sshd than via a vulnerability in spiped. (In fact, if you need to run SSH for the benefit of interactive logins, you're probably better off having sshd only listening on 127.0.0.1 and connecting to it via spiped.)
- You don't need a persistent connection. 'ssh -L' works by holding a single TCP connection open and multiplexing incoming connections over it; as a result, if you lose your internet connection you'll need to re-establish the tunnel. (On my laptop, I've been sending email via an SSH tunnel for years — and I have a cron job which runs every minute to re-establish the tunnel if it has died.)
- No more checking SSH host keys. If you can connect via spiped, you've got the right keys — if the "shared" keys used by the spiped client and server don't match, the connection-creation handshaking will fail and connections will be immediately closed.
I sent the spiped code around to a few people on Friday, and I haven't heard any major complaints; so I've released spiped version 1.0.0 on the spiped website today; there is also an SVN repository for anyone interested in keeping track of future development (not that I expect there will be very much) and a mailing list for discussions about spiped.
Enjoy!