Opportunistic Encryption

Any host configured to use OE by publishing OE DNS records must always run Openswan, as any OE-capable hosts will refuse to communicate with it in the clear.

Be aware that private-or-clear does not mean we will talk to those hosts in the clear if OE fails to initialize properly. Openswan refuses to talk in the clear to any host that advertises OE capabilities through DNS records.

For this reason, it is important to be aware that if you configure the DNS while experimenting with OE, and you later decide to no longer run OE on that host, you must remove the DNS records that advertise the OE capability. If this defense method was not in place, an attacker could easily cause a failure of OE by filtering IKE packets, and we would happily fall back to a cleartext connection without realizing what happened. By refusing to communicate, we will notice the connection fails to start, and we can investigate what is going on, and find out we are being attacked.

Internal States

We need to remember which IP addresses do not support OE, or else we would try those addresses indefinitely. Of course, they also have to be timed out, because otherwise we would end up with a very big list of IP addresses to remember. The following table lists the OE state information we have to keep for all these IP addresses or networks.

State	Description
trap	Packets going to these network ranges need to be trapped and checked for possible OE
	IPsec processing.
tun	Packets going to these network ranges already have an IPsec tunnel established.
pass	Packets going to these network ranges should be sent in the clear without attempting OE.
hold	Packets going to these network ranges need to wait. OE is being attempted currently, or OE has
	been misconfigured.

These states, with the exception of trap, are the same states used for regular IPsec tunnels. State information can be seen with the ipsec eroute command. pass eroutes are expired after a certain time, so an OE-capable machine does not end up with thousands of them.

Configuring OE

The goal of the Openswan project is to deploy IPsec as massively as possible. Therefore, the configuration needed for OE has been kept to a minimum. If you install Openswan from source, OE will be enabled by default. Everything should work automatically, and the end user does not need to be aware that some connections are encrypted. However, OE has seen some problems, and most distributions still focus on VPN connectivity, so they tend to play safe and disable OE. This can be done by including the following line in /etc/ipsec.conf, after the default section:

include "/etc/ipsec.d/examples/no_oe.conf"

138

Chapter 6

Debian is the only distribution that asks you if you want to enable or disable OE when you install the Openswan package. Once OE sees a much wider audience and has proven to be stable on large scale deployments, we hope that more Linux distributions will start to ship Openswan with OE enabled.

Configuring Policies

The precise OE behavior can be fine-tuned using the entries in the policy files in /etc/ipsec.d/ policies. The default policy files only contain 0.0.0.0/0 in private-or-clear, which means OE will be attempted for all hosts, falling back to cleartext if the remote hosts do not support it.

Especially if you are new to OE, it is recommended to add the name servers from /etc/resolv.conf in the clear-or-private policy. This will prevent the cascade failure in the first minute of trying to use OE for the name servers, and makes OE functional from the start of Openswan.

To configure passive OE on a server, remove the 0.0.0.0/0 entry from the private-or- clear policy file and add it to the clear-or-private policy file.

Full OE or Initiate-Only

When Openswan starts, it tries to find out whether full OE is possible. It will regularly check for its own public key in the reverse DNS of its IP address.

If Openswan finds its own key based on the current IP address, it will run with full OE capabilities. If the section config section contains a myid= statement, that value is used as leftid= in the IKE protocol to enable initiate-only OE, if a valid DNS record is found for the host name specified in the myid= setting. If you specify a host name for myid=, do not forget to prepend the @ symbol to prevent it from being resolved to an IP address.

If the host is on a static IP address, and you control the reverse DNS for that IP address, you should set up TXT and IPSECKEY records in the reverse and enable full OE. If you do not control the reverse, you should create TXT and IPSECKEY records for the hostname in the forward zone. If your name server does not support the IPSECKEY record, you can use the KEY record instead, but remember that this should be avoided since RFC 3445 restricted the use of KEY records to DNSSEC only.

Generating Correct DNS Records

The ipsec showhostkey command is used to generate the proper public-key DNS records. For instance, if we wish to generate a TXT record for bofh.xelerance.com, which has a static IP address of 193.110.157.17, we use the following command on bofh.xelerance.com:

# ipsec showhostkey --txt 193.110.157.17

; RSA 2192 bits	bofh.xelerance.com Thu Oct 17 12:32:33 2002
IN TXT	"X-IPsec-Server(10)=193.110.157.17" "AQOkF1Ggd4iFfI2

nQxJYbN9HGDhhIAKIXrG3+MCoAPX+z+fNI9j7rxxR9QhThIZZeOx+X9WB4hIa8/8xAnELmcRhkD8

CxfznE4tCQ/Ws+9ibXUdD8Wee3JusSMrmLCuIScNUQuBtRe+l+nn16dzvw3/PGB67gid+AvGvJJJ

nxiFjibd/4ayVebJRj6Bu/FRexpXr3jEgg0TJwxu9y1xBR7i0tRYCdSQPKNClNrgmX7YZTp4bu6g izhil63/sR6" "8eAqUz/DctDFDv7nrYsGDgGnfs03ncbY2m3lyPoiJyRJ34f4SILUBm+V44B5js NDwFj7qx6wJ+dmXVkM7JGp5yLo93mfAhdKAcm5JkOpek2HszzO13"

139

Opportunistic Encryption

You can use this data (called RRdata) to create a record both in the reverse DNS, in this case under 17.157.110.193.IN-ADDR.ARPA., and in the forward zone under bofh.xelerance.com. In our case, we add the following entry to our 157.110.193.IN-ADDR.ARPA. zone:

17.157.110.193.IN-ADDR.ARPA. IN TXT "X-IPsec-Server(10)=193.110.157.17" "AQN [...]"

In a similar way, we add the "IN TXT...." part in the zone for xelerance.com:

bofh.xelerance.com.	IN	TXT	"X-IPsec-Server(10)=193.110.157.17"
"AQ[...]"

Older versions of this command used to return a # instead of a ; for the first comment line, which breaks the zone, since # is not a valid comment character for the BIND name server. Make sure you do not paste in lines that mistakenly use # symbol as a comment character.

You can also see that the key has been cut in two parts, each in double quotes, separated by a space. This was a workaround for an obscure BIND bug. Even if you do not use BIND yourself, it is safer to keep it in case some upstream ISP uses BIND. However, this syntax is not compatible with some other DNS implementations such as djbdns, in which case you cannot use it and should remove the inner quotes and spaces and turn this into a single continuous string.

Similarly, you can create the old KEY records. You cannot specify a gateway or preference with this record type:

#ipsec showhostkey --key

;RSA 2192 bits bofh.xelerance.com Thu Oct 17 12:32:33 2002

bofh.xelerance.com. IN KEY 0x4200 4 1 AQ[...]

You can change bofh.xelerance.com for 17.157.110.193.IN-ADDR.ARPA. and use this key record in the reverse as well.

And of course, you can use the command to generate the new IPSECKEY records. You need to specify a priority (1-255) and a gateway:

#ispec showhostkey --ipseckey 10 193.110.157.17

;RSA 2192 bits bofh.xelerance.com Thu Oct 17 12:32:33 2002

bofh.xelerance.com. IN IPSECKEY ( 10 5 193.110.157.17 AQ[...] )

The second argument within the brackets is the public key algorithm, 5 being RSA. If no gateway is specified, for instance because this entry is for initiate-only DNS in the forward zone, then . is inserted as the gateway.

Name Server Updates

Remember that after changing the DNS, it might take a while before the updated records appear, especially on secondary name servers. Be careful when triggering an OE connection to a remote host too soon, because if that remote host caches the negative DNS response "there is no key", it will only want to talk in the clear to your end, while your end is likely restarted and updated and will only talk encrypted to the remote host. This deadlock will remain until the remote clears its cache, when the TTL is reached.

140

Chapter 6

As always, do not forget to increase the serial number of the zonefile, or else the secondary nameservers will never pick up your new OE record.

Verifying Your OE Setup

The ipsec verify command displays the relevant settings for OE. It is best to run this when Openswan has been shut down, so that packets sent or received by this verification process are not dropped because of OE policies. Alternatively, if you have a clear policy for your name server, you should be able to run ipsec verify when Openswan is already started.

# ipsec verify

. . .

Opportunistic Encryption DNS checks:

Looking for KEY in forward dns zone: bofh.xelerance.com [DEPRECATED]

Looking for TXT in forward dns zone: bofh.xelerance.com [MISSING]

Looking for IPSECKEY in forward dns zone: bofh.xelerance.com [MISSING]

Does the machine have at least one non-private address? [OK]

Looking for IPSECKEY in reverse dns zone: 17.157.110.193.in-addr.arpa. [MISSING]

Looking for TXT in reverse dns zone: 17.157.110.193.in-addr.arpa. [OK]

Looking for KEY in reverse dns zone: 17.157.110.193.in-addr.arpa [DEPRECATED]

We can see here that the old-style deprecated KEY records are still in the DNS for our bofh.xelerance.com host. A KEY record also appears in the reverse at 17.157.110.193.INADDR.ARPA. And a TXT record for bofh.xelerance.com is missing from the forward zone, but it does have a TXT record in the reverse. This is not a problem because the machine is actually on a static IP address, and therefore able to use full OE. It does not need a TXT record in the forward, because the reverse record is always valid for this host. New-style IPSECKEY records have not been added for this host yet.

Furthermore, when you start Openswan, and OE is enabled, you should see the following entries in the log:

Nov 7 20:26:23 bofh pluto[1970]: loading group "/etc/ipsec.d/policies/private"

Nov 7 20:26:23 bofh pluto[1970]: loading group "/etc/ipsec.d/policies/private-or-clear"

Nov 7 20:26:23 bofh pluto[1970]: loading group "/etc/ipsec.d/policies/clear" Nov 7 20:26:23 bofh pluto[1970]: loading group "/etc/ipsec.d/policies/clear- or-private"

Nov 7 20:26:23 bofh pluto[1970]: loading group "/etc/ipsec.d/policies/block" Nov 7 20:26:57 bofh pluto[1970]: using our IP (193.110.157.17:TXT) as identity!

141