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.)

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, 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.