In some countries, network operators employ deep packet inspection techniques to block certain types of traffic. For example, Virtual Private Network (VPN) traffic can be analyzed and blocked to prevent users from sending encrypted packets over such networks.
By observing that HTTPS works all over the world (configured for an extremely large number of web-servers) and cannot be easily analyzed (the payload is usually encrypted), we argue that in the same manner VPN tunneling can be organized: By masquerading the VPN traffic with TLS or its older version – SSL, we can build a reliable and secure network. Packets, which are sent over such tunnels, can cross multiple domains, which have various (strict and not so strict) security policies. Despite that the SSH can be potentially used to build such network, we have evidence that in certain countries connections made over such tunnels are analyzed statistically: If the network utilization by such tunnels is high, bursts do exist, or connections are long-living, then underlying TCP connections are reset by network operators.
Thus, here we make an experimental effort in this direction: First, we describe different VPN solutions, which exist on the Internet; and, second, we describe our experimental effort with Python-based software and Linux, which allows users to create VPN tunnels using TLS protocol and tunnel small office/home office (SOHO) traffic through such tunnels.
I. INTRODUCTION
Virtual private networks (VPN) are crucial in the modern era. By encapsulating and sending client’s traffic inside protected tunnels it is possible for users to obtain network services, which otherwise would be blocked by a network operator. VPN solutions are also useful when accessing a company’s Intranet network. For example, corporate employees can access the internal network in a secure way by establishing a VPN connection and directing all traffic through the tunnel towards the corporate network. This way they can get services, which otherwise would be impossible to get from the outside world.
II. BACKGROUND
There are various solutions that can be used to build VPNs. One example is Host Identity Protocols (HIP) [7]. HIP is a layer 3.5 solution (it is in fact located between transport and network layers) and was originally designed to split the dual role of IP addresses – identifier and locator. For example, a company called Tempered Networks uses HIP protocol to build secure networks (for sampling see [4]).
Another solution is Secure Shell protocol (or SSH). SSH is an application layer protocol, which provides an encrypted channel for insecure networks. SSH was originally designed to provide secure remote command-line, login, and command execution [5]. But in fact, any network service can be secured with SSH. Moreover, SSH provides means for creating VPN tunnels between the spatially separated networks. Unfortunately, SSH connection can be analyzed and blocked (would it be as widely spread as for example TLS protocol, things could be different).
Like SSH, OpenVPN [6] runs on top of TCP protocol (in fact, OpenVPN can also operate on top of UDP transport protocol). We have evidence that in certain countries OpenVPN is successfully blocked by governments. Of course, it is harder to detect these protocols, because traffic is encapsulated inside TCP/UDP connections. Here, deep packet inspection solutions are required in order to effectively block such tunnels.
Another widely used layer 3 protocol for building the VPNs is IPSec protocol [2]. IPSec security association can be established using pre-shared keys or using Internet Key Exchange protocols (IKE and IKEv2) [1]. Because IPsec runs directly on top of IP protocol, it can be easily detected without the usage of sophisticated packet inspection solutions.
III. HARDWARE, SOFTWARE AND ARCHITECTURE
In Figure 1 we show the general view of the architecture. Note, we assume that the SOHO VPN client box is a separate Linux box, is not on the path, and is inside the Intranet.
To implement the VPN client and server we have used the Python framework and Ubuntu Linux distribution. The implementation consists of roughly 1.2K lines of code (LOC) and all functions are realized in userspace. We have exposed the implementation in our git repository [3] so that everyone can use it without any fee.
During the experiments, however, we have considered the following setup. For hardware, we have selected a micro instance from DigitalOcean. The instance had a single-core CPU, 25 GB of data storage, 1GB of random access memory, and was located in New York, USA. The VPN client was located in Tashkent, Uzbekistan, and was spinning on a Raspberry PI microcontroller. This way we mimicked the SOHO router. We have also used wget tool to measure the throughput, and we have used ping utility to measure the round trip times.
IV. EXPERIMENTAL EVALUATION
We have made several experiments over the course of our work. The very first experiment was related to sending ping messages towards the Google DNS server and observing the differences in round trip times (basically, we have compared the round trip times between the setting in which the tunnel was present and the setting in which the tunnel did not exist).