8.2. VTun

VTun (Virtual Tunnel) is a simple VPN that uses the tun device (FreeBSD, OpenBSD, NetBSD) or the tun/tap device (Linux, Solaris) to copy packets between the TCP/IP stack and the vtund program running in user space. Architecturally, VTun is similar to the SSH VPN that we built in Chapter 7.

VTun supports four types of tunnels:

IP	IP datagrams, after encryption and optional compression, are carried as payload data in either TCP segments or UDP datagrams.
Serial	VTun provides a virtual PPP connection, similar to that in Figure 4.3, in which the PPP frames are encrypted, optionally compressed, and transported in either TCP segments or UDP datagrams
Ethernet	After encryption and optional compression, Ethernet frames are carried as payload data in either TCP segments or UDP datagrams. This type of tunnel is similar to the IP tunnel except that Ethernet frames instead of IP datagrams are tunneled. This means that any type of network-layer protocol, not just IP, can be carried in the tunnel as long as it can use Ethernet as the interface layer.
Pipe	This type of tunnel is similar to using SSH to tunnel a user command. The input and output of the tunnel are pipes, so the output from a local program can be fed directly to the tunnel, which pipes it to the input of another program on the remote host. This type of tunnel is a sort of superpipe that operates across a network while encrypting/compressing the data it carries.

All these tunnels are similar to ones that we saw in Chapter 4. The IP and Ethernet tunnels merely connect the user-space vtund application to the bottom of the TCP/IP stack through the tun or tun/tap device. This configuration is illustrated in Figure 8.1.

Figure 8.1. IP and Ethernet Tunnels with VTun

[View full size image]

As with Figure 7.58, this diagram is a little misleading because the traffic flowing through the tunnel must first travel through the TCP/IP stack again.

The configuration for the serial tunnels is similar to that shown in Figure 8.1, except that IP datagrams from the stack are first delivered to the PPP routines, where they are encapsulated into PPP frames. In the case of Linux and Solaris, the PPP routines are part of the kernel. In the case of FreeBSD, the PPP functionality is provided by another user-space application. In either case, the PPP frame is delivered to vtund, which sends it through the tunnel to the peer PPP routines in the remote host.

The configuration for the VTun pipe tunnels is shown in Figure 8.2.

Figure 8.2. The VTun Pipe Tunnel

[View full size image]

In this case, each user application talks directly to vtund through pipes rather than using the TCP/IP stack. With this type of tunnel, vtund is providing application-to-application connectivity rather than a network-to-network connectivity.

Data entering a VTun tunnel can be operated on by any combination of three modules. The first module compresses the data, using either ZLIB, when TCP carries the payload, or LZO, when UDP carries the payload. The second module encrypts the data, and the third module performs traffic shaping by limiting the amount of bandwidth that a particular tunnel can use. The modules to use are chosen by a configuration file, as are the other tunnel parameters.

The VTun Authentication Procedure

In a VTun VPN, one gateway plays the role of a server, and its peer gateway plays the role of a client. The vtund process can operate in either role. During tunnel establishment, the client authenticates itself to the server with the challenge/response protocol shown in Figure 8.3.

When the client connects, the server informs the client of its version by sending a string of the form VTUN server ver 2.6 10/05/2004. The client responds with its host name by sending a string of the form HOST: linuxlt. When it receives the client's host name, the server generates a 16-byte random number and sends it to the client as a string of the form OK CHAL: <xxx>, where xxx is the challenge encoded as 32 characters from the set {a,. . . , p}, each character representing 4 bits of the challenge.

The client encrypts the challenge with a shared secret that it obtains from the configuration file and returns it to the server as a string of the form CHAL: <yyy>, where yyy is the encrypted challenge encoded as 32 characters from {a,. . . , p}, as before. If the decrypted challenge is correct, the server signals its acceptance of the client's authentication by returning the string OK FLAGS: <PtO>, where PtO is a set of character flags that describe the tunnel parameters. If the client fails the authentication, the server returns the string ERR.

The P flag indicates whether the payload should be carried in TCP (T) segments or UDP (U) datagrams. The t flag indicates the type of tunnel: u for IP, e for Ethernet, t for serial, or p for pipe.

There are five possible options, three of which take values. The options and values are shown in Figure 8.4.

Figure 8.4. VTun Tunnel Parameter Options

Option	Value	Meaning
S	bandwidth	limit amount of bandwidth for the tunnel
C	level	use ZLIB compression at the specified level
L	level	use LZO compression at the specified level
K		keep-alive flag
E		encrypt tunnel data

After authentication, traffic can begin flowing through the tunnel. As it enters the tunnel, traffic is first compressed, if desired, then encrypted. If traffic shaping was selected, it is applied to the data after encryption. Finally, the data is encapsulated in a TCP segment or a UDP datagram and sent to the peer gateway, where these steps are reversed.

A typical UDP encapsulation for an IP tunnel is shown in Figure 8.5.

Figure 8.5. VTun IP in UDP encapsulation

[View full size image]

Because the encrypted data is carried within a UDP datagram, VTun will not experience problems with NAT/PAT. PAT will use the port fields from the unencrypted UDP header (Figure 2.14) to map IP datagrams between the internal and external addresses. Similarly, when the tunnel uses TCP to carry the encrypted data, PAT can use the TCP port fields (Figure 2.16) for the mapping. Using UDP encapsulation has the advantage that the VPN will not suffer from the problems that we saw in Chapter 6 and Chapter 7 of having two reliability layers.

VTun Security

VTun uses the OpenSSL library (Chapter 6) to provide encryption services but does not make use of the SSL protocol itself. Rather, VTun uses SSL merely to provide the encryption algorithm it uses for authentication and encryption, the SSL MD5 implementation it uses to convert a shared secret to an encryption key, and the SSL random-number generator it uses to create the random challenge.

If the SSL library is not available, VTun will not encrypt the tunnel traffic but will still use the challenge/response protocol for authentication. Unfortunately, VTun generates the random challenge by using the standard C library function rand (seeded with the current time) and encrypts it by exclusive-ORing the shared secret into the challenge. As we saw in Chapter 3, these are fatal practices. In VTun's case, this is especially deadly because the challenge is available to an attacker as both plain- and ciphertext. This means that the attacker can trivially recover the shared secret (see Exercise 8.2).

As of this writing, the current stable version of VTun is version 2.6. This version supports only 128-bit Blowfish encryption, which it uses in ECB mode (Chapter 3) for both client authentication and encryption of the tunnel data.

Version 3 of VTun will support AES and Blowfish in several modes with key sizes of 128 or 256 bits.

As we saw in Chapter 3, ECB mode allows an attacker to identify identical blocks in the ciphertext, subjects the cipher stream to replay attacks, and makes insertion and cut-and-paste attacks particularly easy. For these reasons, the use of ECB mode in a VPN is a serious weakness.

This weakness is compounded by the fact that VTun does not use a MAC to authenticate each data block. As we've seen, this is another serious weakness that opens the cipher stream up to manipulations of various types, such as cut-and-paste and replay attacks.

Because VTun does not sequence number its blocks either explicitly or implicitly, any block can be replayed without detection. If we consider financial transactions, such as fund transfers, we see why this can be a devastating weakness.

Finally, VTun's security ultimately relies on a single, long-lived shared secret. As we've seen before, this represents another serious weakness because such keys are subject to physical compromise and because they allow an attacker to accumulate and analyze a large amount of ciphertext encrypted with the same key. This problem is exacerbated in VTun because the challenge/response protocol provides pairs of ciphertext and the corresponding plaintext, enabling known text attacks on the underlying encryption algorithm.

VTun's security is sufficiently weak that it shouldn't be used in circumstances that require anything more than the most casual security. We could use it as a sort of low-level cloaking protocol in situations where the data is of low value and active attacks are not a threat, but there are other, better protocols that share VTun's simplicity while delivering better security.

See [Gutmann 2003b] and [Etienne 2001] for further analyses of VTun's security.