Encrypting the Local Network
Our prototype code detects the client connecting from the HTTP USER_AGENT string, and will redirect the client to the respective pages for Windows 2000, Windows XP, Linux, or 'Unknown'. The reason for the difference between 2000 and XP is that different DLLs were needed for our prototype WaveSEC client using the ipsec.exe tool. This tool is based on the Microsoft Resource Kit DLLs, which are different for Windows 2000 and Windows XP. This difference is not relevant
with lsipsectool.exe.
The files for the client have been bundled using the NullSoft Installer Software (NSIS) for Windows. The .nsis file used is also available at ftp.openswan.org.
Unfortunately, this means we cannot bundle the client as an EXE file with the X.509 Certificate, since we cannot rebuild the client executable using NSIS on our Linux-based WaveSEC sever.
Our Prototype Experiences
We found a few oddities when deploying WaveSEC at the BlackHat security conferences and at the DefCon hacker conference.
252
Chapter 10
Openswan Issues
Openswan ignored some Delete/Notify requests from Windows. This bug has since been fixed, but still, when someone closes their Windows laptop, there will be no Delete/Notify, and the IPsec tunnel to that IP address stays up. No one will be able to use that IP address until the conn expires. Therefore, short keylifes (keylife= and ipseckeylife=) should be used in combination with uniqueids=yes, which will cause old connections to die if the same X.509 Certificate (meaning the
same laptop) shows up later on another IP address. This is the same reason why we use rekey=no on the server side. If the client is not there, we assume it left or died, and we tear down the tunnel, making the IP address available for a future client. Unfortunately, Microsoft does not support the Dead Peer Detection extensions to the IPsec protocol, which would be ideal for this situation.
Windows Client Issues
The ipsec.exe tool led to a few further problems. Sometimes running ipsec -off to kill the IPsec connection did not work properly. Some people closed their laptop when the tunnel was up. When they got home, they probably spent some time wondering why their laptop did not work, until they realized that all their traffic was still being sent to an unreachable WaveSEC server at the conference center. Worse, if they de-installed the WaveSEC client while the IPsec tunnel definitions were still active, they could no longer easily remove them using the ipsec -off command. And they likely did not know how to delete them using MMC. And yes, these definitions do survive a reboot too.
We hope that these issues will not happen with lsipsectool.exe, since that application has much better Windows integration, and features things like a tray icon that could act upon events such as closing the lid, or shutting down the machine.
Windows Kernel Issues
We encountered two important problems with the Windows IPsec implementation, though these issues could be due to how ipsec.exe interfaces with the Windows kernel IPsec stack.
The first problem occurs when the WaveSEC server is not the default gateway, when some Windows systems do not properly tunnel all traffic through the WaveSEC server, but instead try to send traffic to the default gateway. This unfortunately means that the WaveSEC server has to be in an inline position, instead of being in an appendix position, and therefore becomes part of the critical infrastructure.
The second problem also appears when an appendix mode setup is used, and the upstream router sends packets directly to the WaveSEC clients instead of via the appendix mode WaveSEC server. Windows then receives plaintext packets, since these packets only get encrypted on the WaveSEC server that is being bypassed now, and to our surprise, does NOT drop them. Of course, if a host has an IPsec SA up, it must never allow (possibly spoofed) plaintext packets. Again, this could be a bug in the ipsec.exe client setting up the Windows kernel IPsec stack, or a bug in Windows itself. We have not recently verified this issue with either an updated Windows machine or with the preferred lsipsectool.exe client.
253