IPSEC – A Security Disaster

It is no secret that IPSEC is far from perfect. Everything about the implementation of the now ubiquitous secure tunneling protocol was plagued with issues irrespective of the vendor. How can so many different people working for a variety of different vendors create something that is not only full of bugs and vulnerabilities but also has interoperability issues. Wasn’t this supposed to be a unified and open standard?

It seems with the benefit of hindsight we can chalk these teething problems up to subversion on the part of the NSA, who was heavily involved in the process.

John Gilmore spoke on a mailing list about the issues he had personally observed throughout the IETF process.

It seems the NSA recipe for subterfuge is as follows: take one already complicated crypto protocol spec, insert committees, add a variety of largely unnecessary features which vendors must comply with (e.g. deprecated cipher selections), add the ability of downgrade attacks through having a “null” transport in a protocol designed primarily and exclusively for crypto, let the vendors who try to implement your disaster choke on terse documentation and stir.

We don’t have to look far to see the legacy we have been left. From Linux to *BSD to Windows – all major platforms have had major implementation flaws and serious bugs in their IPSEC stacks.

The OpenBSD IPSEC controversy in 2010 centered around claims that the FBI deliberately backdoored (through a shill with commit privileges) their IPSEC implementation. After an extensive audit that wasn’t all that open De Raadt claimed that several minor bugs had been found but no smoking gun was discovered. Was this the work of another three letter agency and were some of the findings hushed up? While some claim there is more to the story than meets the eye I sincerely doubt they could have covered up the discovery and removal of such a backdoor. For starters one could simply diff the source code pre and post audit and verify what has been changed. That said, many do not compile their own kernel and simply accept the precompiled one distributed with their OS – could there have been something nasty hidden in the binary? I don’t know. That’s the problem with binaries. Perhaps future deterministic build verification tools will one day render this potential vector ineffective.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s