OpenVPN and Wireless Security

1. Describe in detail the steps that two OpenVPN clients and the OpenVPN server must do to communicate with each other. Describe the entire path of data packet that travels from a client to the second, including the processing made by the server (max 2 pages).

OpenVPN is an open source soft that implements a SSL VPN. OpenVPN communicates using packets encapsulated in TCP segments or UDP datagrams. What OpenVPN offers is a secure way for two or more devices to communicate over a public infrastructure. Two nodes that want to communicate must first raise a tunnel which tries to transport the data in a secure manner. The data is actually encrypted, encapsulated and released via the public network. Considering the security measures that OpenVPN takes, encryption, authentication, integrity and non-repudiation may be mentioned.

Let us consider the following simple topology.

Firstly, in order for the communication to be possible, on the Server, virtual network interfaces must be created. In this case, since OpenVPN is configured in server mode, only one VNI is needed, since there is only one OpenVPN instance. Also, on the Server, a virtual network subnet is created and routing rules are established. Now the Server is practically waiting for connections.

Client1 wants to send a packet to Client2. Firstly, the tunnel must be established between the Server and the two clients. For this to be possible, the two clients need an IP from the virtual network subnet. An IP is given only after authentication. Every client must follow the next steps.

If the pre-shared-key authentication method is used, on one of the two devices (server or client), a “secret” is generated. This “secret” must be securely sent to the other peer using SSH or a physical device (a floppy disk or a flash). The generated “secret” contains, among other things, the Encryption key (used to encrypt the actual data) and the Hash key (used in the hash algorithm).

If certificates are used for authentication, than both devices must first generate a private and a public key. The private key always remains secret. The devices generate a CSR (Certificate Signing Request) which is sent to the CA (Certificate Authority). The CA constructs the certificates and sends them back to the devices, along with its public key. Next, the process of sharing the keys for Encryption and Hashing may begin. In our example, we may consider the Server to be the CA. In our scenario, since the case is multi-client, this is the authentication method used. The Server needs the DN for each client in order to apply the right configuration.

Now, the two clients receive IP addresses from the virtual network subnet and Client1 prepares a packet using the virtual address of Client2. The packet is pushed to the kernel and the TUN interface sends it to be encrypted and signed using the previously established key and hash; then the data is re-encapsulated inside a public packet which is sent to the OpenVPN Server.

The Server receives the packet, decapsulates it and decrypts it. Encryption must be again made, but this time using the keys and hashes established with the client that the packet is destined for. OpenVPN must decide, based on the routing rules, to which client the packet must be sent. The packet is then encrypted and re-encapsulated in a public packet and sent to Client2 via the public network.

2

Client2 receives the packet on its real interface, decapsulates it and decrypts it. The data is then sent by the TUN interface to the destined Application.

If an attacker gains access to the Server, not only could he generate a man-in-the-middle attack, but also compromise the actual data being sent. Of course, the moment of the attack is also important: before authentication, before data transfer, during data transfer. The attacker could easily change encryption keys and hashes and could even stop the authentication process, making modifications over the certificates or even removing them completely. Since the CA is established on the Server, the attacker may also generate false certificates. In this case, the secure OpenVPN would become as insecure as it could get.

3

2.

SECURING IEEE 802.11G WLAN USING OPENVPN AND ITS IMPACT ANALYSIS-summary-

Wireless LAN (WLAN) is undoubtedly the most widely used wireless technology. Besides the fact that it comes with cheapness, few components and an easy use, it provides quick access to the Internet and the Intranet almost everywhere. The downside, however, is that using the open air as medium brings up severe security issues. Since Virtual Private Networks have proven to be efficient in securing communications over wired networks, they have also been taken into consideration for securing the WLAN. Here, it is briefly explained a way to secure IEEE 802.11g WLAN using OpenVPN.

IEEE 802.11 contains the standards for implementing wireless local area network computer communications. 802.11a, b and g are mostly used. They differ in transfer rate, number of supported connections, susceptibility to interference and range.

In the beginning, the method to secure the information transmitted in WLAN was WEP (Wired Equivalent Privacy). Unfortunately, it was later proven that this protocol can be easily broken due to a number of weaknesses: short IVs and keys, crackable authentication message, no key-management protocol. Some of the attacks used to determine these vulnerabilities are: Aircrack, Dsniff, Kismet, MacStumbler, Wep0ff.

WLAN needed confidentiality, integrity, origin authentication, replay protection and this is what VPN offers with its tunneling of the data. OpenVPN is an open source soft that implements virtual private networks infrastructures (VPNs). The traffic is tunneled through the transport layer using TCP or UDP. The security is given by the OpenSSL library. Considering the location of the VPN code in the operating system, the VPNs may be kernel-based or user-space. In the user-space case, the traffic to the VPN must be turned towards the VPN application. This is made using TUN or TAP VNIs (Virtual Network Interfaces).

Figure 1. OpenVPN

For assessing the performances of IEEE 802.11 g WLAN after implementing OpenVPN, two experimental scenarios were settled. The first one had to measure the throughput under normal conditions and the second one had to analyze the throughput fluctuations when OpenVPN was implemented in WLAN. For the measurements, throughput, latency, frame loss and IP packet delay variation were used as parameters and RFC 4148 was followed. For the metrics, the following RFCs were used: RFC 2544, RFC 2679, RFC 2680, RFC 3393. For the experiment to be possible, the following equipment is necessary: two laptops loaded with Red Hat Enterprise Linux 5, Ethernet Cables, TL-WA601G 108M TP-Link Wireless Access point, SPT-2000A Spirent test center.

4

ApplicationLayer

Application 1

OpenVPN(encapsulation)

Routing Process (network layer)

IP virtual destination

IP real destination

Interface

Virtual(TUN/TAP)

Real(eth0, etc)

Interface

Virtual(TUN/TAP)

Real(eth0, etc)

Routing Process (network layer)

IP virtual destination

IP real destination

ApplicationLayer

Application 2

OpenVPN(encapsulation)

Publicinfrastructure

The setup is represented in the following figure. The measurements were performed for UDP and TCP traffic.

Figure 2. Experiment setup with and without OpenVPN (what is written in red corresponds to what was added with the implementation of OpenVPN)

The experiment has revealed that increasing the frame size, the throughput for both UDP and TCP traffic is also increased. The throughput is slightly higher when OpenVPN is implemented, with compression and lower when OpenVPN security is applied.

In what average latency is concerned, bigger frames correspond to higher latency. However, the latency decreases when OpenVPN is not implemented.

The measurements have shown that the frame loss percentage increases with the traffic, UDP or TCP.

The use of OpenVPN with compression made the IP Packet delay variation to drop.

In conclusion, the implementation of OpenVPN does not bring any improvement for 802.11 g WLAN, but if compression is used, than the measurements show an increased performance.

5

20.20.20.2(Virtual Interface)

20.20.20.1 (Virtual Interface)