Chapter 6
ever designed, the Domain Name System (DNS). And the only information we need from the remote host is its public key. If we can retrieve the remote host's public key and the remote host can retrieve our public key, we could set up an IPsec tunnel.
The DNS would function as a trusted third party between the two hosts who want to communicate. And furthermore, we can have the DNS records point to other servers to delegate the IPsec tunneling to. So even if you have a server that does not support OE, you can add a DNS record for that server pointing to another (close by) server that will handle the IPsec tunnels on its behalf. This allows us to encrypt most of the way for servers that do not natively support OE.
Trusting the DNS?
Of course, there is one other problem with the DNS: it is not secure. Currently, anyone can spoof DNS answers or pollute DNS caches. Or someone can execute a man-in-the-middle attack and pretend to be the remote host you are trying to connect to, and you end up with a secure connection to the wrong host. Before discarding the DNS as a valid method of security, however, it is important to examine the two methods of breaching the security of communications between two hosts.
Firstly, an attacker could passively sniff network traffic and eavesdrop on the connection. Anyone can do this. If you are drinking your coffee in Starbucks right now, browsing the Internet on your laptop, the person next to you might be monitoring every site you visit. This is called a passive attack. Passive attacks are easy, but they generally are not targeted. People run sniffers and just wait until interesting information comes along. Passive attacks hardly cost any resources, and can (in theory) be undetectable.
The second method of attack is an active attack. An example of an active attack is a man-in-the- middle attack. Here, the attacker pretends to be someone else, or sends you malicious information to trick you into communicating with them instead of the host you were trying to reach. An active attack is targeted. It takes resources, it requires brains, it is hard to automate, and it can be discovered. There is an important legal difference between passive and active attacks. While a passive attack can be morally wrong, it is often still on the borders of legality. An active attack is almost always a criminal offense. Passive attacks are relatively easy to attempt, while active attacks are much more complex and therefore a rare occurrence. Unless of course, you are specifically targeted during, say, a business meeting.
Now if we go back to our goal of ensuring no one can eavesdrop on us, then we see that the most important type of attack to thwart is the passive attack. It would be nice to also be able to thwart the active attack, but we will get to that later. Preventing passive attacks is what is going to prevent the most attempts to eavesdrop on us. After that, we can focus on those few malicious hackers that are trying to specifically target us.
OE in a Nutshell
Opportunistic Encryption is a means of initiating IPsec tunnels to remote hosts by publishing and retrieving public keys from the DNS. We publish our own public key, and the remote server publishes its key, and then both servers can obtain the other's public key and set up an IPsec tunnel. No other pre-arrangement is necessary. This is a symmetrical process, and any host can initiate OE to
133
Opportunistic Encryption
another host. They are equal peers. However, for simplicity, we will sometimes talk about the server and the client. The intended meaning is that the client initiates, and the server responds.
If we use DNS to store our public keys, this will protect us against all passive attacks. If on the other hand DNSSEC is used, we are also protected against active attacks. The verification of DNSSEC records is not done by Openswan itself, but by the resolver library, which is called through a helper application, lwdnsq. Currently, BIND-9 is the only resolver that supports DNSSEC.
To enable DNSSEC processing, one needs to install a DNSSEC-capable local resolver (such as BIND-9), and enable it in /etc/resolv.conf. Openswan needs to be compiled with support for lwdnsq, by enabling USE_LWRES in Makefile.inc.
The identity of a host is more or less coupled to the IP address of that host, though the initiating end can actually specify a fully qualified domain name (FQDN) within the IKE channel as well. This means that clients behind NAT have some problems running OE, since it is hard to distinguish between a benign NAT situation and a rogue man in the middle.
If a server supports OE, it will have published a special DNS record containing its public key. On a client that supports OE and which tries to connect to a new IP address, the initial packet is trapped and cached within the kernel (for KLIPS; NETKEY unfortunately still drops this packet) and Openswan is signaled with the IP address that some program was trying to connect to. Openswan will do a DNS lookup to determine if the remote host supports OE. If not, the cached packet(s) are released in the clear. No encryption will take place for this IP address. If the remote host does support OE, Openswan fetches the public key via this DNS record, and it will initiate an IPsec connection using a self-made instance of the OE connection that uses authby=rsasigkey. The remote end will respond to the IKE request and, after it has fetched our public key from DNS, will be able to set up its end of the IPsec tunnel.
An OE Security Gateway
OE can also be used through another machine. This way, even when the target machine itself does not support OE or IPsec in general, the machine right in front of it can encrypt most data on behalf of the target machine.
If client A is trying to talk to the non-OE server, they set up an IPsec tunnel to the OE IPsec Gateway, resulting in all but the last hop being encrypted. For this to properly work, the non-OE server should have the OE IPsec GW in its network path somehow. That is, it cannot be the machine next to it; it has to be a machine in front of it. Otherwise the non-OE server, which knows nothing about IPsec, would send client A packets back that would not pass through the OE IPsec GW, and would therefore not be encrypted (and worse, because there is an IPsec policy in place, would also get dropped at the client).
134