Why I do IPSec improperly and reduce my security

June 2, 2013

I've had an IPSec tunnel between my home machine and work for a fairly long time now. Now, I have a confession: during all of this time, the tunnel has had fixed keys.

If you don't know IPSec you may not understand what this means, so let me explain. To simplify a bit IPSec connections are protected by symmetric stream ciphers, which require keys for those ciphers; this is very similar to SSH, TLS, and any other network encryption protocol. But in those other protocols the stream cipher keys are normally arranged on the fly through the session setup protocol and often long-running sessions will be re-keyed periodically. Periodic re-keying (if done securely) both limits the amount of encrypted data an attacker can do brute force attacks on and limits the damage of a key compromise; it's thus generally considered a good idea.

My IPSec tunnel doesn't have any of this. The stream cipher keys it uses are hard-coded into my scripts and it uses the same stream cipher keys for however long until I go through the manual effort to change them. As you might guess, this is far from ideal from a security perspective, even though my keys are completely random.

(I have a program that dumps N bits of randomness from /dev/urandom and I use that to generate keys whenever I decide to rekey.)

In theory it's possible to do better than this, because IPSec has a whole set of systems called IKE to handle exactly the job of negotiating IPSec stream cipher session keys. The problem is that in practice all of this is fiendishly complex, generally badly documented, and doesn't always actually work (at least on Linux, other environments may have better experiences). Part of the problem is that IPSec IKE systems are generally designed and documented for complex configurations where you want things like X.509 certificates and so on; simple scenarios sometimes seem like an afterthought.

(IPSec itself falls into the usual crypto obsession of having too many options and thus quite a lot of ways of blowing your feet off, in addition to the fundamental complexity that you have to understand to use it at all.)

I actually once got an IKE setup 'working' between two systems in that it could set up the initial keys but then things blew up whenever it re-keyed the ongoing connection (I believe that existing TCP connections died, but it was a long time ago so I've forgotten the details). Of course trying to figure out where the bug might be was hopeless so I just gave up (and went to fixed keys, among other things).

(There is a general lesson for security here but you can probably already guess what it is and I think I've probably mentioned it before.)

(I was reminded of all of this pain by a recent package upgrade on my Linux machines that changed things from one IKE system to another. I saw that and briefly considered trying to set up a proper re-keying IKE configuration before I began laughing bitterly at the very idea of wading back into the IKE swamps.)


Comments on this page:

From 207.172.69.99 at 2013-06-02 10:05:28:

So... why do you do this, as opposed to either an SSL VPN or SSH with tunnels (even SSH with SOCKS if you need a bunch of ports open?)

I know why I use IPsec -- site to site connections where each side is basically equivalent. The usual policy based routing mechanism is horrendous, and getting IKE set up once per site is usually OK, but debugging it is a nightmare.

-dsr-

By cks at 2013-06-02 14:39:41:

At least at the time that I set it up (and I think still now), an IPSec tunnel was the easiest and best way to basically simulate a PPP link. I wanted my home machine to act as if it was on the network at work for IP in general. It also seemed like the theoretically right way to do it (for a machine with a static IP, at least).

(This network presence applies only to selected network destinations and then one gets into policy based routing and all sorts of other fun stuff, but I would still have the policy based routing issues with any technology.)

From 87.79.78.105 at 2013-06-22 21:42:01:

Have you taken a look at sshuttle?

Aristotle Pagaltzis

By cks at 2013-06-24 13:03:03:

Based on reading the sshuttle description, I don't think it would quite do what I want. I actively want my home machine to appear as a separate IP address on the work network and to be reachable there (for whatever ports I open up and so on). Still, it's an interesting program and I'm going to have to remember it for potential future use.

(Pragmatically I also have my IPSec tunnel set up and working now, so switching to anything else would take additional work.)

From 87.79.78.105 at 2013-06-24 23:21:33:

I actively want my home machine to appear as a separate IP address on the work network

Ah – yes, it can’t do that for you.

When I found it, I had an OpenVPN setup that had been fiddly to configure, even quite insecurely, and whose routing was global (when running, it would run all my traffic through the tunnel instead of just the traffic for IPs from that network), which I’d have needed to fix myself. But that network has all public IPs, they’re just unreachable behind a firewall – except for select IPs and ports, one of which is the shell server for students. So for me, sshuttle was just what the doctor ordered.

Aristotle Pagaltzis

Written on 02 June 2013.
« The mystery of POSTs with a zero Content-Length
Security is not the most important thing to most people »

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

Last modified: Sun Jun 2 01:26:01 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.