Using the SSH protocol as a secure transport protocol

November 24, 2014

I have an IPSec problem: my IPSec tunnel uses constant keys, with no periodic automatic rekeying. While IPSec has an entire protocol to deal with this called IKE, in practice IKE daemons (at least on Linux) are such a swamp to wade into that I haven't been willing to spend that much time on it. Recently I had a realization; rather that wrestle with IKE, I could just write a special purpose daemon to rekey the tunnel for me. Since both ends of the IPSec tunnel need to know the same set of keys, I need to run the daemon at either end and the ends have to talk to each other. Since they'll be passing keys back and forth, this conversation needs to be encrypted and authenticated.

The go-to protocol for encryption and authentication is TLS. But TLS has a little problem for my particular needs here in that it very much wants to do authentication through certificate authorities. I very much don't want to. The two endpoints are fixed and so are their authentication keys, and I don't want to have to make up a CA to sign two certificates and (among other things) leave myself open to this CA someday signing a third key. In theory TLS can be used with direct verification of certificate identities, but in practice TLS libraries generally make this either hard or impossible depending on their APIs.

(I've written about this before.)

As I was thinking about this it occurred to me that there is already a secure transport protocol that does authentication exactly the way I want it to work: SSH. SSH host keys and SSH public key authentication is fundamentally based on known public keys, not on CAs. I don't want to literally run my rekeying over SSH for various reasons (including security), but these days many language environments have SSH libraries with support for both the server and client sides. The SSH protocol even has 'do command' operation that can be naturally used to send operations to a server, get responses, and perhaps supply additional input.

It's probably a little bit odd to use SSH as a secure transport protocol for your own higher level operations that have nothing to do with SSH's original purpose. But on the other hand, why not? If the protocol fits my needs, I figure that I might as well be flexible and repurpose it for this.

(The drawback is that SSH is relatively complex at the secure transport layer if all that you want is to send some text back and forth. Hopefully the actual code complexity will be minimal.)


Comments on this page:

By Ewen McNeill at 2014-11-24 03:13:07:

Given that you manage both ends, have you considered using an easier to set up tunnelling technology? OpenVPN is my preferred "just works" VPN tool in many situations (pretty much anything that isn't "site to site", and even some of those), and leverages TLS with (if you want) certificate authentication in both directions.

Ewen

PS: IKE is a bit of a pain, but I wouldn't say so much of a pain that I'd write Yet Another (tm) rekeying daemon just to avoid setting it up. Especially if you do "shared secret" IKE. Just saying.

By dozzie at 2014-11-24 05:31:56:

Actually, if you avoid using ipsec-tools directly (i.e. if you use Pluto from Openswan or strongSwan), then setting up IKE is pretty easy for both X.509 and PSK authentication. I would go this way instead of doing some magic manually.

I feel the need to say this. You are describing the reinvention of a wheel. IKE exists and works. Smart people that understand security spent a lot of time trying to get something safe. Yes, IKE isn't exactly the prettiest thing out there. (This is not a judgement call on your intelligence/security understanding, merely a comment on the fact that most people are not likely to come up with something as secure.)

With that said...

(1) I've only used IKE on OpenIndiana, SmartOS, and OmniOS - there it is relatively straightforward

(2) the use of ssh is clever

From 107.217.62.37 at 2014-11-24 19:07:16:

Check out tincd.

Written on 24 November 2014.
« I'm happier ignoring the world of spam and anti-spam
Delays on bad passwords considered harmful, accidental reboot edition »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 24 00:15:12 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.