Encrypting the Local Network

If you are using KLIPS on the client, you can run tcpdump in one window, and ping a random machine on the Internet in a second window. You should only see encrypted packets with tcpdump. Remember that you should not test the encryption by pinging the gateway itself, since the gateway is part of the local subnet, which is not protected by WaveSEC unless you duplicated the 'routing trick' for the LAN by splitting those in two half routes into the ipsecX interfaces as well. If we are able to use NETKEY in the future, it should work for both LAN and remote addresses, but you would have to run tcpdump on another machine, to snoop the traffic.

Starting the WaveSEC Connection

When dhclient has finished all its work, it checks for the existence of a file called /etc/dhclient-exit-hooks. If it exists, it will execute it. We use this script to fire off our changes into the DNS and to fire up the WaveSEC connection.

if [ -n "$new_oe_gateway" ] then export new_oe_key

#. /etc/ipsec/wavesec_setup.sh $new_ip_address $new_oe_gateway $new_routers

fi

Known Issues with WaveSEC

First of all, there is nothing we can do to prevent a user from associating with a rogue AP. Until APs get cryptographically signed beacons, the risk of such an active attack will remain.

Another possible active attack is a man-in-the-middle attack on the DHCP protocol. Instead of connecting to the real DHCP server, we accept a rogue DHCP server's offer and encrypt everything to the attacker's key. The IETF DHC working group is currently working on securing the DHCP protocol. This will likely involve using DNSSEC.

WaveSEC cannot coexist with Opportunistic Encryption, and this is true for both the WaveSEC server and client. This happens because in choosing the outgoing packet path, two eroutes would conflict, and neither connection will work. Passive OE may not cause the same problems.

In inline mode, IPs once used for WaveSEC are not recycled cleanly. In particular, the IPsec tunnel remains routed from the server's perspective. For this reason, once you have set up WaveSEC on your laptop, you must continue to use it. The problem has several potential solutions, as yet unimplemented.

The biggest problem though, is the steep learning curve in setting up WaveSEC. We hope to provide distribution packages in the future that greatly simplify setting up WaveSEC. This should become easier as more distributions move to more flexible, though complex, DHCP client setups using the Zeroconf protocol.

WaveSEC for Windows

The problem with Windows is that we do not control any part of the DHCP or IPsec subsystem on the clients. We cannot hook Openswan additions into Windows, so we are left with the normal features of this OS.

248

Chapter 10

The WaveSEC for Windows solution consists of two parts. The first part securely obtains an X.509 Certificate generated on the fly. The second part negotiates an IPsec tunnel to the default gateway, which will carry all the traffic.

We use a redirect to a web server using SSL for this part, similar to how hotspots redirect you to their login page. To make things easier, we provide a tool to import the X.509 Certificate called certimport.exe. We also use a tool to make configuration of the Windows IPsec tunnel easier. This freely available tool, called lsipsectool.exe, is available on SourceForge.net. It provides a clear interface, and a tray icon, and takes care of shutting down the connection for us.

This solution of adding software onto the Windows machines is far from ideal, since it requires that the user installs software from an unknown source, but Microsoft really left us without any better alternative.

Design Limitations

This version of WaveSEC is really a better than nothing solution. The user has to install untrusted software. Worse, because Microsoft can only use IPsec X.509 Certificates for the 'Computer Account', installing the X.509 Certificate requires Local Administrator privileges. Not everyone with a company laptop actually has these privileges

This solution also clashes with any other running IPsec software, such as Nortel, Cisco, or other third-party products.

249