Obfuscating VPN Traffic

(1)

Obfuscating VPN Traffic

JJF Derksen

August 22, 2018

Supervisor: dr. ir. Marc X. Makkes Universiteit van Amsterdam Rogier Spoor SURFnet

Host organisation: SURFnet,https://www.surf.nl

Universiteit van Amsterdam

Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering

(2)

Abstract

Virtual private network (VPN) connections ensure privacy as well as security between two connected computers on the Internet. However some countries and companies do not allow the use of VPN connections and use a firewall to prevent the use of VPN. Header information of network traffic from VPN connections contains recognisable characters. Firewalls can use these recognisable characters to detect VPN connections. To avoid VPN connections being actively used, firewall setups can limit these connections in different ways, for example: connections can be down throttled, disconnect by sending termination packets or blocked completely. When VPN connections can no longer be used, users would lose privacy and security of the internet connection. To prevent detection, VPN traffic could be obfuscated to mimic the same patterns as Transport Layer Security (TLS) traffic.This thesis investigates various OpenVPN solutions created. The solutions obfuscate the VPN related header information characters of a connection. In addition, we show that VPN servers can be configured such that they are undetectable, except for authorized users. The results of this thesis show that VPN servers can remain undetected for any unauthorised user when recognisable header information characters of VPN connections are obfuscated. Despite this obfuscation there are still vulnerabilities making it is still possible to detect VPN connections. The detection of VPN connections is accom-plished by monitoring network traffic on various OpenVPN servers. The Thesis results on the various OpenVPN servers are compared to the network traffic of TLS connections.

(5)

Chapter 1

Introduction

Internet traffic is subject to monitoring. Monitoring of network traffic happens when using the internet in a company with strict firewall rules or in a country that enforces strict firewall rules, such as China [NS14] or Iran [AAH13]. All network traffic passing the firewall will be initially monitored on header information. When creating an internet connection within a network with firewall rules, these rules determine which network traffic is passed through and which network traffic will be throttled, disconnect or blocked [SB14]. In addition, the network enclosed by the firewall can determine your geographical location by using the internet protocol (IP) address of a client request. To protect against firewalls throttling, disconnecting or blocking network traffic, a virtual private network (VPN) connection can be used when exchanging network traffic.

A VPN connection provides secure communication over an unsecured internet connection. This is done by creating a virtual tunnel between the source, the client device, and the endpoint, the VPN server. The endpoint will act as the origin of the traffic request. This masks the true origin of a user request. This makes it impossible to determine the origin of a traffic request made from a VPN end-point. The network traffic between client and VPN server is encrypted. Therefore, firewalls are not able to distinguish network traffic as anything other than VPN network traffic. When users want to create a VPN connection, they can choose among multiple VPN protocols. The most common proto-cols are internet protocol security (IPSec) [Ken05], point-to-point protocol (PPTP) [HPV+₉₉_{], layer} 2 tunnel protocol (L2TP) [TVR+₉₉_{] and VPN solutions that use a hybrid form of the aforementioned} procols, like OpenVPN [Kei17].

A VPN client can initiate a VPN connection by starting a handshake. This handshake is an in-teractive agreement to use a specific protocol and parameters. On completion a secure cryptographic communication channel is established. VPN network traffic has VPN related characters, which makes it distinguishable from other network traffic. Firewalls monitoring network traffic can pick up on these characters when analysing network traffic, thereby making it possible for a firewall to detect VPN connections [PBUK07,GLMG16,PJL+₁₂_{]. If the encryption algorithm is secure, the payload remains} secret. However, since the initiating of a VPN connection or an existing connection can be detected, firewalls that disallow the use of a VPN can throttle, disconnect or block the VPN server. This makes it impossible for users to freely interact with the internet in a secure and anonymous way on any network. Therefore, we aim to present a solution to prevent a VPN server from being detected as well as the network traffic of the VPN server. As long as the VPN server and its connections will not be detected there is no reason to block or destroy any connection to the VPN server. This thesis will therefore investigate the obfuscation of an OpenVPN connection, making it possible for user to always create a private internet connection. The OpenVPN connection will be obfuscated by encrypt-ing VPN related characters and convertencrypt-ing the network traffic to resemble a transport layer security (TLS) connection. TLS uses the transmission control protocol (TCP) [Pos81] to transport network traffic; therefore, we obfuscate the OpenVPN network traffic using the TCP protocol in OpenVPN. The differences in protocols will be described and a solution to obfuscate the OpenVPN network traffic will be presented.

In this thesis, we make the following contributions

(6)

VPN server setups are tested on their detectability (Section5.2).

• Monitoring the network traffic of various OpenVPN servers. The differences in network traffic are shown.

• Analysing VPN network traffic and TLS network traffic. The differences in network traffic are compared using the various OpenVPN servers connections and a TLS connection.

We aim to configure a VPN server that will not be detected, when it is running on a server and the server is exchanging network traffic with a client. The VPN server will not be blocked and connections will not be destroyed. Users will alway be able to create a private and secure internet connection using the VPN server. Through the contributions and by creating an undetectable VPN server we aim to answer the following research question: How can one hide a VPN connection to prevent a third party from detecting, destroying or blocking the connection between a client and a VPN server?

To help answer this research question, these sub-questions have been formulated: • How can an OpenVPN server be detected?

• How can a VPN connection be detected?

• Which criteria should hold to improve obfuscation of an OpenVPN connection?

The rest of the paper is organised as follows. The related work is presented in Chapter2, followed by the protocols of the technologies used presented in Chapter 3. Chapter 4 describes the experiments designed to explore the OpenVPN configuration to be tested. Chapter5 presents the results of the experiments conducted. An analysis of these results is then conducted and discussed. Chapter 6 answers the research question and sub-questions. Suggestions for future work to obfuscated VPN connections are discussed in Chapter7.

(7)

Chapter 2

Related work

To ensure that a VPN connection will not be detected, a VPN server, as well as the connection, should be indistinguishable from a TLS connection. The detection of a VPN server is performed using ”active probing”. Ensafi et al. [EFW+₁₅_{] describe ”active probing” as passively monitoring the network for} suspicious traffic, actively probing the corresponding servers and blocking those determined to run circumvention services. The controlling organ, which is the organ that controls the firewall rules of the network, issues its own probes to send a request to a server and observe the server response, resulting in gathering information about a suspicious server. The gathered information can be used, by the controlling organ, to update firewall rules. We use the model of ”active probing” to determine the detectability of the VPN servers in this thesis.

Zander et al. [ZAB07] describe the converting of network protocols in the following way. Many of the existing covert channels in network protocols follow the security through obfuscation approach. Indus-try products still lack methods to deal with covert channels. Several methods are used to obfuscate packet payload and hide the true protocol being used to transport network traffic. Dyer et al. [DCS15] describes three categories of obfuscation methods: obfuscation methods that use encryption to fully randomise the sent message, obfuscation methods that tunnel traffic using existing software artefacts and obfuscation methods that use encryption in combination with lightweight ciphertext formatting to make network traffic mimic a protocol that is allowed. The obfuscation methods of mimic a proctol presented in the paper will be used in this thesis. We will use this model to examine the possibility of using ciphertext formatting to make OpenVPN network traffic mimic the TLS protocol.

Much progress has been made in improving obfuscation methods. Despite this progress, shortcom-ings in these methods result in allowing the obfuscation methods to be reliably detected. Depending on the obfuscation method chosen, an attack can be used to detect the obfuscation. There are vari-ous attacks for varivari-ous obfuscation methods, depending on the obfuscation the attack expecting the highest success can be chosen to use [WDA+₁₅_{]. These attacking methods used have to be taken} into consideration when creating obfuscation. The attacking methods should not be able to detect the obfuscation of the VPN network. Using these attacking models presented we can determine if the solution presented in this thesis is obfuscated. This will give an indication of the obfuscation of the OpenVPN network traffic.

(8)

Chapter 3

Background

This Chapter describes the technologies used for the experiments in this thesis. We start by examining how network traffic is exchanged between a client and a server. We explore the differences in the TLS 1.2 and the TLS 1.3 version. Next, we describe how VPN traffic is created. Finally, we examine how OpenVPN network traffic is created and exchanged. Within OpenVPN we examine an option to obfuscate the network traffic.

3.1 Network traffic

TCP/IP network communication goes through a standardised protocol to start and continue commu-nicating when using the internet and similar computer networks. When computer systems want to start communication the internal structure and technology used are not considered for the network communication. The communication between different systems is possible through well-defined proto-cols. When transporting data, the communication protocol describe how this data must be packaged, labeled with an address, transmitted, routed and received. All this can be displayed as a model. There are several conceptual models, such as the open systems interconnection model (OSI) [DZ83] and the TCP/IP model [Ala14].

The OSI model has seven network layers (the physical, data link, network, transport, session, presentation and application layers), while the TCP/IP model has four network layers (the data link, network, transport and application layers). Each layer communicates through an exchange protocol data unit with its lower or high layer. Each protocol data unit has a payload along with protocol-related headers or footers. This means that from the application layer to the last layer, header or footer data is added to the payload, making the size of the packet to be transmitted larger than the payload alone. With the header or footer information added to the payload, the protocol used can be determined.

As stated earlier, we focus on the network communication between the client and VPN server provided by TCP. TCP creates a host-to-host connection at the transport layer of the OSI and TCP/IP model. At this layer, the protocol handles all handshaking and transmission details. When TCP is used to stream data, it guarantees that it resends data that is damaged, lost or delivered out of order. Damage is detected by adding a checksum to each segment transmitted that can be used by the receiving host to check the correctness of the segment. Data loss or duplication is detected by using acknowledgments (ACK) from the receiving host and by adding sequence numbers to each transmitted segment in which out of order deliveries are detected. The TCP segment consists of a segment header and a data section. The TCP header contains ten mandatory fields and an optional extension field for padding from the TCP segment.

TLS

TLS is a cryptographic protocol that provides communication security. TLS aims to provide privacy and data integrity between communicating devices. This is done using encryption, authentication and data integrity checking. Currently TLS 1.2 [DR08] is mainly used. However, recently the draft for TLS

(9)

1.3 [KPW13, Res] has been proposed. There are major functional differences between TLS 1.2 and TLS 1.3. The algorithms that are considered legacy have been removed as well as some cipher suites. Key derivation functions have been re-designed, cryptographic improvements have been made and the TLS 1.2 negotiation mechanism has been deprecated in favor of a version list in an extension. New functionalities are that the handshake messages after the server hello messages are now encrypted, a session resumption can be done with pre-shared keys and a 0 round-trip time. The round-trip time is average response to changes. These changes have been made with the promise of enhanced security and speed. However, TLS 1.3 is still a draft and under development. OpenVPN only supports it in the latest version combined with the OpenSSL master branch release. EduVPN still uses a version of OpenVPN that does not support TLS 1.3. Therefore we will be using TLS 1.2 for the test with the EduVPN configuration and have a seperate test for capturing network traffic from an OpenVPN connection using TLS 1.3

3.2 Virtual private network

VPN is built on top of existing physical networks. It enables a secure point-to-point connection between two or more points over the physical network, which is otherwise unsecured. Network traffic between the client and VPN server sent is encrypted. This is done by creating a tunnel between the connected hosts. With the tunnel between two hosts, the data and header information exchanged is encrypted and encapsulated by adding additional header information to the new packet. These new packets are then sent between the client and VPN servers.

To create a secure VPN connection, a connection consists of the following attributes:

• Confidentiality: prevents unauthorised users from accessing the payload of the transported network traffic. Such that even when a third party captures and analyses the network traffic, this third party is not able to read the actual data being sent. This is done by encrypting the data being sent.

• Authentication: prevents unauthorised users from accessing the VPN network while allowing authorised users to create a connection on the secure VPN network.

• Integrity: ensures detection of any instances of tampering with transmitted data between the authenticated sender and receiver.

There are various VPN implementations and each provides its own mechanism to transmit data be-tween the client and VPN servers. Depending on the implementation chosen, there are several charac-ters to detect VPN network traffic. Four commonly used VPN implementations are OpenVPN [Kei17], IPSec [Ken05], PPTP [HPV+₉₉_{] and L2TP [}_TVR+₉₉_{]. Each one resides on different network layers.} Nevertheless, the layering of a VPN is not very straightforward, as they usually use multiple protocols that are present in different layers. The additional information added on the transport layer can be used to determine the network protocol used.

OpenVPN

OpenVPN provides essential security services such as confidentiality, authentication and integrity for network communication. These security essentials are comparable to other VPN implementations. To understand how an OpenVPN message is created the OpenVPN related characters noticeable in network traffic can be explained. OpenVPN is a Secure Sockets Layer (SSL) VPN that is implemented on OSI layers 2 and 3. To create the SSL connection, OpenVPN utilises the OpenSSL encryption library, which uses the secure network extension standard SSL/TLS. OpenVPN improves the security of the standard TLS connection by using a pre-shared static key (or pre-shared passphrase) to generate a hash-based message authentication code (HMAC) key. This key is used to authenticate the packets that TLS uses for the handshake sequence. [Ope]

OpenVPN multiplexes the TLS session used for authentication and key exchange (control channel) with the actual encrypted tunnel data stream (data channel), shown in figure3.1. The control channel uses the TLS connection to ensure an acknowledgement when network traffic is received and the data

(10)

Figure 3.1: OpenVPN multiplexer

P CONTROL HARD RESET CLIENT V1 1 (deprecated) initial key from client, forget previous state P CONTROL HARD RESET SERVER V1 2 (deprecated) initial key from server, forget previous state P CONTROL SOFT RESET V1 3 new key, graceful transition from old to new key P CONTROL V1 4 control channel packet (usually TLS ciphertext)

P ACK V1 5 acknowledgement for packets received (only for control packets) P DATA V1 6 data channel packet

P CONTROL HARD RESET CLIENT V2 7 initial key from client, forget previous state P CONTROL HARD RESET SERVER V2 8 initial key from server, forget previous state

P DATA V2 9 data channel packet with 24 bit peer-id, after this byte

Table 3.1: OpenVPN opcodes[ag]

channel often uses the connectionless user datagram protocol (UDP). It is also possible to use the TCP protocol for the data channel instead, to ensures an acknowledgement when network traffic is received.

With the use of OpenVPN’s well-defined protocols and standards, it is possible to determine the network traffic from the creation of a connection and the network traffic from a running connection. For creating a connection OpenVPN provides two authentication modes. The main mode uses TLS with either certificates or user credentials; another mode uses pre-shared static keys, which, by default, provide authentication and encryption. Using these protocols, authentication and key exchange for a session can be established. Certificates provide authentication of the counterparty and generate a random HMAC key, as described earlier. There are two key methods for generating the HMAC key, and the header information varies depending on the method used. When the first key method is used, the keys are directly generated using local functions, and no extra information need be added to the packet header information (see appendix tableB.1). Whereas if the second key method is used, the keys are generated from the random source material created by both parties, and extra packet header information is added (see appendix tableB.2).

OpenVPN provides nine plaintext opcodes in an OpenVPN network message to classify a message. Table3.1shows all possible opcodes. The first OpenVPN control channel packet is the

P CONTROL HARD RESET CLIENT V2, to enable the OpenVPN connection. After this message the server response with a P CONTROL HARD RESET SERVER V2 message. When these messages have been exchanged the tunnel session information, keys and certificates can be shared. After this initial setup, there will be the control and data channels between the client and VPN server. The structure of the control channel differs from the data channel.

The control channel initiates the secure data tunnel establishment procedure, performing a hand-shake, including session starting, key exchange and cipher suite agreement. After agreement is es-tablished the secure data channel is formed. The control channel is also responsible for the key renegotiation procedure. The control channel consists of the packets P CONTROL, P ACK and the reset messages to initiate an OpenVPN connection. The structure of a P CONTROL packet is shown in table3.2and the structure of a P ACK is shown in appendix tableB.3.

The data channel can be used after the initialisation and configuration of the OpenVPN tunnel. The payload in the data channel is encrypted, but the header information that is visible in the P DATA

(11)

Type Size (in byte) Note

Session ID 64 ”random generated value

to identify TLS session”

HMAC 16 or 20 ”Only used if –tls-auth

is specified”

Packet-ID 4 or 8 ”includes sequence number

and optional time t timestamp”

Net Time 4 Local network time

P ACK Packet-ID array length 1 Lenght of array P ACK Packet-ID array Used if length >0 P ACK Remote Session ID Used if length >0

Message Packet-ID 4

TLS payload ciphertext n only for P CONTROL

Table 3.2: Header information with P CONTROL

package as shown in appendix tableB.4

The header packages of the OpenVPN packages are a clear indicator that the network traffic is OpenVPN network traffic. Therefore, we look into the an option to obfuscate these headers in Open-VPN. OpenVPN provides the option tls-crypt which encrypts and authenticates all header packets with a key from the provided keyfile. The tls-crypt option has two drawbacks. The first drawback is that the key used is a pre-shared group key, which is shared amongst all clients and servers in an OpenVPN deployment and the second drawback is that the lifetime of a key is limited to roughly 8000 years divided by the number of clients. These drawbacks are patched in the tls-crypte-v2 [Kar17] option by supply each client with a unique tls-crypt key. To be able to create a client specific key the crypto used has to be predefined. The creation of the key is slightly more work compared to OpenVPNs key exchange method.

(12)

Chapter 4

Experiment setup

In this Chapter we propose the setups and experiments that will be used to test the obfuscation of VPN network traffic. There are two experiments conducted using seven setups. The two experiments are: examining how an OpenVPN server can be detected and examining the network traffic of the seven setups. These setups consists of two TLS setups and five OpenVPN setups to monitor the network traffic. The OpenVPN setups are also used for testing the server detectability. There are are thee OpenVPN setups using TLS 1.2 and two setups with OpenVPN using TLS 1.3. The experiments and the setups are described in this Chapter.

4.1 Setups

The seven setups, as represented in table4.1, are proposed to be used for the experiments. The TLS 1.2 and the TLS 1.3 setup are used for monitoring TLS network traffic. The various OpenVPN setups are used for the OpenVPN server detection as well as network traffic monitoring. Three of the OpenVPN setups use the configuration file as provided by EduVPN. The OpenVPN standard is used as control setup and the OpenVPN secure and obfuscation setups are the modified servers. The modifications made to the servers are done to make the servers undetectable and improve the obfuscation of network traffic. The other two OpenVPN setups use the latest OpenVPN version 2.4.6. These two OpenVPN setups make use of the latest OpenSSL 1.1.1-pre9-dev library. The configuration of the server is done using the standard file as provided by the OpenVPN community, with the exception to only accept TLS 1.3. The details of the configuration of the various OpenVPN setups are discussed in Section4.3.

Test configuration In this thesis referred to as

TLS connection using TLS 1.2 TLS 1.2

TLS connection using TLS 1.3 TLS 1.3

OpenVPN server as provided by eduVPN OpenVPN standard OpenVPN server as provided by eduVPN

modified options: port (443) and tls-crypt enabled OpenVPN secure OpenVPN server as provided by eduVPN

modified options: port (443), tls-crypt enabled and port sharing OpenVPN obfuscation OpenVPN 2.4.6 server with OpenSSL 1.1.1-pre9-dev OpenVPN TLS 1.3 standard OpenVPN 2.4.6 server with OpenSSL 1.1.1-pre9-dev

modified options: port (443), tls-crypt OpenVPN TLS 1.3 secure Table 4.1: Setup naming schema

(13)

4.2 Experiments

To examine the detectability of OpenVPN network traffic we conduct the following two experiments. The first experiment examines how an OpenVPN server can be detected. The second experiment examines the network traffic of the seven setups. The first experiment examines how an OpenVPN server can be detected. To investigate the first experiment, the OpenVPN standard was used as a base test. The results of this experiment are compared with the results of the modified OpenVPN setups. This experiment shows how the OpenVPN standard setup holds against detection and how the modifications change the result. If an OpenVPN servers is unable to be detected, the server can no longer be blocked for hosting an OpenVPN server.

The second experiment examines the network traffic of the seven setups. The OpenVPN standard setup is the base test to determine the characters of VPN network traffic. With the various other OpenVPN setups, the network traffic is altered before being sent. The various OpenVPN setups show how OpenVPN connections can be detected and the differences in network traffic. The TLS 1.2 setup is used to specify how TLS network traffic is defined and what differences there are with VPN network traffic. The TLS 1.3 setup is used to define the changes affecting the network traffic of TLS 1.2. With the differences between the TLS 1.2 and the OpenVPN setups clarified, the changes that must be made on OpenVPN network traffic to mimic TLS network traffic can be proposed. With the proposed changes OpenVPN network can be obfuscated and stay private from anybody monitoring the network traffic. The OpenVPN secure and obfuscation network traffic shows the differences in network traffic already applied. Comparing the secure and OpenVPN obfuscation network traffic with the TLS network traffic shows us what should still be changed to mimic TLS network traffic. The OpenVPN standard TLS 1.3 and OpenVPN secure TLS 1.3 show the impact of using TLS 1.3 compared to the OpenVPN standard and secure setup.

With the first experiment it is possible to answer the sub-question, how can an OpenVPN server be detected? With the second experiment, when examining the network traffic of the various OpenVPN, the following sub-questions will be answered. It is possible to answer the sub-question, how can a VPN connection can be detected? In the second experiment, when comparing the the TLS network traffic with the OpenVPN network traffic. It is aslo possible to answer the sub-question, Which criteria should hold to improve obfuscation of an OpenVPN connection? With the results of these experiments and answers to the sub-questions the primary research question can be answered.

4.2.1 Experiment one: OpenVPN server detection

The various OpenVPN setups must be tested to determine whether the server running OpenVPN can be detected. To test this, the open port numbers and port numbers listened by the server are scanned. After this the port number that the server is listening on are investigated. Requests sent to the listening port consisted of HTTPS requests, random data and OpenVPN standard client configuration connections requests. The response of the server was monitored and captured. With the captured data there can be determined what the OpenVPN server response was and whether the response provided any clues to the possibility of a running OpenVPN server.

4.2.2 Experiment two: network traffic monitoring

To understand the differences in network traffic between TLS and the various OpenVPN setups, all the network traffic is monitored and analysed. With all this captured network traffic the difference in behaviour can be exposed. The differences between TLS 1.2 and TLS 1.3, TLS and OpenVPN network traffic and between the various OpenVPN setups are described. The client creates a connection to a web server using TLS. The network traffic from the creation of this connection is captured at the client. After this connection is created, the client and web server exchange data. This data will then also be captured at the client. All this data was used to analyse the behaviour of TLS network traffic. This data can be used to compare TLS 1.2 and TLS 1.3 network traffic and be used to compare TLS network traffic to VPN network traffic. Eventually, the data can be used to see how the obfuscated VPN network traffic is comparable to TLS network traffic.

(14)

points. The client and OpenVPN server establish a secure tunnel connection, as described before. The client uses the secure tunnel to send the request to the OpenVPN server. The OpenVPN server proceed to send the request to the web server. All network traffic from the OpenVPN server to the client and network traffic from the client to the OpenVPN server was captured. This captured data can be used to analyse the characters of OpenVPN standard network traffic. The data contains the initialisation of a connection and the continuation of the dataflow. The network traffic of the OpenVPN secure and obfuscation setup will differ from the OpenVPN standard setup. The network traffic between the OpenVPN standard and secure will be compared to the network traffic of the OpenVPN standard and secure TLS 1.3. The differences in network traffic will be described.

4.3 OpenVPN configurations

Each setup has a unique client and server OpenVPN configuration. The OpenVPN standard, secure and obfuscation use the OpenVPN 2.4.4 version with OpenSSL 1.0.2k-fips. The OpenVPN TLS 1.3 standard and secure use the OpenVPN 2.4.6 version with OpenSSL 1.1.1-pre9-dev. The OpenVPN 2.4.4 version use the OpenVPN standard configuration as the core profile. The configuration file of this setup is explained first, whereas the changes made for the other OpenVPN 2.4.4 version setups are discussed only where they differ from the core configuration. The OpenVPN 2.4.4 servers run on CentOS 7, which create a security-enhanced Linux based operating system. Every image runs on an instance with 1 VCPU with 384MB of RAM and 10GB of disk space. The OpenVPN 2.4.6 version use the OpenVPN community standard server configuration file, with the exception of using TLS 1.3 as minimum version. The OpenVPN 2.4.6 servers run on an Ubuntu 16.04 instance with 1 VCPU with 384MB of RAM and 10GB of disk space. To have access to any of the server, the firewall rules on ports 22, 80, 443 and 1194 are allowed to be accessed.

4.3.1 OpenVPN standard configuration

The OpenVPN standard server configuration file is provided by eduVPN. The settings of the file are show in listing 4.1. Each line represents a setting of the OpenVPN standard server. To get an understanding what some of the options entail they are explained after the listing.

(15)

auth SHA256 ca tls/default/internet/ca.crt cert tls/default/internet/server.crt cipher AES-256-CBC client-connect /usr/libexec/vpn-server-node/client-connect client-disconnect /usr/libexec/vpn-server-node/client-disconnect dev tun-1-1-1 dev-type tun dh none group openvpn keepalive 10 60 key tls/default/internet/server.key local :: log /dev/null management 127.0.0.1 11941 max-clients 125 ncp-ciphers AES-256-GCM persist-key persist-tun port 1194 proto tcp6-server push "block-outside-dns" push "dhcp-option DNS 9.9.9.9" push "dhcp-option DNS6 2620:fe::fe"

push "redirect-gateway def1 bypass-dhcp ipv6" push "route-ipv6 2000::/4" push "route-ipv6 3000::/4" remote-cert-tls client script-security 2 server 10.158.68.128 255.255.255.128 server-ipv6 fdf9:5071:e6ab:55b1::/64 setenv INSTANCE_ID default

setenv PROFILE_ID internet tcp-nodelay tls-auth tls/default/internet/ta.key 0 tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 tls-version-min 1.2 topology subnet user openvpn verb 3

Listing 4.1: OpenVPN standard configuration

Auth: authentication of packets goes with the HMAC, to ensure the integrity and the authentication of a packet. The default for this algorithm is SHA1, but in this configuration the algorithm used is SHA256. Ca: the certificate authority is known as the root certificate. Cert: the certificate file must be signed by the certificate authority public key and a key file that uses the private key that was generated when building the peers certificate. Each peer in an OpenVPN link running in TLS mode should have its own certificate and private key file. Cipher: a cipher algorithm encrypts the packets. The default is BF-CBC, an abbreviation for Blowfish in Cipher Block Chaining mode; in this configuration, the AES 256 algorithm was chosen. Ncp-cipher: a list of ciphers can be given that can be negotiated between the client and the server to choose from. The defaults are AES-256-GCM and AES-128-GCM, but in this configuration, only AES-256-GCM was allowed. This cipher can be used to override the cipher originally defined. Keepalive: is a helper directive designed to simplify the expression of ping and ping-restart in server mode configurations. key Local peer’s private key. persist-key: is used to disallow re-read key files when a SIGUSR1 or ping-restart is received. Port: allows a user to specify the TCP/UDP port number to use for local and remote access. Proto: specifies the protocol for communication with the remote host. Push: sends a file to the client for remote execution. A limited set of options can be pushed to the client, for feasibility and security. The options in this setup configuration were: block-outside-DNS to prevent DNS leaks, DHCP-option DNS x DNS server to use, redirect-gateway to redirect all IP network traffic through OpenVPN and route-IPv6 to redirect all internet-bound traffic using the currently allocated public IP. Script-security: directive offers policy-level control over OpenVPN usage of external programmes and scripts. Tls-auth: is an additional layer of HMAC authentication protecting against denial of service attacks,

(16)

dropping incorrect HMAC signatures immediately without response. tls-cipher: A list of allowable TLS ciphers. It can prevent a version rollback attack where a man-in-the-middle attacker tries to force two peers to negotiate to the lowest level of security they both support. Tls-version-min: specifies the peers minimal TLS version to use.

4.3.2 OpenVPN secure configuration

Most of the configuration described in section Section4.3.1 was used for the OpenVPN secure con-figuration, all changes to the configuration are shown in listing4.2.

port 443

tls-crypt tls/default/internet/ta.key

Listing 4.2: OpenVPN secure configuration

The port number for OpenVPN listen on was changed from default 1194 to 443. The option tls-auth has been replaced with the option tls-crypt. This option encrypts and authenticates all header packets with the key from the keyfile. OpenVPN traffic is then more difficult to identify. In this version of tls-crypt, all peers use the same pre-shared group key to authenticate and encrypt the header packets. If collision occurred, the security of tls-crypt would degrade to the level of security of the option of tls-auth. The extra privacy would be lost.

semanage port -m -t openvpn_port_t -p tcp 443

Listing 4.3: Enable openvpn listening on port 443

The semanage tool was used to configure security-enhanced Linux images policies. We configured the port options to allow OpenVPN to listen to 443. This was done by modifying the OpenVPN port to listen to TCP port 443 using the command in listing4.3.

4.3.3 OpenVPN obfuscation configuration

Most of the configuration described in section Section4.3.1 was used for the OpenVPN obfuscation configuration, all changes to the configuration are shown in listing4.4.

port-share 127.0.0.1 8008 port 443

tls-crypt tls/default/internet/ta.key

Listing 4.4: OpenVPN obfuscation configuration

The port-share option shares the OpenVPN port with another application. When a non-OpenVPN protocol is detected, the connection will be proxied to the server at host:port. Currently it is only designed to work with HTTP/HTTPS. As in Section4.3.2the port is changed to 443 and tls-crypt is enabled.

To get the port sharing option of OpenVPN working, the Apache server configuration and the SSL configuration are changed. The Apache server configuration must be changed in order to listen to another port. The traffic received on port 80 will be redirected to the location where the new web server is listening on the new port. The Apache server will no longer listen to port 443. The changes that must be made on the Apache server file are shown in listing4.5.

(17)

Redirect permanent / https://145.100.180.117:8008/ </VirtualHost>

Listing 4.5: Apache server configuration

The SSL configuration file port number must also be changed in order to listen to the default 443 to the new definite port number, shown in listing4.6.

Listen 8008 https

Listing 4.6: SSL configuration

After these configurations have been applied the server has an OpenVPN and Apache server sharing the port 443. All traffic sent to the port will be classified as OpenVPN traffic or non-OpenVPN traffic. The OpenVPN traffic will be managed by the OpenVPN server and the non-OpenVPN traffic will be sent to the Apache server running on the new port.

4.3.4 OpenVPN TLS 1.3 configuration

The OpenVPN standard TLS 1.3 server uses the OpenVPN community provided configuration file as presented in Listing4.7. The only exception being the tls-version-min option. This option specifies the server to only accept connection using TLS 1.3. This option can only be used when the latests OpenVPN 2.4.6 version is used in combination with the latest OpenSSL 1.1.1 library. With the OpenVPN secure TLS 1.3 server uses the same configuration with two minor changes. The port option is set from 1194 to 443. And the tls-auth option is changed to the tls-crypt option.

port 1194 proto tcp dev tun ca ca.crt cert server.crt key server.key dh dh2048.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 208.67.222.222" push "dhcp-option DNS 208.67.220.220" keepalive 10 120 tls-auth ta.key 0 key-direction 0 keepalive 10 120 auth SHA256 comp-lzo user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3 tls-version-min 1.3

(18)

Chapter 5

Results and analysis

This Chapter shows the results of the experiments conducted and analyse these results. The results presented are the active detection of an OpenVPN server. Followed by the network traffic detection of TLS 1.2 and TLS 1.3, an OpenVPN standard connection, two setups of OpenVPN where network traffic is hidden using tls-crypt and two setups of OpenVPN where they use TLS 1.3.

5.1 Active detection OpenVPN server

The following experiments have been conducted on the various OpenVPN servers, to determine whether a server has OpenVPN running. Starting with scanning the ports the various OpenVPN server are listening on. After scanning the ports the first experiments sends a random data request, containing the correct server ip address and port number and some random generated data as the payload, to the various OpenVPN servers. The next experiment sents an incorrect OpenVPN client configurations request to the various OpenVPN servers. Both experiments determine whether and how each server is responding. Finally we monitor the OpenVPN three way handshake, on al various OpenVPN server and compare these with the three way handshake when creating a TLS connection. All OpenVPN servers use the TCP protocol to sent and receive data and listen to port 1194 or port 443, as described in section4.3.

5.1.1 Port scanning

Port scanning detects the ports a server is listening on. The default OpenVPN port is 1194. When a server is listening on port 1194 this is most likely an OpenVPN server. Therefore, the experiments with an OpenVPN server listening on port 443 are established. When a third party uses a browser to visit the OpenVPN secure server to see what is running on the server, the server is not able to sent a response. This would result in suspension of what could be running on the server on port 443, revealing that something unusual is happening on the server. With OpenVPN obfuscation, where the OpenVPN server shares port 443 with a web server. When a third party sends a request to the domain as a non-OpenVPN connection, the client is shown a website. Only an OpenVPN client, with certificate and private key that is verifiable by the client and server, can make use of the OpenVPN server.

5.1.2 Connection request

Each server is sent connection requests and the response of the server is captured. Every OpenVPN server is configured to used the tls-auth or tls-crypt option. This feature is a special layer of authenti-cation on top of the control channel. It enables authentiauthenti-cation on every packet on the control channel by a HMAC signature and a unique identifier. This means that an OpenVPN server with this feature enabled is able to detect packets with a correct signature and start up the connection. Packets with an incorrect signature should be dropped immediately, resulting in loss of the connection. When the server receives random data the data is checked for the HMAC signature. This HMAC signature is

(19)

unrecognised by the server, which drops the packet and will not respond. The same results occurred when a connection request is sent with an incorrect client configuration. This makes it unclear for the user sending the request why the packet was dropped. The server does not give any clues away and can remain undetected on running OpenVPN.

5.1.3 TCP three way handshake

We investigated the handshake messages between a client and a server. Detailed information about the three TCP messages sent between a client and server is included in the appendix. The first message is the client SYN message, shown in appendix listingC.1, initiate a connection. The second message is the server SYN-ACK messages, shown in appendix listingC.2, tell the client to initiate the connection and that the SYN packet of the client was received . The final client ACK message, shown in appendix listingC.3, tells the server the SYN message was received. These messages differ little between the TLS and the various OpenVPN setups. The only noticeable change is the port number of the destination server on the OpenVPN standard configuration. The port number on the OpenVPN standard server is 1194, whereas with the OpenVPN secure and obfuscation, the destination port number is 443.

5.2 Monitoring network traffic

In this section, we show the results of the monitored network traffic between a client and an OpenVPN server. The results come from the following experiments:

1. Handshake

2. Network traffic from client to server 3. Network traffic from server to client

We used the results of the network traffic from a web server, using a TLS 1.2 connection, as a baseline to compare with the network traffic of the various OpenVPN configurations. The results of the OpenVPN standard setup were used as control data for the way OpenVPN network traffic is currently transmitted. The TLS 1.3 connection is used to show the difference with TLS 1.2 and the OpenVPN standard and secure TLS 1.3 network traffic is used to compare with the OpenVPN standard and secure network traffic.

5.2.1 Handshake

We first investigated the handshake messages between a client and a server. To compare the TLS handshake with the various OpenVPN handshakes we investigated the first two messages that ex-change information about the handshake. The first message is from the client to the server. In the case of TLS, this will be a client hello packet, and with various OpenVPN servers, this will be a P CONTROL HARD RESET CLIENT V2 packet requesting a specified connection from the server. The server should then respond. With a TLS connection, the server will respond with a server hello packet; with the various OpenVPN connection, the server will respond with a

P CONTROL HARD RESET CLIENT V2 packet.

5.2.2 Client hello

The first message is from the client to the server. The TLS client sends a client hello message that lists cryptographic information such as the TLS version and, in the clients order of preference, the cipher suites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the client hello to include the data compression methods supported by the client. All this information is provided in listing 5.1. The information is sent unencrypted from the client to the server. The TLS 1.3 client hello message looks similar to the TLS 1.2 client hello message. The full TLS 1.3 client hello message is shown in appendixC.4. The main difference is that the list of supported algorithms has been pruned of all legacy algorithms and

(20)

the message contains some extra extensions. The extra extensions are key share, supported versions, psk key exchange modes and padding.

TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22)

Version: TLS 1.0 (0x0301) Length: 181

Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 177

Version: TLS 1.2 (0x0303)

Random: b28da649682ad1528912298bbf83b68000100f1f1aa0d9fb... Session ID Length: 0

Cipher Suites Length: 30 Cipher Suites (15 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 106

Extension: server_name (len=14)

Extension: extended_master_secret (len=0) Extension: renegotiation_info (len=1) Extension: supported_groups (len=10) Extension: ec_point_formats (len=2) Extension: SessionTicket TLS (len=0)

Extension: application_layer_protocol_negotiation (len=14) Extension: status_request (len=5)

Extension: signature_algorithms (len=24)

Listing 5.1: TLS 1.2 client hello

The OpenVPN standard server P CONTROL HARD RESET CLIENT V2 message contains dif-ferent information than a TLS client hello message. The difference is that the

P CONTROL HARD RESET CLIENT V2 message contains an opcode, which can be used to clas-sify the packets. Next to this, the packets contain a HMAC key and a packet-ID array. All these characters can be used to identify the message as OpenVPN. The session ID is already set, unlike a TLS connection where the session ID is not set by the client. This information is included in list-ing5.2. The information is sent unencrypted from the client to the server. The OpenVPN standard TLS 1.3 P CONTROL HARD RESET CLIENT V2 message contains exactly the same characters as the OpenVPN standard message. The complete layout of the packets is identical.

Packet Length: 54

Type: 0x38 [opcode/key_id] Session ID: 1749442841458726212

HMAC: 2bf1d91bd6e954be8a13644d0ee1d13cbbf72db5 Packet-ID: 1184785289

Net Time: Jul 18, 2084 05:38:21.000000000 West-Europa (zomertijd) Message Packet-ID Array Length: 59

Packet-ID Array

Message Packet-ID Array Element: 2351849216 Message Packet-ID Array Element: 346 Message Packet-ID Array Element: 2237684736 Message Packet-ID Array Element: 0

Listing 5.2: OpenVPN client reset

The OpenVPN secure and obfuscation server initially sent an unknown message to the server. When this message is decoded as OpenVPN, the message is P CONTROL HARD RESET CLIENT V2. This message will contain less information than the OpenVPN standard message. The opcode of the message is still visible and can be used to classify the packet as OpenVPN. The HMAC key and the packet-ID array are encrypted and sent in the data payload of the packet, as shown in listing 5.3. Some information is still sent unencrypted. The OpenVPN secure TLS 1.3

P CONTROL HARD RESET CLIENT V2 message contains exactly the same characters as the Open-VPN secure message.

(21)

Packet Length: 54

Type: 0x38 [opcode/key_id] Session ID: 15291516204509398523 Message Packet-ID Array Length: 0 Message Packet-ID: 346

Data (40 bytes)

Data: 844b3a914373e4db4e5c2d3197860aae31a9f5cb7f1395fd...

Listing 5.3: OpenVPN secure and obfuscation client reset

A raw data packet from the client reset message sent by any OpenVPN server is visible, as shown in figure 5.1. Consistent with what we saw above, every P CONTROL HARD RESET CLIENT V2 message contains the packet length and the opcode visible in a packet. Figure 5.1 also shows that the these characters are always in the same position with the same value in the raw data packet. The position from the packet length and the opcode is always on the same position in an OpenVPN network packet. The OpenVPN standard and secure TLS 1.3 message is identical to the OpenVPN standard and secure message. This is shown in the raw data packet as well, appendixC.1. The packet length and the opcode is visible.

5.2.3 Server hello

The second message is from the server to the client. The TLS server responds with a server hello mes-sage that contains the cipher suite chosen by the server from the list provided by the client, the session ID and another random byte string. The server also sends its digital certificate. If the server requires a digital certificate for client authentication, the server sends a client certificate request that includes a list of the types of certificates supported and the distinguished names of acceptable certification authorities, as shown in appendix listingC.5. The information is sent unencrypted from the server to the client. The TLS 1.3 server hello message, appendixC.6, is different than the TLS 1.2 message. The TLS 1.3 message contains different extensions than the the TLS 1.2 message and does not have the extensions the TLS 1.2 message has. The TLS 1.3 message also contains a partitions of change cipher spec protocol. This partitions is a new partition compared to the TLS 1.2 server hello message. The OpenVPN standard server responds with the P CONTROL HARD RESET SERVER V2 message. The message also contains an opcode to classify the packet. Next to this, the packet also contains an HMAC key and a packet-ID array, which can be used to identify the message as OpenVPN. The session ID of the server is set as well. The session ID is visible in the TLS server hello message as well as in the OpenVPN P CONTROL HARD RESET SERVER V2 message. This information is pro-vided in appendix listingC.7. The information is sent unencrypted from the server to the client. The OpenVPN standard TLS 1.3 P CONTROL HARD RESET SERVER V2 message contains exactly the same characters as the OpenVPN secure message.

The OpenVPN secure and obfuscation server initially sent an unknown message to the server. When this message is decoded as OpenVPN, the message is P CONTROL HARD RESET SERVER V2. This message contains less information than the OpenVPN standard message. The opcode of the message is still visible and can be used to classify the packet as OpenVPN. The HMAC key and the packet-ID array are encrypted and sent in the data payload of the packet, as shown in appendix listingC.8. Some information is still sent unencrypted. The OpenVPN secure TLS 1.3

P CONTROL HARD RESET SERVER V2 message contains exactly the same characters as the OpenVPN secure message.

A raw data packet from the server reset message sent from any OpenVPN server visible in appendix figureC.3. As above, for every message, the server reset message contains the packet length and the opcode. Here as well, these characters are always on the same position with the same value in the raw data packet, clearly indicating that the message sent is OpenVPN network traffic. The OpenVPN standard and secure TLS 1.3 message is identical to the OpenVPN standard and secure message. This is shown in the raw data packet as well, appendixC.2. The packet length and the opcode is visible.

(22)

(a) Standard (b) Secure

(c) Obfuscation

Figure 5.1: Packet length and opcode visible

5.3 Network traffic from server to client

After the configuration details are exchanged between client and server, the actual data can be trans-ported. The characters of TLS 1.2 and TLS 1.3 network traffic is identical. So are the characters of OpenVPN standard and secure TLS 1.3 compared to the OpenVPN standard and secure network packets. These packets have fewer extra definable characters in the packets before the payload with the encrypted data, and the characters of a TLS network packet is completely different from the characters of an OpenVPN network packet. The difference are that the TLS server data packet con-tains the content type, the version and the packet length as recognisable characters followed by the encrypted data, as shown in appendix listingC.9, whereas the OpenVPN standard setups server data packets contain the packet length and the type as recognisable characters followed by the encrypted data, as shown in appendix listingC.10. With the OpenVPN secure and obfuscation setup, the data packet is initially unknown but can be decoded as OpenVPN and will result in the same structure as the OpenVPN standard data packet.

When we look at a raw data packet sent by the OpenVPN server to the client, containing data, it is visible as represented in figureC.4. Packets from the OpenVPN server to the client can consist of different length. To be able to compare the packets, packets with the same length have been selected. As above, the packet length, followed by the opcode, is in the same position for all OpenVPN servers, clearly indicating that the message sent is OpenVPN network traffic. The OpenVPN standard and secure TLS 1.3 data packets are identical to the OpenVPN standard and secure data packets. This is shown in the raw data packet as well, appendixC.5. The packet length and the opcode is visible.

5.4 Network traffic from client to server

As in Section 5.3 with the data sent from the server to the client, there is no difference between the network packets of TLS 1.2 compared to the TLS 1.3 and the OpenVPN standard and secure TLS 1.3 compared to OpenVPN standard and secure network traffic. The data sent by the client to the server between TLS network packets and OpenVPN network packets is different. The difference are that the TLS client data packet contains the content type, the version and the packet length as recognisable characters, followed by the encrypted data, as seen in appendix listingC.11, whereas the OpenVPN standard setups client data packets contain the packet length, the type and the peer ID as recognisable characters followed by the encrypted data, as seen in appendix listingC.12. With the OpenVPN secure and obfuscation setup, the data packet is initially unknown but can be decoded as OpenVPN and will result in the same structure as the OpenVPN standard data packet.

(23)

is visible as represented in figureC.6. Packets from the client to the OpenVPN server can consist of different length. To be able to compare the packets, packets with the same length have been selected. As above, the packet length, followed by the opcode, is in the same position for all OpenVPN servers, clearly indicating that the message sent is OpenVPN network traffic. The OpenVPN standard and secure TLS 1.3 data packets are identical to the OpenVPN standard and secure data packets. This is shown in the raw data packet as well, appendixC.7. The packet length and the opcode is visible.

5.5 Analysis

This Section provides the analysis of the results of active probing to an OpenVPN server, followed by the analysis of the results of the network traffic of all the setups.

5.5.1 Active detection OpenVPN server

Sending an incorrect request to any OpenVPN server will result in loss of the connection. The reason a connection is refused is unclear to the requesting client. Whether an OpenVPN server is running on the server is also unclear, keeping an OpenVPN server hidden for any unauthorised users. There is no difference when using TLS 1.2 or TLS 1.3 on the OpenVPN server.

With port scanning, the OpenVPN obfuscation server was the most private server. In this case, the server shared the port for OpenVPN traffic with a web server. In this case, a website can be shown to users making a non-VPN request to the server. The website provided must be allowed by the firewall, preventing the server from being blocked by the firewall. The OpenVPN server would stay hidden. When the VPN server is used network traffic from the server to a client will be higher than with a regular website. This may arouse authorities suspicions when they monitor the quantities of data transported between the server and clients. The website hosted on the server should therefore carefully be chosen to explain the quantities of data exchanged. This could be a video streaming website explaining quantities of data exchange.

5.5.2 Network traffic

The analysis of the network traffic monitoring results will be discussed below. These results consists of three parts. The first part analyses the TCP three-way handshake. The second part analyses how OpenVPN secure and obfuscation network traffic is compared with the OpenVPN standard network traffic. Finally in the third part of the analysis the OpenVPN setups are compared to the TLS network traffic.

5.5.3 TCP three way handshake

The initial TCP three-way handshake was identical for all setups. These messages do not reveal any information about the connection to be created, other than that a client will try to establish a connection to a server. This is because without any knowledge between the client and the server they have to be able to create a TCP connection. This can only be done when a client is able to send a message to a server, which the server is able to understand. This means that the client and server have to follow the TCP protocol for creating a connection. Only after a correct handshake with the protocol defined configuration details is sent between the client and server can a successful connection be established.

5.5.4 OpenVPN setups compared

The OpenVPN header information is different for the various OpenVPN servers. The header informa-tion for the OpenVPN secure and obfuscainforma-tion show fewer VPN related characters than the OpenVPN standard server. The OpenVPN standard connection contains many recognisable characters in its headers, as shown in Section5.2.2. Many of these characters can be detected during the creation of an OpenVPN connection, because of the protocol definition for creating an OpenVPN connection. Because of the protocol TLS 1.3 does not has any effect on the structure of the OpenVPN network

(24)

packets. The creation of network packets is done using the same structure, creating identical structured OpenVPN network packets. In the OpenVPN secure, secure TLS 1.3 and obfuscation setup some of the characters are encrypted before being sent. However, the opcode is never encrypted in any of the connections. This opcode clearly indicate the creation of an OpenVPN connection and can be used to detect the connection as an OpenVPN connection. With the data transportation layer, nothing is changed on the headers of the packets. This means that the opcode of the packets is still visible, making the data network traffic packets as noticeable as they were when non of the characters are encrypted in the standard OpenVPN connection. The packets stay detectable unless the OpenVPN protocol is modified. The OpenVPN specific characters should be removed. Another option would be to repack the packets and adding TLS characters to the packet to mimic the TLS protocol.

5.5.5 TLS compared to OpenVPN

The TLS 1.2 and TLS 1.3 client and server hello packets are unencrypted packets with different ele-ments than in the OpenVPN hello messages. The TLS packets are larger than those of the OpenVPN messages. This makes it possible to add information to the OpenVPN packet to resemble the length of the TLS packets. The information added to the packet can be used to allow the OpenVPN packet to more closely resemble a TLS message by adding TLS-relatable characters.

With OpenVPN secure, secure TLS 1.3 and obfuscation some of the message information about the protocol is encrypted. Characters that are encrypted are HMAC, packetid or the packetid array. These characters become unknown encrypted element in the packet header. This differs from the TLS message because nothing is encrypted in the TLS header information. This means that even if all the header information of OpenVPN is encrypted, the OpenVPN protocol is harder to detect. However, the protocol would still not resemble the TLS network protocol.

(25)

Chapter 6

Conclusion

This Chapter draws the conclusions of the results of the experiments conducted, answering the pri-mary research question: How can one hide a VPN connection to prevent a third party from detecting, destroying or blocking the connection between a client and a VPN server? Before we answer the pri-mary question, we answer the sub-questions.

How can an OpenVPN server be detected?

In this thesis, we examined various OpenVPN configurations and tested the detectability of Open-VPN servers. All configurations stayed hidden from detection when requests are sent to the servers. Scanning the ports of the servers reveals the following information about the server. The OpenVPN standard and standard TLS 1.3 server revealed to be listening to port 1149, the default port for OpenVPN. The OpenVPN secure and secure TLS 1.3 server revealing to be running listening to port 443, which itself is irrelevant but when a website request is done and no response is given this would create suspicion about the server. The OpenVPN obfuscation server is the most private server, the server shares the port 443 with a web server and an OpenVPN server.

How can a VPN connection be detected?

The differences in network traffic are examined and some obfuscation of the OpenVPN network traffic was applied, using the OpenVPN setups. In Chapter5, we showed that network traffic can be captured and analysed. The control channel of OpenVPN has many characters to detect OpenVPN network traffic, as shown in Listing 5.1 These OpenVPN network traffic characters can be detected by monitoring the network traffic and using filters to classify the traffic. When the OpenVPN server port is changed and the header information is encrypted, monitoring OpenVPN traffic using a filter is as efficient as using the OpenVPN standard or standard TLS 1.3 configuration. This is shown in Figure 5.1 where all the OpenVPN servers opcodes are in the same place in a network packet and clearly detectable.

Which criteria should hold to improve obfuscating of an OpenVPN connection?

The criteria to improve obfuscating of an OpenVPN connection are twofold. First, the OpenVPN server should be undetectable and secondly the network traffic between a client and a VPN server should be obfuscated. To create a undetectable OpenVPN server, external sources attempting to dis-cover whether there is an OpenVPN server running should not be able to detect an OpenVPN server. As shown in the results, when an OpenVPN server runs with tls-auth or tls-crypt enabled, the server will drop an incorrect OpenVPN request. This in combined with sharing a port on the server with a web server, as presented with the OpenVPN obfuscation server creates an OpenVPN server that can stay undetectable.

To create obfuscation of the network traffic between a client and a VPN server, external sources monitoring the network traffic should not be able to detect OpenVPN characters in network traffic.

(26)

Since not all characters of OpenVPN are encrypted, it is still possible to detect OpenVPN network traffic. The OpenVPN network traffic has a noticeable opcode, which is detectable when monitoring network traffic. The header information that is encrypted creates a noticeable difference compared to a TLS connection, where none of the header information is encrypted.

How can you hide a VPN connection, to prevent a third party from detecting, destroying or block-ing the connection between a client and a VPN server?

The header information of an OpenVPN message should be obfuscated by encrypting the complete header. The network traffic of the various OpenVPN servers always have an opcode visible. There-fore, it will always be possible to detect the network traffic as OpenVPN network traffic. When the header information is completely encrypted, it is not recognisable as OpenVPN traffic, but neither is it similar to TLS network traffic. Therefore, characters specific to TLS should be added in order to mimic TLS network traffic. This was not done in this thesis and the header information was only partially encrypted. Obfuscating a VPN connection to prevent a third party from detecting, destroy-ing or blockdestroy-ing the connection between a client and a VPN server is not possible usdestroy-ing the methods presented in this thesis.

(27)

Chapter 7

Future work

In this thesis, the OpenVPN protocol and the different configuration options involved are used to de-termine the possibility of obfuscating an OpenVPN connection. The header information of the control channel are partially encrypted, but the data channel is not modified. Therefore, further research is warranted to clarify how the data channel of the OpenVPN network traffic can be obfuscated and how the control channel can be obfuscated more. This could be accomplished by reworking the protocol of OpenVPN and developing a method to transport the data between a client and a server.

For the OpenVPN TLS 1.3 setups we used the master branch release build: OpenSSL 1.1.1-pre9-dev. Since they are still working on the TLS 1.3 protocol and the OpenSSL library this can have an impact on the way the network traffic is handled by OpenVPN. When stable version of OpenSSL is deployed the network traffic should be checked to examine if there have been any changes to the OpenVPN network traffic.

Another research possibility is to explore the impact of repacking the data packets before sending. When the data packets should mimic the TLS protocol it is possible to ad TLS related characters to the packets. This implies that the mechanism OpenVPN uses to recognise packets as OpenVPN packets must be adopted with this solution. This research would determine whether a port-sharing option, as presented in this thesis, would still work.

(28)

Bibliography

[AAH13] Simurgh Aryan, Homa Aryan, and J Alex Halderman. Internet censorship in iran: A first look. In FOCI, 2013.

[ag] Doxygen automatically generated. OpenVPN source code documentation. https:// build.openvpn.net/doxygen/html/network_protocol.html. [Online; accessed 15-05-2018].

[Ala14] Mohammed M Alani. Guide to osi and tcp/ip models. 2014.

[DCS15] Kevin P Dyer, Scott E Coull, and Thomas Shrimpton. Marionette: A programmable network traffic obfuscation system. In USENIX Security Symposium, pages 367–382, 2015.

[DR08] Tim Dierks and Eric Rescorla. The transport layer security (tls) protocol version 1.2. Technical report, 2008.

[DZ83] John D Day and Hubert Zimmermann. The osi reference model. Proceedings of the IEEE, 71(12):1334–1340, 1983.

[EFW+_{15] Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, Nicholas Weaver, and Vern}

Paxson. Examining how the great firewall discovers hidden circumvention servers. In Proceedings of the 2015 Internet Measurement Conference, pages 445–458. ACM, 2015. [GLMG16] Gerard D Gil, Arash H Lashkari, M Mamun, and Ali A Ghorbani. Characterization of

encrypted and vpn traffic using time-related features. In Proceedings of the 2nd Inter-national Conference on Information Systems Security and Privacy (ICISSP 2016), pages 407–414, 2016.

[HPV+99] Kory Hamzeh, Grueep Pall, William Verthein, Jeff Taarud, W Little, and Glen Zorn. Point-to-point tunneling protocol (pptp). Technical report, 1999.

[Kar17] Steffan Karger. [openvpn-devel] proposal: tls-crypt-v2 (client-specific tls-crypt keys), Jul 2017. URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge. net/msg15126.html.

[Kei17] Jan Just Keijser. OpenVPN Cookbook. Packt Publishing Ltd, 2017. [Ken05] Stephen Kent. Ip authentication header. 2005.

[KPW13] Hugo Krawczyk, Kenneth G Paterson, and Hoeteck Wee. On the security of the tls protocol: A systematic analysis. In Advances in Cryptology–CRYPTO 2013, pages 429– 448. Springer, 2013.

[NS14] Daiyuu Nobori and Yasushi Shinjo. Vpn gate: A volunteer-organized public vpn relay system with blocking resistance for bypassing government censorship firewalls. In NSDI, pages 229–241, 2014.

[Ope] OpenVPN. Security overview. https://openvpn.net/index.php/open-source/ documentation/security-overview.html", note = [.

(29)

[PBUK07] Daniele Piccitto, Stefan Burschka, and Guillaume Urvoy-Keller. Traffic mining in ip tunnels. Master’s thesis, Eurecom Institute, 2007.

[PJL+12] Yi Pang, Shuyuan Jin, Shicong Li, Jilei Li, and Hao Ren. Openvpn traffic identification using traffic fingerprints and statistical characteristics. In International Conference on Trustworthy Computing and Services, pages 443–449. Springer, 2012.

[Pos81] Jon Postel. Transmission control protocol. 1981.

[Res] Eric Rescorla. The transport layer security (tls) protocol version 1.3 draft-ietf-tls-tls13-28. https://tools.ietf.org/html/draft-ietf-tls-tls13-28", note = [.

[Res99] Eric Rescorla. Diffie-hellman key agreement method. 1999.

[SB14] Yan Shi and Subir Biswas. Website fingerprinting using traffic analysis of dynamic web-pages. In Global Communications Conference (GLOBECOM), 2014 IEEE, pages 557–563. IEEE, 2014.

[TVR+_{99] W Townsley, A Valencia, Allan Rubens, G Pall, Glen Zorn, and Bill Palter. Layer two}

tunneling protocol ”l2tp”. Technical report, 1999.

[WDA+15] Liang Wang, Kevin P Dyer, Aditya Akella, Thomas Ristenpart, and Thomas Shrimpton. Seeing through network-protocol obfuscation. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security, pages 57–69. ACM, 2015. [ZAB07] Sebastian Zander, Grenville Armitage, and Philip Branch. A survey of covert channels

and countermeasures in computer network protocols. IEEE Communications Surveys & Tutorials, 9(3):44–57, 2007.

(30)

List of Figures

3.1 OpenVPN multiplexer . . . 9

5.1 Packet length and opcode visible . . . 21

C.1 Packet length and opcode visible client hello OpenVPN TLS 1.3 message . . . 38

C.2 Packet length and opcode visible server hello OpenVPN TLS 1.3 message . . . 38

C.3 Packet length and opcode visible server hello message . . . 38

C.4 Packet length and opcode visible server to client . . . 39

C.5 Packet length and opcode visible server to client OpenVPN TLS 1.3 . . . 39

C.6 Packet length and opcode visible client to server . . . 39

(31)

List of Tables

3.1 OpenVPN opcodes[ag] . . . 9

3.2 Header information with P CONTROL . . . 10

4.1 Setup naming schema . . . 11

B.1 Header information with key methode 1 . . . 32

B.2 Header information with key methode 2 . . . 33

B.3 Header information with P ACK . . . 33

(32)

Appendix A

Abbreviations

ACK Acknowledgment

AES Advanced Encryption Standard DNS Domain Name System

HMAC Hash-based Message Authentication Code HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure IP InternetProtocol

IPSec Internet Protocol Security IPv6 Internet Protocol version 6 ISP Internet Service Provider IV Initialisation Vector

L2TP Layer 2 Tunnelling Protocol MAC Message Authentication Code NAT Network Address Translation OSI Open Systems Interconnection PDU Protocol Data Units

PPP Point-to-Point Protocol

PPTP Point-to-Point Tunnelling Protocol PSK Pre-shared Static Key

SSL Secure Sockets Layer

SSTP Secure Socket Tunnelling Protocol TCP Transmission Control Protocol TCP/IP Internet Protocol Suite TLS Transport Layer Securit TUN Network Tunnel

UDP User Datagram Protocol VPN Virtual Private Network

Obfuscating VPN Traffic