What is a SSL VPN and How Does it Work?

Acceleration of Data through SSL Virtual Private Networks

Rob Jansen

University of Minnesota, Morris 600 East Fourth Street

Morris, MN 56267 (123) 456-7890

[email protected]

ABSTRACT

A Virtual Private Network (VPN) simulates a private network over a shared public network like the Internet. SSL tunnels are used to secure data transferred in a VPN. Data must be encrypted before being sent through SSL tunnels and decrypted after being received. The VPN server performs this encryption and decryption on all data traveling to internal application servers.

This causes a bottleneck at the VPN server when there are multiple tunnels in use. Throughput of the VPN is limited by the computational power of the VPN server. Surveyed and described is a new approach that increases the throughput of the VPN by 260%. The new approach distributes the computational load among internal application servers of the VPN, which results in an increase in system performance.

Categories and Subject Descriptors

A.1 [Introductory and Survey]

General Terms

Algorithms, Performance, Design, Security, Theory.

Keywords

SSL, TLS, VPN.

1. INTRODUCTION

The Internet is a widely used and increasingly popular public network. It is very large and has many uses, including accessing information electronically, accessing online services like email, and transferring data throughout the world. The use of the Internet will increase as users become more educated and more online services become available. The Internet contains a vast amount of information, some of which should be kept private. E-commerce and online banking provide examples of the type of information that should not be shared with unauthorized users. As use of the Internet grows, it becomes more important for transferred data to be secured.

The idea of remote computing is also gaining popularity. Remote users access files and services from a computer located in a

different room, state, or even country. Access to the home or work computer allows users to stay productive, especially in an increasingly mobile working environment. Moreover, this computer connection needs to be secure so that the transfer of data between the local machine and the remote machine can not be intercepted, read, modified, or otherwise manipulated in a harmful way. One way to achieve a secure remote access connection is through the use of a Virtual Private Network.

1.1 What Is a VPN?

A VPN provides remote access to computers and data in a secure fashion. In [11] Venkateswaran defines a VPN as “a communication environment constructed by controlled segmentation of shared communications infrastructure to emulate the characteristics of a private network.” A VPN can be broken down into three parts: it is a network, it is private, and it is virtual.

A VPN is a network, a computer communication infrastructure that connects computers, printers, and other devices. This infrastructure can be either wired or wireless. Any two devices on this communication network can talk to and exchange information with each other via the underlying infrastructure. The Internet is an example of a very large inter-connected network.

A VPN is a private network available only to a closed group of authorized users. Information exchanged in a private network does not travel outside of the private network itself. This information can not be eavesdropped by someone who is not on the private network. The data transferred inside the private network is not affected by data being transferred outside the private network, and vice versa. In [11] Venkateswaran calls this

“traffic isolation.” The resulting network allows authorized users to privately access services and resources on the private network securely.

Finally, a VPN is virtual. The VPN is formed by temporarily extending or simulating a private network across a shared public network like the Internet. Ortiz explains in [10] that this simulated private network is formed by either a network to network (server- server) or a remote user to network (client-server) connection.

Users of the virtual network will be able to access services and resources from both underlying networks.

1.2 How Does a VPN Work?

A VPN uses a tunnel to simulate a private network over a shared public network. A tunnel is a connection between two endpoints for transmitting data. A secure tunnel keeps the simulated network private. The secure tunnel ensures that data sent through it will not be read or manipulated by users who are not authenticated with the simulated network. This is important because our secure private network is simulated over the insecure Internet. If the

personal or classroom use is granted without fee provided that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

UMM Computer Science Seminar II 2008, Morris, MN.

Copyright 2008, Rob Jansen.

tunnel were not secure, anyone with Internet access could potentially read and modify data as it is being transferred between the endpoints. The secure tunnel serves as a link that connects the endpoints and creates the virtual network.

Data gets transferred through the secure tunnel and is delivered to the correct endpoint of the virtual network. Each computer or node connected to the virtual network has a virtual IP address (VIP). This VIP allows each node to be accessible by other nodes on the virtual network. Data is transferred between nodes by following a secure tunneling protocol like Secure Sockets Layer(SSL)/Transport Layer Security(TLS) Protocol, or Internet Protocol Security (IPsec). TLS [4] is SSL's successor, but is still referred to as SSL or SSL/TLS because of SSL's popularity. In this paper we will refer to the protocol as SSL. This paper will focus on VPNs that use SSL for establishing secure tunnels for transmitting data. SSL is discussed in further detail in section two of this paper.

1.3 Why Is a VPN Useful

In traditional private networks, connectivity between separate networks occurred through a series of dedicated links. These links were physical wires leased from telecommunication carriers, were formed between physical locations, and only allowed to be used by the company that was leasing them. Venkateswaran suggests in [11] that private networks that use dedicated links are expensive to set up. A VPN allows remote access to a private network through a public shared network like the Internet. The use of the Internet as the underlying network makes a VPN solution both a low cost and flexible solution [7, 10, 11, 12], especially when compared to the more traditional VPNs that use dedicated links [10]. The Internet is already an established public network, so there is no extra leasing cost. The Internet is also very flexible in that it is far-reaching and spreads throughout the world. Anyone with Internet access has the potential to authorize themselves with the VPN and use its services and resources.

The flexibility of a VPN makes it popular among companies with traveling employees who still need access to the company's local data network [7, 11]. Working from home or while traveling increases productivity and is convenient for employees. Mobile workers can use VPN technology to connect to their company's network from anywhere they have Internet access. They would be able to use services and resources of the company network while not physically at the office. This would allow them to increase their efficiency while away from the office.

A VPN can also be used to secure a wireless network connection [6]. Many wireless network routers use a form of insecure wireless security that is susceptible to attack. Bittau, Handley, and Lackey discuss [2] the insecurity of WEP, a common method of securing wireless network connections. Their discussion suggests a new method is needed for securing wireless networks. A VPN provides wireless security because all data travels through a secure tunnel. Gupta shows in [5] that SSL ensures the security of wireless networks. An SSL VPN would be a secure solution to a wireless network connection.

2. SSL SECURITY METHODS 2.1 SSL Security on the Internet

SSL has emerged as one of the most dominant security protocols used on the Internet today [3]. SSL is widely used and known to

be secure [1, 5, 9]. SSL is used in many applications that need security, including email clients, online banking, online shopping, and many websites that collect confidential information such as passwords, PINs, or credit card numbers [5]. In web browsers, HTTPS in the address bar indicates that SSL is being used as part of the session. There is no need to install a separate program to use SSL since it is supported by web browsers [1, 9]. This also means there is no need for any additional hardware to support SSL. SSL is an easy to use protocol for data transfer that can be adapted to any application, including VPNs.

2.2 SSL Protocol

The SSL protocol consists of three main parts. Before we can transfer data, we must have established a secure connection between the data source and destination. This is the SSL tunnel.

Once the SSL tunnel is established, we then need to secure the data by encapsulating it with SSL. Finally we need to tell the data where it needs to travel by encapsulating it in TCP/IP. These methods follow the SSL Handshake Protocol and the SSL Record Protocol, and are discussed in further detail below.

Figure 1. SSL tunnel establishment via the SSL Handshake Protocol.

2.2.1 SSL Tunnel Establishment

To securely transport data, we establish an SSL tunnel, a secure

connection between the communication partners. The SSL tunnel

authenticates and verifies these partners. The method used to

establish the SSL tunnel is the SSL Handshake Protocol. The

partners mutually authenticate and negotiate the version, cipher,

and compression methods that will be used during

communication. They exchange random numbers that are used to

compute a shared secret key. This shared key is used during the

following communication between the partners over the

established tunnel. The protocol can be seen in more detail in

figure 1. The communication partners will use the tunnel to

exchange SSL encapsulated data.

2.2.2 SSL Encapsulation

Data sent over an SSL tunnel is SSL encapsulated to provide data confidentiality through encryption. Encryption is a security process where human readable text passes through an algorithm and gets transformed into non-human readable text, or ciphertext.

The reverse process involves decryption of the ciphertext into human readable text. Encryption and decryption use the shared key computed during tunnel establishment. Decryption of data can only be performed by using the same secret key that was used to encrypt the data. The process of encryption and decryption provides data confidentiality because only the communication partners will know the secret key and be able to decrypt and read the data.

SSL encapsulation also provides data integrity through the use of a message authentication code (MAC). A MAC is a computed value based on the data contents. The sender computes a MAC of the data before sending, and includes this MAC in the encrypted message. Then the receiver decrypts the message and also computes the MAC of the received data. If the data has not been modified, both the sender's and receiver's MAC will match. The MAC is like the data's fingerprint, it provides data integrity by ensuring that the data is not changed during transmission.

The SSL Record Protocol encapsulates data by fragmenting it into smaller blocks, compressing it, computing and adding the MAC, encrypting it, and adding a SSL header. The SSL header, which encapsulates or wraps around the data, contains information about the original data. SSL encapsulation is important because it encrypts data so it is unreadable without the decryption key. The result of this process can be seen in figure 2 (a).

Figure 2. Encapsulation of data via the SSL Record Protocol.

2.2.3 TCP/IP Encapsulation

TCP/IP encapsulation adds an IP header and TCP header to the SSL encapsulated data. The IP header contains the source and destination address and the TCP header contains the source and destination port. The source is one endpoint of the tunnel, and the destination is the other endpoint. The encrypted data is now ready for transmission across the Internet through the established secure SSL tunnel. The final transmitted data can be seen in figure 2 (b).

Once the data reaches the other end of the tunnel, it is unwrapped by removing the TCP/IP headers and retrieving the SSL encapsulated data.

3. SSL VPN

An SSL VPN is made up of VPN server and VPN client endpoints. As in figure 3, the VPN server creates SSL connections with the clients and relays data between the client and the private network services used by the client. The VPN server also performs SSL encapsulation, including encryption, on outgoing data from the private network before sending it to the client through the SSL tunnel. Incoming client data gets decrypted and relayed to the private network services. Encryption and decryption must be performed on all data traveling through the tunnel. The data relay and continuous encryption and decryption of data over the SSL tunnel is very computationally intensive. The VPN's communication quality is therefore dependent on the VPN server's computational power [12]. This creates a bottleneck at the VPN server. The speed of transferring data through the tunnel will only be as fast as the speed at which the VPN server can encrypt, decrypt, and relay data. The communication quality of the VPN will be degraded for each additional connection to the VPN server.

Figure 3. SSL VPN architecture.

3.1 Advantages of a SSL VPN

The benefits of an SSL VPN include the benefits of a VPN in addition to the benefits of SSL. An SSL VPN provides robust security and privacy to its users. As discussed earlier, this security is provided through the use of SSL tunnels and encryption. Other advantages include the low cost, easy setup, and flexibility. An SSL VPN can securely transfer data across the world. Clients need not install special software because a SSL VPN can be used inside a browser. A SSL VPN is a secure way to connect to a remote network.

3.2 Disadvantages of a SSL VPN

One of the main problems with a SSL VPN is the bottleneck created by the VPN server. Encryption and decryption are computationally demanding tasks that ensure data confidentiality and message integrity. The SSL VPN server is the destination for this computational load, and therefore the source of the bottleneck. The bottleneck occurs because all data traveling between the private network and the remote clients must travel through the VPN server. The use of an asymmetric VPN has reduced this bottleneck and improved the throughput of the VPN server [12].

4. ASYMMETRIC SSL TUNNELS

The main paper [12] in our study of VPNs introduces a method to

help increase the efficiency of the data transferred over the VPN.

We will look at the idea of Asymmetric SSL Tunnels (AST) to help reduce this bottleneck and improve the throughput of the VPN server. VPN server throughput is the amount of data per time unit that will transfer through the server. Higher throughput values mean higher communication quality for the VPN. The idea behind AST is to distribute the VPN server's computational load among application servers that the client communicates with on the VPN so as to reduce the overall computations performed by the VPN server itself. This will free up CPU resources on the VPN server resulting in an overall increase in communication quality.

In the AST solution, the VPN server is still responsible for the SSL tunnel establishment with the VPN client. The VPN server and VPN client are the endpoints of this tunnel and data will be transferred securely between these two points. SSL encapsulation is no longer performed by the VPN server, but instead this task will be performed by the data's corresponding application server.

We now provide a data flow example to help illustrate the operation of the SSL VPN using AST.

4.1 Operation

4.1.1 Handling the Request

To begin communication, the client and server create a secure SSL tunnel following the SSL Protocol. The process was described earlier. Once the tunnel has been established, the client performs SSL encapsulation and TCP/IP encapsulation and sends data in the form of a request through the tunnel to the VPN server, as in figure 4 (a). The VPN server does the reverse, it unwraps the data by removing the TCP/IP and SSL headers, and decrypts the request in order to verify the data, authenticate its source, and forward the data to the correct application server in figure 4 (b).

Once authenticated and decrypted, the request is sent to its destination application server on a private network. If the network between the VPN server and the application server is insecure, which means there are possibly other clients on the network who could intercept the data, the VPN server can encapsulate the request from the client with SSL and send the data to the application server through another SSL tunnel. This extra tunnel requires additional SSL encapsulation and increases the computational load of the VPN server and the destination application server. This step can be skipped if all clients on the private network are trusted. The application server receives the request and processes it accordingly, as in figure 4 (c).

Figure 4. Data flow in a SSL VPN using AST.

4.1.2 Handling the Response

4.1.2.1 SSL Encapsulation in Application Server

Once the request is processed by the application server, it then forms a response for the client. The response data is SSL encapsulated by the application server instead of the VPN server, as shown in figure 4 (d). This is possible because the VPN server does not need the original plaintext response from the application server for any verification or authentication purposes. This encapsulation occurs even if the network between the application server and the VPN server is secure or trusted. This results in outgoing data from the application server always being secured with SSL. In figure 4 (e), the application server then performs TCP/IP encapsulation on the response data. This TCP/IP encapsulation adds a fake TCP header whose destination address is that of the VPN server. The fake header also contains other information so the VPN server knows where to forward the response. The application server then sends the encapsulated response to the VPN server.

When the response arrives at the VPN server, it has already been SSL encapsulated. This will save the VPN server computational load while sending the response back to the client. The VPN server now uses an IP engrafting algorithm to correct the response's TCP header and to forward the encapsulated response to the client.

4.1.2.2 IP Engrafting in VPN Server

The VPN server receives a response that needs to be forwarded to the VPN client. This response can simply be relayed to the client through the correct SSL tunnel it has established with the VPN server. Normally this response must travel through the VPN server process that handles VPN data; however, this is no longer needed since the application server has already prepared the data for the client. The IP engrafting algorithm handles this relay by accelerating the response through the VPN server, as described in figure 4 (f).

The TCP header of the application server's response needs to be corrected to include the destination of the VPN client. The VPN server stores this engrafting information in a table. The table contains information that is inserted into the fake TCP header to produce a valid TCP header. This will allow the VPN server to send the response to the VPN client through the correct SSL tunnel. IP engrafting will now take the response and forward it directly to the correct outgoing TCP port. The encapsulated response will appear to be legal outgoing data to the TCP/IP protocol, and will be immediately sent through the SSL tunnel for delivery to the client. The client will then receive and process the response data, as figure 4 (g) shows.

4.2 Implementation and Architecture

In [12], Zhou, et al, implemented AST with OpenVPN. OpenVPN is an open-source SSL VPN solution with a wide array of features. OpenVPN has two modes, VPN client mode and VPN server mode. A third mode, called app server mode, was developed as part of the AST solution. The app server mode was based on the VPN client mode, and is meant to be run on the application server. The use of the three modes in the AST SSL VPN is described below.

VPN server mode includes a module that was written and loaded

into the kernel of the VPN server. This module performs the IP

packet engrafting. Even though SSL encapsulation is now performed in the application server, it is preserved in the VPN server in case it is needed for data that has not yet been encapsulated.

VPN client mode is used to handle the VPN on the client machine. This mode has not been modified in the AST solution.

The client mode is responsible for performing SSL encapsulation of outgoing data and sending it to the VPN server through an SSL tunnel. It also unwraps incoming data from the VPN server for use by the client machine.

App server mode is a new mode which is based on VPN client mode. The app server mode will automatically search and create a SSL tunnel with the VPN server. It uses this tunnel to receive SSL encapsulation information from the VPN server. The application server will use this information when it encapsulates responses for the client. The VPN server may wish to send data from the client through this tunnel. This is useful if the network between the VPN server and the application servers is insecure.

4.3 Performance

Experiments were done to test the throughput and response time of an SSL VPN using AST [12]. The experiments were done with one VPN server and four application servers. The File Transfer Protocol (FTP) was used on the application servers to test throughput and ping was used to test response time.

4.3.1 Throughput

During the throughput test, fifty clients were simulated for each application server. These clients established a VPN connection with the application servers using traditional SSL tunnels. Each client continuously downloaded data from the application server.

The application servers started app server mode and switched to AST one by one, and the CPU utilization and throughput were recorded for comparison.

Figure 5. The effect of CPU utilization of the VPN and application servers.

4.3.1.1 Internal Security Not Required

Data sent from the VPN server to the application server is sent in the clear when internal security is not required. This means that SSL encapsulation is not needed on data traveling from the VPN server to the application server. Figures 5 and 6 show the results of the tests. As each application server switched to AST, its CPU utilization increased because it was now performing the SSL encapsulation of the response data. SSL encapsulation was no longer performed at the VPN server. This reduced the VPN server's CPU load and the released CPU resources were used to slightly increase the throughput of the other application servers.

The application server that switched to AST had free CPU resources and could perform SSL encapsulation more quickly than the busy VPN server. After the faster encapsulation, the VPN server only had to forward the data to the VPN client using IP engrafting. This resulted in a dramatic increase of 260% in the throughput of the application server. Each application server increased its throughput by switching to AST, and each contributed to an increase in throughput of the entire VPN.

Figure 6. The effect of AST on the throughput of the VPN and application servers.

4.3.1.2 Internal Security Required

SSL tunnels are used to transfer data between the VPN server and

the application server when internal security is required. This

means the application server will need to unwrap and decrypt the

incoming data before processing a response. This results in

slightly higher initial CPU utilizations and slightly lower initial

throughput values than we see in the case where internal security

is not required. The increase in throughput is a result of the VPN

server directly forwarding the application server's response to the

VPN client, instead of unwrapping, decrypting, and re-

encapsulating it for the VPN client, which would normally be

done when using a SSL VPN.

4.3.2 Response Time

Ping was used to test response time between the client and the application servers. The mean of fifty pings from the VPN client to the application server is used for comparison. When internal security was required, the AST solution reduced the response time of the traditional SSL tunnel approach from 11.2 milliseconds to 7.7 milliseconds. The AST solution has a lower response time because it eliminates the need for the VPN server to unwrap and decrypt the response from the application server and re- encapsulate it for the VPN client. This means the VPN server is performing one less decryption and encryption for every response.

When internal security is not required, the AST solution did not reduce the response time achieved with the traditional SSL tunnel.

5. ALTERNATIVE UDP APPROACH

SSL tunnels are usually TCP based, however, the tunnels can also be based on UDP. When using UDP tunnels in the AST SSL VPN, a method called UDP diffusing can be used. UDP diffusing will cause the application servers to send the response directly to the client instead of the VPN server as in figure 7. The application server does not need to create fake TCP headers when this mode is used, but instead will create a real UDP header with the client's destination address.

Figure 7. UDP diffusing in a SSL VPN using AST.

UDP is connectionless, that is, it will not create an end to end connection with the client and server. Because of this, data sent with UDP can possibly arrive unordered. Also, since there is no connection, there is no way to verify that transferred data has reached its destination. These limitations are important to consider when using UDP based tunnels.

6. CONCLUSIONS

SSL VPNs are a secure solution to transferring data over the Internet. However, this secure data transfer causes a bottleneck in the VPN server. It has been shown that a AST solution can be used to increase the throughput and response time of the VPN and application servers by distributing the computational load among application servers. The performance results suggest that the increase in throughput is more beneficial when a higher percentage of application servers are using AST.

In the results presented, the throughput of the VPN server was 9.64 MB/s, close to the maximum for TCP-based SSL tunnels.

Once the maximum throughput is reached in the VPN server, the servers using AST will more or less have an equal part of the maximum throughput while the servers using SSL tunnels will have a smaller portion. This allows the administrator to control which servers will be allowed a higher percentage of throughput by specifying which ones will use AST and which ones will not.

For example, an email server that is not extremely time dependent could be allowed a smaller portion of the throughput by using SSL tunnels. The servers that are more time dependent could achieve higher throughput by using the AST approach. Testing would be beneficial to efficiently handle specialized cases where tight control is needed.

It is important to consider that the main increase is throughput of outgoing data flow. Incoming data flow will be more or less unaffected since no acceleration is performed while transmitting data from the VPN server to the application server. Connections where large amounts of data are mostly being transferred from the client to the application server would not see an improvement in throughput. It is also important to consider that the AST solution described is research. Thorough testing is needed to help us uncover issues that may arise during its use.

7. ACKNOWLEDGMENTS

Thanks to Andy Lopez for his guidance and support throughout the research, drafting, and review process. Thanks to Andy Lopez and Leiah Stevermer for providing feedback on my paper.

8. REFERENCES

[1] Bisel, L., “The Role of SSL in Cybersecurity,” IT Professional, 2007, vol. 9, no. 2, pp. 22-25.

[2] Bittau, A., Handley, M., and Lackey, J., “The Final Nail in WEP's Coffin,” IEEE Symposium on Security and Privacy, 2006.

[3] Chou, W., “Inside SSL: The Secure Sockets Layer Protocol,”

IT Professional, 2002, vol. 4, no. 4, pp. 47-52.

[4] Dierks, T. and Allen, C., “RFC2246: The TLS Protocol Version 1.0,” 1999. http://www.ietf.org/rfc/rfc2246.txt [5] Gupta, V. and Gupta, S., “Securing the Wireless Internet,”

IEEE Communications Magazine, 2001, vol. 39, no. 12, pp.

68-74.

[6] Kang, N., Iacono, L., Ruland, C., and Kim, Y., “Efficient Application of IPsec VPNs in Wireless Networks,” 1st International Symposium on Wireless Pervasive Computing, 2006.

[7] Khanvilkar, S. and Khokhar, A., “Virtual Private Networks:

An Overview with Performance Evaluation,” IEEE Communications Magazine, vol. 42, no. 10, 2004, pp. 146- 154.

[8] Kizza, J., “Computer Network Security,” Springer, 2005, pp.

440-455.

[9] Kuihe, Y. and Xin, C., “Implementation of Improved VPN Based on SSL,” 8th International Conference on Electronic Measurement and Instruments, 2007.

[10] Ortiz, S., “Virtual Private Networks: Leveraging the Internet,” Computer, 1997, vol. 30, no. 11, pp. 18-20.

[11] Venkateswaran, R., “Virtual Private Networks,” IEEE Potentials, 2001, vol. 20, no. 1, pp. 11-15.

[12] Zhou, J., Xia, H., Wang, X., and Yu, J., “A New VPN

Solution Based on Asymmetrical SSL Tunnels,” Japan-China

Joint Workshop on Frontier of Computer Science and

Technology, 2006, pp. 71-78.