SSL VPN

Vittorio Picco

February 19, 2008

Contents

1 Introduction 2

2 VPN and SSL technologies 3

2.1 VPN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 SSL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 IPsec vs. SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.1 Network and Transport layer security . . . . . . . . . . . . . . . . . . . . . . . 4
2.3.2 Relation with the operating system . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3 IPsec is a complicated protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.4 IPsec advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 SSL VPN details 7

3.1 SSL VPN as a black-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Technical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Reverse proxying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2 Application translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3 Network extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 OpenVPN 11

5 Security issues 16
5.1 Client side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Network and connection problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Endpoint security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
In the end: the stupid user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
The list could last forever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Server side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6 Conclusions 20

1
Chapter 1

Introduction

In the last 15 years the explosion of the Internet has changed many things in the way companies
communicate with their customers and relate to their employees. E-banking, e-commerce, teleworking
are just some of the many possibilities that the Web offers. As soon as all these services where
developed it was clear that they were as powerful as useless if not implemented with a lot of attention
on the security aspects. In particular two technologies fully satisfied this needs, and made them
possible: SSL (Secure Sockets Layer) and VPN (Virtual Private Network).
With SSL (now called TLS; during this document I will often use both terms, since TLS is in prac-
tice SSL v3.1, and the terminology won’t affect the explanation) many important security concepts,
like authentication and encryption, could be implemented in an easy way in web browsers and email
clients, allowing ordinary people to securely connect to web sites and email sevices.
VPNs are a perfect solution for those companies that need to securely connect different networks
or PCs over an untrusted network like the Internet. Using a VPN a company can allow employees to
connect to its internal network from virtually anywhere in the world.
In this document I am going to present a new way to implement VPNs, not with the traditional
use of IPsec but with SSL. IPsec shows several drawbacks, due both to the OSI layer to which it is
applied and to the way it relates with the operating system.
Furthermore, I am going to analyze a product available on the market to create SSL VPNs:
OpenVPN. I will briefly describe the features it offers and how to use it to build a simple Virtual
Private Network.
In conclusion we will analyze some security issues related to the SSL VPN technology.
It is important to remark that at the moment this report is being written, there isn’t any official
SSL VPN standard. All the analysis made here try to look at the SSL VPN problem in a general
way, expecially for what relates the security issues. Each product available in the market should be
evaluated separately, understanding which features it offer and therefore which problems is prone to.

2
Chapter 2

VPN and SSL technologies

As we said, the boom of Internet based technologies made all the companies aware of the computer
security problems. One of the most interesting challenges was to find a way to route sensible infor-
mation over unsecure networks, like the Internet. Most companies can’t simply afford the cost of an
ad-hoc link between, for example, two different plants or the CEO home and his office. The solution is
to use already existing networks. Internet on the pros side has got its ubiquitousness and the very low
cost; the only cons is probably also the hardest to deal with: the complety unsafety. Packets travelling
on the internet can be sniffed, manipulated, hijacked, deleted so that nobody can feel completely safe
out there.

2.1 VPN overview

VPNs are a way to create a link between two routers or two PCs over the Internet, or, generally
speaking, any untrusted network, encrypting and authenticating the packet’s flow, so that both ends
of the communication can trust each other. VPN are usually used by companies to allow their
employees to access the company’s internal network remotely. Another use of VPNs is to connect two
remote sites of the same company, to share common resources like file servers. The distinguishing
characteristic of VPNs are not security or performance, but that they overlay other network(s) to
provide a certain functionality that is meaningful to a user community.
It is clear that this is a very abstract concept: how do we make this overlaying network in practice?
Supposing we are able to build it, probably we would like to add to this network some security
features, so we have a lot of other questions to anwser, like: how do we encrypt packets? how do
we authenticate them? how can we feel reasonably sure that they can’t be manipulated? The most
common implementation of a VPN makes use of IPsec.

2.1.1 IPsec
IPsec is a technology that defines two protocols: one for encryption (ESP) and the other for au-
thentication (AH). In addition, a third protocol (IKE) is used to exchange the keys needed for the
cryptografic operations. IPsec protocols operate at the network layer, layer 3 of the OSI model. They
allow to implement a VPN; an IPsec VPN can work in two different modes: transport and tunnel.
In transport mode only the payload of the IP packet is encrypted (or authenticated), the header is
not. In this way all the routers along the path can read the source and destination address and thus
perform the routing correctly.
In tunnel mode the whole IP packet is incapsulated in a brand new packet, whose source and
destination addresses are not anymore the one of the two ends of the communication, but the one of
the first and last router. If somebody sniffs a packet, he can’t neither understand who are the actal
sender and recipient of the message. On the other hand, this does not allow a host-to-host link, but
only a gateway-to-gateway.

3
2.2 SSL overview
SSL is a protocol that provides encryption for network-based traffic. SSL is a network protocol with
responsability for the management of a secure, encrypted, communication channel between a server
and a client. SSL is implemented in the major Web browsers. One of the most basic functions of SSL
is message privacy. SSL can encrypt a session between a client and a server so that applications can
exchange and authenticate user names and passwords without exposing them to eavesdroppers.
One of the most powerful features of SSL is the ability for the client and the server to prove their
identities by exchanging certificates. All traffic between the SSL server and SSL client is encrypted
using a shared key and a negotiated encryption algorithm. This is all effectuated during the SSL
handshake, which occours at session initialization. Another feature of SSL protocol is that SSL
will ensure that messages between the sender and the receiver have not been tampered during the
transmission. The result is that SSL provides a secure channel between a client and a server.
SSL runs on what is called a “secure session layer”, an intermediate layer added to the original
TCP/IP stack between Transport and Application. This allows SSL to encrypt not all the IP traffic,
but only selected application’s messages, giving the user a greater flexibility.

2.3 IPsec vs. SSL

There are some significant differences between SSL and IPsec. They are due to the different layer to
which security is applied and the way these two protocols are implemented in a computer.

2.3.1 Network and Transport layer security

The first big difference between SSL and IPsec is the layer of the OSI stack at which security is applied.
First of all, we have to remark that the TCP/IP stack is different from the OSI one. The first is made
up of 4 layers: Data Link, Network, Transport and Application; the second is composed of 7 layers:
Physical, Data Link, Network, Transport, Session, Presentation and Application.
When we design a security protocol, we have to choose at which of this layers we want to operate.
This choice affects two main variables: the degree of security, in terms of encrypted data, and the
flexibility, that is the possibility for the user to choose which applications protect and which not.
IPsec deals directly with IP packets, therefore it works at the Network Layer. No matter which
application is sending the packets, no matter which TCP socket the packets are directed, they are all
encrpyted and/or authenticated.
On the other hand, SSL operates at the session level. This could sound strange, because TCP/IP
has no session layer! In fact SSL operates in what is called a “secure session layer”, which lies between
Transport and Application layers. This is a small modification of the classical TCP/IP layers, but
allows to implement security in a better way. Why? To answer this question, we must briefly analyze
the behaviour of a security protocol when applied to a certain stack layer. Let’s consider the classical
4 TCP/IP layers.

• Application: a security protocol operating at the application layer provides the best solution
in terms of flexibility. It’s possible to create different rules for each application and it’s possible
to implement different degrees of security depending on the data the application manages. The
down side is that every application must be modified to implement the security protocols, there
could be communication problem between similar applications that implements the security
policies in a different way and, last but not least, informations like IP addresses cannot be
protected because they are inserted only at a lower layer.

• Transport: at this layer the security policies are application independent and therefore we
have not the same flexibility as before, but we do not need to modify each application we want
to protect. The security protocol can be implemented, for example, as a plugin, with many
advantages in terms of easiness of installation and use. We can consider SSL as operating at
this layer, even though actually it works in a slightly upper one.

4
 • Network: this is where IP packets are created and managed. Security controls at this level
allow to encrpyt and/or authenticate all the IP packets, including sender and recipient addresses.
The price to pay is a loss in flexibility because at this layer we do not know which application
has created which packet, so all the traffic belonging to a specific IP address is controlled. At
this layer works the IPsec protocols suite.

• Data Link: the data link layer handle packets travelling on physical links between two ends,
like your modem and your ISP, or a dedicated circuit between two buildings. Here it’s possible to
encrypt all the information travelling on a network, including application data, IP and physical
addresses. The problem is that since this layer handle physical links between two ends, it’s
not a layer where is possible to create a VPN, because a VPN is, by definition, something that
operates on an untusted network, and not on a physical link. If you can afford a direct connection
between your company site in Europe and the other one in Argentina you don’t have any need
for a VPN.

From this brief description we can understand how do security protocols work: the more you
implement it at a high level the more you will gain in flexibility but with a growing cost of usability
and easiness of installation, and also protecting less informations; the more the security protocol is
implemented at a low level the more it will protect information and will be application independent,
with the price of a lower flexibility and customization possibilities.
Network layer security solutions were the most used, because they can protect a lot of informations,
in particular the IP addresses, allowing a sufficient degree of customization. Recently, the interest of
companies has moved toward Transport (or Session) layer security for different reasons. A this layer we
can have more customization possibilities, and in particular we can protect in a different way different
TCP sockets. For example we can decide to encrypt the HTTP traffic but leaving uncrypted the FTP
traffic, and so on. It is true that at this level we cannot protect IP addresses, but this is not a high
price to pay: unless we provide authentication with IP there is a web portal that is the interface of
the application proxy (located inside the internal trusted network): it is the proxy that operates with
administrative privileges.addresses (and nobody should do), an attacker performing IP spoofing on a
system secured at transport layer can only perform Denial of Service attacks. Describing IPsec, we
have also seen that protecting low level information like IP addresses need us to work at tight contact
with the Operating System, and this is discouraged. A transport (or session) layer application can
come out as a simple plugin, allowing each application to decide whether to use it or not.

2.3.2 Relation with the operating system

Since IPsec operates at the network level of the OSI stack, it deals with the encapsulations of packets,
and therefore must interact directly with the operating system. IPsec violates what is called the
OS ring architecture. This architecture represents an operating system as a set of concentric circles.
In the inner circle, called Ring 0, lie the kernel and all those processes that need a direct contact with
the hardware, like peripheral drivers; in Ring 1 there are some system tasks and so on. Usually, user
applications lie in Ring 3. The OS ring architecture states that applications running in a certain ring
cannot interfere with application running in an inner ring. It is now clear that IPsec break this rule.
When I want to install a VPN I should not deal directly with the kernel, but only with applications
with far less privilieges. Let me state one point: the OS ring architecture is not something sacred or of
vital importance, but is a system that has been proved as secure and easy to maintain. If one chooses
not to follow this philosophy must know that he is leaving a safe, tested way to write applications.
In addition, this tight coupling with the OS makes Windows implementation different from a Linux
one, or a MacOS one, since different kernels requires different IPsec implementations. Once the codes
are written and inserted in the kernel you must be sure that 3 different implementations of the same
protocols can talk to each other with no problems. Furthermore, in systems like Linux, subjected to
periodic kernel updates, we must guarantee that the protocol is able to work fine after every kernel
update.
As a result IPsec results quite difficult to install and maintain, expecially in devices like mobile
phones or PDAs. In such devices there isn’t any or a very little operating system and it’s usually as

5
small as possible, so IPsec does not fit well.
On the other hand, SSL implementations work at a higher Ring, Ring 3, and can come out as a
simple plugin for already installed applications, like web-browsers. If there are updates of the protocol
they can be easily installed and configured, without the need to worry about the kernel. On the
contrary, updates of the kernel will not require a particular attention to be sure that SSL would still
work. We cansee the difference between SSL and IPsec like the one between a normal program and
a device driver. Managing drivers requires more attention than managing programs, right because
drivers works in an inner Ring.

2.3.3 IPsec is a complicated protocol

The reason why most of the VPN solutions on the market until now were based on IPsec is simply
that at the time VPNs where developed, IPsec was the only reliable security protocol. As said in [2]:
“IPsec was not chosen due to its great strength as a protocol. It was chosen because it was the only
game in town”.
IPsec is a very complicated protocol. Some analysis performed on it (see [3] as an example)
found that IPsec is complicated at a point that is not possible to understand if it’s actually secure.
Complexity is a big issue in the security field. As long as a software is simple, it can be tested, bugs
can be easily found and corrected, thus resulting in a higher security level. In contrast, IPsec was
developed by a commitee and we know the maxim: “A camel is a horse designed by committee”. The
resulting protocol was something too large, even with too many functionalities than desired. The best
example is about the modes of IPsec. When we described transport (which encrypts only the payload)
and tunnel (which encrypts all the packet) modes, one could ask why choosing the transport mode,
since it protects less informations? In fact this is not a stupid question. Developing two different
modes causes a high rise in the complexity of the protocol, with all the risks in term of security
we just summarized. A protocol with only tunnel mode will have no more possibility to distinguish
between host-to-host and gateway-to-gateway links, and this is probably a reasonable cost to pay if
the result is a way less complex protocol.

2.3.4 IPsec advantages

There are some cases where IPsec is still the best way to implement a VPN. The minimum requirement
for SSL to work fine is that both ends support the SSL protocol. There could be some cases where
the machines or the servers in a network are very old and can’t even run a browser, or simply nobody
has ever installed the SSL plugin in an old browser already installed.
Another case is when we want to protect all the traffic of a network. In an SSL VPN environment,
we would need to configure every single application to use the SSL protocol. This could be a problem
because in large networks we may have a lot of applications, requiring many different ports. Every
application should then open an SSL communication with the other end, exchanging certificates and
so on. This could result in quite a big overhead both in terms of network traffic and of work needed
to configure all the applications.
The last inconvenient when using SSL is caused by packets drop. When a host receives a packet
manipulapted by an attacker, malformed or duplicated, he must drop it. With IPsec this happens at
network level, while with SSL the packet must travel through Data Link, Network and Transport layers
and finally be rejected. This can cause a bigger computational effort in an SSL protected system, but
it is a so small inconvenient that in practice it is useless to care about it.

6
Chapter 3

SSL VPN details

As we have seen, SSL has got many advantages with respect to IPsec. It is a small, constantly
maintained and updated protocol, that does not need difficult configuration and does not interfere
with the operating system; it allows to define application layer policies to choose which application
should make use of the secure connection and which not. It does not work at kernel level, simplifying
the installation and maintenance phases. SSL has been designed having in mind Internet based money
transaction and secure exchange of data; probably in the 90’s Netscape didn’t realized that SSL could
also be a very efficient way to implement a VPN. Long story short, the advent of the Internet era, of
a constantly increasing speed of the connections and the availabaility in almost every computer in the
world (and also in the International Space Station) of web browsers, radically changed the situation.
The biggest advantages of an SSL VPN with respect to an IPsec VPN, are in terms of easiness of use
and low cost.
We can start to describe SSL VPNs as black boxes, to see which functions and features they offer,
regardless of the way the are implemented.

3.1 SSL VPN as a black-box

The trick of SSL VPNs is to combine the features of the SSL protocol to the abstract concept of a
VPN. If we want to build our own SSL VPN we must decide which features we want our VPN to offer,
regardless of the programs and utilities that we will later on decide to use. This choice will affect the
number of services offered and the degree of security of our VPN.

3.1.1 Features
The main features an SSL VPN can offer to their user are:
• Manageability: in this category we can insert features like status reporting, logging and audit-
ing. Another interesting possibility is remote network management, to offer the network manager
the possibility to fix problems also when he is not on-site.

• High availability and Scalability: high availability is the property for a network to work
also in the case of a device failure. This goal can be achieved setting up two parallel SSL
connection. There are two ways to manage them: in the active/passive mode one connection
is used to transfer the packets and the other one stands by; if the first connection fails, the
second one becomes active. In the active/active solution there are two connections handling the
network traffic; this solution allows the same failure recovery feature as the previous, but, in
addition, it can provide scalability. Scalability is the ability to balance the network load on the
two connections, to avoid congestions. This features can be achieved by means of a balancer,
placed internally or externally the network, and is sometimes called IP Spraying.

• Portal customization: we will see later what exactly is a VPN portal, but anyway this feature
is simply the possibility to customize the web site used to access the remote network. This is
needed not only to obtain a good looking home page, but also to allow devices with limited

7
 display possibilities, such as mobile phones or PDAs, to access the VPN. Another feature is the
possibility to show an user with limited privileges only a limited access to the network services.

• Authentication: whilst a normal SSL connection need only the server to authenticate, in a
VPN environment both client and server authentication are needed. Authentication can be
achieved by means of different technologies, like username and password, one-time-password,
smart cards, X.509 certificates and so on. Authentication can be performed on a individual or a
group basis, using different forms of authenthication for users or groups with different privileges.
The network administrator should create an authentication policy to define clearly which user
or group must use which authentication form.

• Encryption and Integrity: these two important features are the same offered by a standard
SSL connection, nothing more, nothing less.

• Access control: one of the most interesting features of an SSL VPN solution is the possibility to
have a granular access control. Once a user has gain access to the network via the authentication
method specified in the authentication policy, he can access resources as stated in the access
control policy. For example some resources can be available only for certain users, some others
can be accessed only at certain times, etc.

• Endpoint security controls: since theoretically with SSL we can access network resources
from anywhere in the world, we would like to be sure that the computer the user is running
is secure, or at least offers some security. Probably from public internet kiosks the antivirus
installed is not updated: this represents a risk for the company network, therefore we should
allow that user only a limited access to the internal resources. This is of particular concern with
an SSL tunnel VPN, where the user is operating in the network with special privileges.

• Intrusion prevention: this feature allows to check the content of the packets that are carried
through the SSL VPN, to avoid virus diffusion or spyware installation after data are decrypted.
This process, though, adds latency to the travelling packets.

• SSL acceleration: since SSL requires a lot of cryptographic operations, in particular to encrypt
and decrypt packets, SSL VPN operations could result slow. This problem affects in particular
the SSL VPN server, that by definition must handle many different SSL connections. To avoid
server overload the SSL operation can be done by external cards connected to the server or by a
dedicated computer connected to the network. In both cases the CPU load needed to perform
the cryptografic operations is left to the external components, so that the server can manage the
network traffic.

This very long list of features shows clearly that any implementation of an SSL VPN can vary
greatly depending on the particular requests of the VPN users. Before building any SSL VPN it is
of great importance to understand the needs of the company, and write a precise authentication and
access control policies, and the manageability requests. Other services can be added as “optionals”,
like intrusion prevention or portal customization.
The choice of which features the VPN will offer, is not a stricly technical decision. Usually the
requests for some services come from the managers, the employees, in general from the people that
will use the network. The goal of the network manager is to collect all the requests and then to choose
the best technical solution to satisfy all the requests. Usually there is a compromise to make between
security and easiness of use. This consideration is important because tells us that is important to
know the technical details of SSL VPN, but that the technical part does not make all the business.

3.2 Technical details

We can now enter more in the details of an SSL VPN solution. There are two main types of SSL VPN:

8
 • SSL portal VPN: [1] explains that “an SSL portal VPN allows a user to use a single standard
SSL connection to a Web site to securely access multiple network services. The site accessed is
typically called a portal because it has a single page that leads to many other resources. SSL
portal VPNs act as transport-layer VPNs that work over a single network port, namely the
TCP port for SSL-protected HTTP (443)”. An user wanting to access such a VPN needs a web
browser able to handle an SSL connection. He will connect to the portal, and through the portal
he will access the network resources, like files in file servers or company email, or internal web
pages, or everything that can be channeled through a web page. SSL portal VPNs can be used
from any computer in the world that have a web browser SSL enabled. In such a VPN we don’t
have internal IP addresses, but all internal network references are translated by the portal to be
accessible also from outside.
It is important to understand that the even though the user acess a web page, and network
services are channeled through web pages, it does not mean that an SSL VPN is a link between
applications. It is a VPN implementation, it works at those secure session layer added to the
TCP/IP four classical layers, and even though it provides a link between a browser and a server,
it is not working at application level. We are not talking about S/MIME or others secure
application level protocols. The application’s data are encapsulated and sent through a secure
session layer link. This is one of the advantages of SSL compared to application layer protocols:
since it does not work at application level it does not need any application modification, but
just a plugin added to it; the plugin allows the browser to use the underlying secure channel.
Do never think an SSL VPN as an application layer security protocol, because it is not.
• SSL tunnel VPN: this is a complete different way to access the VPN. Tunnel means that there
is an SSL connection between the remote user and the local network, and inside this tunnel are
travelling a number of different application protocols. This means that the user does not need a
web browser, but an application able to handle different protocols, like DNS or SSH for example.
The web browser is no longer needed because the packets exchanged do not carry exclusively
HTTP traffic, but every kind of protocol. It is still possible to use a browser, but there must be
some application working along with it able to read the non-HTTP traffic and treat it as needed.
In this configuration, the remote user is using a virtual private address belonging to the VPN,
so that he is in practice inside the network: he can use internal IP addresses and so on.
We will see some practical examples clarifying these concepts in the OpenVPN chapter. Now we
are going to take a look to which are the technical features, called functions that allow us to implement
an SSL portal or tunnel VPN.

3.3 Functions
3.3.1 Reverse proxying
Reverse proxying is a core function in an SSL portal VPN. The web page to which users access to
get a service acts as a proxy: it receives the request of the user and on his behalf retrieves the data
or makes a request to the remote, trusted network. The SSL connection is established between the
user’s browser and the remote proxy, that must therefore encrypt and decrypt entering and leaving
data. The term reverse is due to the fact that usually a proxy receives requests from a private network
and forward them to the Internet; in this case the proxy receives requests from the outside world and
translates them into internal requests. The user would not need to configure any HTTP or SOCKS
proxy on her client, because this time the proxy works on the other end of the connection.

3.3.2 Application translation

Application translation is another thing required for an SSL portal VPN to work. It is the ability to
convert one application protocol into another, to make it available in a web browser. One example is
simply the web mail. With web mail you don’t need an e-mail client to access a POP server, but you
can read and compose your e-mails using your web browser. Another example is the access to a file

9
server: if you want to remotely and securely access your company file server, with an SSL portal VPN
you can connect to the secure access web page, and then browse the files you’re interested to in the
company file server by using a normal web page; the only thing required is an SSL enabled browser.
Example: suppose you are a network manager, sitting in an airport with a wifi connection at
your disposal. As a good network manager you always think about the health of your network, so
now you want to ping your company’s file server to see if it’s still alive. If you built an SSL portal
VPN, what you have to do is to access the portal web page, authenticate as the network manager and
then you’ll be showed the portal. Using the browser you will click on the button “Ping test” that you
put in the portal web page; the other end of the communication will receive your request as a HTTP
request, but understands that you want to perform a ping test. Your HTTP request is translated into
an ICMP request toward the file server. The result of the ICMP ping operation is translated again in
the form of a text that will show up again in the portal, letting you know that the file server is fine
and you can take your plane without worries.

3.3.3 Network extension

Network extension is the ability for an user to remotely operate in the trusted internal network
remotely. From the user’s point of view nothing changes from being physically inside the trusted
network. This is a classic function provided by an SSL tunnel VPN. The network’s services are
tunneled through the SSL connection and received by your browser that, with the help of a Java
script interpreter or any other active contents handler, will show the user an interface; using this
interface the user can use the company’s network services exactly as he was inside it. The active
content agent is required to ask the internal network administrative privileges. In an SSL tunnel VPN
the web browser is not required, since the internal IP addresses are extended to the remote user.
Example: suppose you are again the network manager of the previous example and you want to
perform the same ping test. If you built an SSL tunnel VPN you log in the system with a web browser
or another application, authenticating as the network manager. This time your laptop is actually a
part of the remote network with a virtual internal address. If you know that the file server has got
10.8.0.34 IP address you can just open a terminal and type ping 10.8.0.34. You will get the ping
operation results exactly as if you were inside the network. We see that it is not important that we
use a terminal, or a plugin of your web browser that emulates a terminal: the important thing is that
there is an active content handler, able to deal with non-HTTP traffic.
In the next chapter we are going to take at look at one implementation of SSL VPN: OpenVPN.

10
Chapter 4

OpenVPN

OpenVPN is a multiplatform open source program that allows to implement an SSL VPN. OpenVPN
is available for different operating systems like Linux, Windows, MacOS X, FreeBSD. It offers the
same degree of security of a classical IPsec implementation, but with a greater flexibility; in addition,
it works in Ring 3 of the OS Ring Architecture. This makes the program more easy to install, in
particular in the case of different operating systems. OpenVPN supports different authentication
techniques and the access control policy can be created on a per-user or per-group basis. The most
important characteristic of OpenVPN is its easiness of configuration and use. Both in Windows and
Linux it can work as a simple terminal program, which only need a configuration file to be properly
set up. There are also graphic interfaces to further semplify the work of the users.
User-space VPNs like OpenVPN use virtual interfaces they control and access without direct kernel
intervention. OpenVPN makes possible the creation of an SSL tunnel VPN: in particular, in Linux,
it uses the dev tun, the virtual device which allows to create tunnels in routed networks. OpenVPN
works well also in bridged networks, and in such cases it makes use of dev tap. These two devices are
available in every kernel from version 2.4.x, so now almost all Linux machines are able to use them.
In Windows the situation is similar and are again used virtual network interfaces to allow the creation
of tunnels.
Explaining the features of OpenVPN can be quite long and tiring. To avoid this, we are now
going to see a practical example that will show how to install and set up a simple VPN between two
remote hosts; the client and the server authenticate each other by means of X.509 certificates. The
example relates to the Linux operating system, but for Windows only a minimum number of changes
are needed, only in the installation steps.

Installation
Depending on the Linux distribution there are many ways to install OpenVPN; the most common are:
the use of packages managers, the installation from an RPM file, the compilation of the source code.
No matter which way you install OpenVPN, you must be sure that you also install OpenSSL (used to
manage the creation of digital certificates) and Lzo if you also want to compress the network packets.
Once installed OpenVPN only needs to have a configuration file, one for the server and one for the
client.

Certificates and keys creation

The first thing we need to do is to create the Certification Authority (CA), that will sign both server
and client certificates. This operation can be done on any machine of the network. Once in the
OpenVPN installation directory, the instructions to use are:
. ./vars
./clean-all
./build-ca
The OpenSSL interactive creation of X.509 certificates will start. We have to fill the required fields
with the informations about the CA. Now it’s time for the server certificate. The instruction is:

11
./build-key-server SERVER_NAME

We must again follow the interactive instructions to create the server digital certificate. Now the
clients. If we decide to use X.509 certificates OpenVPN force us to authenticate both the server
and the client. This is an optional operation of the TLS protocol, that usually authenticates only
the server, but OpenVPN makes it compulsory for security reasons. Since at the end the client will
be tunneled into the remote network, we must be sure that he really is who he claims to be. The
instruction is:

./build-key CLIENT_NAME

This instruction must be replicated for each client we want to be able to access the network. At the
end we must create che Diffie-Hellman parameters used for the key exchange.
This procedure has created a folder named keys which contains all the public certificates and the
private keys that are needed. Now we have to move the files to their recipient, being careful when
moving the secret keys. Every host must have its X.509 certificate, its secret private key and the
the CA certificate. The server must also have the file with the parameters for the Diffie-Hellman
algorithm.

Configuration files
The configuration files are the core or the VPN functioning. Here are specified all the parameters
needed for the VPN to work, like the port used, security limitations (chroot, etc) and a lot of other
things. By showing the configuration files used in this example we will explain step by step their
meaning.

Server side
port 1194 ;or any other
proto udp ;or tcp

These are some of the most important directives for the server. OpenVPN official port is the UDP
1194; if for any reason we cannot use that port or even the UDP protocol, we can change the port
number (e.g. port 8080) and the protocol (e.g. proto tcp).

dev tun ;or tap

Here we must specify if want to use the tun virtual interface (routed network) or the tap (bridged
network).

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key # This file should be kept secret

Now we must tell OpenVPN where are the CA and server certificates. Obviously the server machine
will need the CA public certificate only, but will need both its public certificate and its private key.

dh /etc/openvpn/keys/dh1024.pem

We also have to specify the file with the Diffie-Hellman parameters, as aforementioned.

server 10.8.0.0 255.255.255.0

This instruction tells the server the network address and the corresponding subnet mask. The server
will automatically take the first address as its own. It is very important to note that this is an address
belonging to the set of IANA private addresses. This is because we are going to create an SSL tunnel
VPN, hence we will have an internal address exactly as if we were inside the network. Both clients
and server are able to talk only with this private address.

12
;client-to-client

If this line is uncommented, the clients in the VPN will be able to talk to each other. Otherwise, each
client will only be alble to talk to the server, and will not “see” other clients in the network.

;user nobody
;group nobody

These two instructions are optional. If uncommented make the OpenVPN server daemon to run not
with current user or root priviliges, but only with user nobody’s. This is a very important feature of
OpenVPN: if a malicious remote user is able to gain access to the server he will not have more that
user nobody privileges so he will not be able to perform harmful operations to the server.
This are the most important settings that we are going to use. There are many more, allowing to
compress the network traffic, to assign to the clients fixed IP addresses, to make possible that when
a client logs in, also all the computers of her network are made part of the VPN, and others. Since
the goal of this chapter is only to give an OpenVPN overview, to understand the concept of tunneled
VPNs, we are not going to analyze in the details all the possibilities offered.

Client side
The client configuration file is very similar to the server’s, so we are only going to show the differences.

client

This instruction tells OpenVPN that this machine it’s a client of the TLS connection.

remote server.mycompany.com 1194

The clients know where the server is with this instruction. It is possible to specify DNS names, as in
the above line, or IP addresses. In contrast to what is done in the server configuration files there is no
port 1194 instruction, but the port number used for the connection is written here. It is necessary
to specify a proto tcp or proto udp instruction.

resolv-retry infinite

This declaration tells the client to try to resolve the server name for an infinite number of tries.
It is not necessary anymore to specify the network address (it is important only for the server) and
the Diffie-Hellman parameters. Obviously like in the server file we must specify the directory where
are located the CA public certificate, the client public certificate and its secret private key.
This is all is needed to set up the clients and the servers, we can now start the communication.

The VPN is working!

To start the VPN we just have to type openvpn server.conf on the server and openvpn client.conf
on the client. The server will stands by, waiting for the client, and the client will begin the TLS
transaction. Both machines will authenticate using their certificates and then the network is built!
Now the two (or more) machines are in the network 10.8.0.0, the server with address 10.8.0.1, the
client with a different one, for example 10.8.0.6. What we can do now? We can test some protocols
to see if they are correctly tunneled through the network, for example.
The first test is obviously a ping. On the client side we perform a ping 10.8.0.1 and see what
happens. The result is showed in figure 4.1. We see that the ping test is succesfully carried out: the
server answers to the pings and that the Time To Live (TTL) is 64, as if the server was just one hop
away; this shows us that the ICMP packets have been correctly tunneled through the SSL tunnel.

The next test is about HTTP. We start the Apache web server on the VPN server and then we
will check if the client can connect to it using a normal web browser. Once the server has been started
(this operation can differ depending on the operating system OpenVPN is running on) on the client

13
Figure 4.1: The first ping test of the SSL tunnel VPN

Figure 4.2: Apache web server test

14
side we put as URL the virtual private IP address of the server, again 10.8.0.1. If everything works
fine we should see the test page of the Apache daemon; in figure 4.2 we see the result.

We have tried the tunnel with an ICMP operation and with an HTTP transfer. We can now try
another protocol that lies in the Application layer of the TCP/IP stack: SSH. SSH is a protocol that
allows to securely connect two remote machines; if used properly, SSH alone could provide us a VPN.
I don’t want to enter in the details, but it’s possible to build an SSH tunnel and in that tunnel let
travel many protocols. The use of this kind of VPN is not straightforward though, simply because
SSH has not been built for that goal.
Going back to our test, we will now open a terminal in the client machine and try to establish a
connection to the remote VPN server, using its private address and not the public one. To do so we have
to start the SSH daemon on the server and then type on the client’s terminal ssh USERNAME@10.8.0.1.
The connection will be established and we will be asked USERNAME’s password. We type it and voila ,
we are in! A screenshot of this test is in figure 4.3

Figure 4.3: SSH connection test

Once we are connected we can do a simple ls to see the content of the home directory of the remote
server. Remember that since we only have user nobody privileges, we can’t do harmful operations on
the server.

15
Chapter 5

Security issues

5.1 Client side

Network and connection problems
Until now, we have said that a remote user with an SSL capable web browser can access the local
network; he will be showed a portal or will be tunneled into the remote network, giving the user an
interface to use network resources. There are some problems, though:

• Internal IP addresses: it is common, in a network environment, to use a NAT to separate

internal reserved addresses from those accessible from a computer external to the network. In
such a case, the IP addresses of the internal machines can’t be reached from the outside. If,
once we accessed the VPN through the web portal, there is any link pointing to an address
like 192.168.x.x we won’t be able to open it, because that address has no meaning outside the
internal network.

• Non fully-qualified machine names: an address like http://sales-server could be per-

fectly working inside the network, but outside the network, again, this has no meaning. This is
not a fully-qualified name, because it misses the references to the internal network.

• Fully-qualified names not DNS published: if we try to access the same server as before
but this time specyfing http://sales-server.mycompany.com we will get another error if this
address has never been published by the DNS server of the company. If nobody in the world
knows the existance of such an address it will be impossible for me to access it.

• Links built whitin active scripts: the same aforementioned problem can occour with links
that are built within an active script, like a JavaScript or a Flash plugin. In this case the link
could be meaningful inside the network but meaningless outside.

Because of this problems, we see that building an SSL VPN link it’s not just a question of trans-
lating http addresses in https ones, and establishing an SSL connection. Some network contents will
be likely to be unreachable. This happens with SSL portal VPNs, and we will soon understand why.
To solve this problem many solutions exists, due to the fact that there is not yet an SSL VPN
standard. I am going to list some of the possible solutions:

• Passing informations as a parameter: in this scheme, a VPN address will look like

https://SSL_VPN_name/page.html?RealLocation=InternalLocation

Probably we don’t like to send the request for the internal server in clear, so we can add encryp-
tion to the above techniques in this way:

https://SSL_VPN_name/page.html?RealLocation=EncryptedLocation

16
 • Modification of the URL: a similar technique is to add to the URL a string containing the
internal name of the wanted resource, like

https://SSL_VPN_name/InternalLocation/page.html

Or, if we want some encryption

https://SSL_VPN_name/EncryptedLocation/page.html

• Tunnell all as non-web: the first two methods works translating an address into another,
starting from a network-only valid address to an Internet valid one. These techniques may fail if
the translation engine of the SSL VPN solution cannot for some reason work properly. This can
happen with links built whitin a Flash plugin or a JavaScript, or when a web page redirects to
another one. In these cases the translation simply does not work. The solution is to tunnel all the
VPN traffic, implementing in practice an SSL full-tunnel VPN. All the traffic, web and non-web,
is tunneled through an SSL connection, so that now the user is in practice inside the network.
Now also non fully-qualifies names, internal IP addresses and non published DNS names make
sense for the user, because any user request will be tunneled and treated as a request coming
from inside the network.

Endpoint security
Another important problem for an SSL VPN involves endpoints security, as we already mentioned.
The intrinsic issue of enpoint security lies in the fact that SSL VPN has been created to allow
connections from virtually any place in the world with an Internet connection. This includes a lot of
vulnerable places, like public internet cafés, wi-fi spots, your friend’s computer. It is impossible to
guarantee a priori that such systems are secure, and it’s impossible to know in advance from which
computer in the world I would need to connect to my company’s network.
During any connection to the Internet there are a lot of data that represent a potential security
issue. To list the most important:

• browser cached pages;

• temporary files, such as viewed email attachments or browser-viewed pdf;

• form fields auto-completion;

• URLs auto-completion;

• cookies;

• history records;

• memorized username and password!

After an user has logged out of a public computer, the next user can know a lot of sensible informations
about what has been done, without the need of any particular hacker rootkit. This is a real problem
that could make the use of a complex SSL VPN implementation completely ineffective from the
confidentiality point of view.
There are many different solution and again the lack of an official standard leaves the software
houses free of implementing their own methods. Some typical are:

• Do nothing: it could seem impossible, but some SSL VPN products do not care about endpoint
security.

• Warn the user: extremely simple choice that could result ineffective in case of browser or oper-
ating system crash.

17
 • Use of the NOCACHE command: most browsers undertand this command and in consequence
do not store locally data. This trick does not solve the problem since the command NOCACHE
does not affect form fields and history, can slow down some applications and not every browser
can understand it.

• Erase all cached data: every time a session ends (this could happpen with an user log out action,
a period of inactivity, browser or computer crash, power losses, etc) the software wipe out all the
sensible data. This solution can be poorly effective in case of a sudden shutdown of the device.

• Using encrypted storage techniques: in this way also in case of a power down data can be hardly
readable from an unauthorized user. This solution does not protect data stored in the virtual
memory (swap file) of the operating system.

In the end: the stupid user

Every good network manager knows that the biggest danger to the network security problem is not
technical, but human: is the user. A neglectful user can do terrible damages to a well built system.
The main problem is when the user does not log out. Usually some timout system is present in
the system, but this can create some problems to the user, because after a period of inactivity he is
forced to log in another time. A very smart (dumb) user can use some trick to bypass this security
measure. It could, for example, use a very small program performing a ping command to a server or
refreshing a web page on a regular basis. The SSL VPN system detects some network activity and
never shuts down the connection.
The solutions are not simple, and should consider that the user will always have a new ace in the
hole to ruin your system. One possible solution makes use of non-intrusive timeouts. They consist
of a normal timeouting scheme, but giving the user a warning when the session is going to expire.
If the user does not react to the warning, the active session is closed after a relatively short time.
Another solution is called forced periodic re-authentication; with this method the user is forced to re-
authenticate periodically, no matter what she is doing. The third solution is based on ignoring phony
activities such as page refreshes. This solution requires to identify which are the activities that can
be defined as phony, an operation that can require a long time and eventually reduce the operations
an user can do.

The list could last forever

There is a thing that at the same time scare and hearten a network administrator: problems never
end! This means a lot of worries, but also a the guarantee that they will always have work to do.
In addition to the listed problems we can add virus and worm diffusion inside the VPN, the use
of spyware, keystroke loggers, and even video cameras aimed to an user’s computer! Furthermore, a
hacker who has gained control of an user’s host can bridge that host toward another network that he
controls. In this way the compromised device will be part of two different networks and the hacker
can have complete access to the network resources.
We could go on forever, there are thousands of different security problems, some that could com-
promise the whole network, some others that can only result in irrelevant information losses. There
are security issues on the client side and on the server side of the connection. Since there isn’t any
standard that has been fixed yet, it is very difficult to list all the problems, because obviously they are
strictly related to the specific implementation details. It is difficult as well to design countermeasures.

5.2 Server side

There are also problems concerning the server side. In this section we will discuss issues related to
both protecting the internal network from compromises made possible by the presence of the SSL
VPN, and protection of the SSL VPN itself.

18
SSL VPN server position
A security aware network is usually connected to the Internet through a DMZ. This gives us two
possible sites to place the SSL VPN server: inside the DMZ or inside the internal network.

If we place the VPN server inside the DMZ, the exterior firewall must open port 443 TCP for
SSL, or 1194 UDP if we use OpenVPN. In any case we need to open one more port than usual. This
architecture exposes our network to these risks:

• SSL keys: the keys needed to decrypt and encrypt data are stored in the DMZ, i.e. in an unsafe
place by definition. Furthermore in the DMZ travels uncrypted data. This exposes the network
to attackers performing sniffing.

• Exterior firewall bypass: in SSL tunnel VPN it is possible to tunnel inside the SSL tunnel
a lot of protocols (as we have seen in the OpenVPN example), also the ones that the exterior
firewall was supposed to block.

• Remote node used as a bridge: a compromised remote host can be exploited to serve as a
bridge to another network. The server cannot be aware that the requests are coming from an
unauthorized network rather than from an authorized client.

If we place the VPN server in the internal network we are exposed to other security problems:

• All firewalls bypass: the SSL tunnel this time will pass through the DMZ and end at the
SSL server inside the internal network; this means that either the exterior firewall or the firewall
between the DMZ and the internal network are useless, because any kind of protocol can be
tunneled through the tunnel and reach the internal server.

• IDSs in the DMZ are useless: the traffic in the DMZ is made of encrypted packets, so IDSs
working in the DMZ are useless, because they cannot analyze encrypted traffic.

• Exposure to DoS attacks: since network packets reach the internal network, it is possible to
a remote attacker to make trivial DoS attacks on the internal network, at least on the SSL VPN
server.

We can deduce that SSL tunnel VPN poses serious security issues, that are really difficult to solve,
since the inner problem is also the key element of this technology: the tunneling concept. Packets
travelling in the tunnel are safe, because they are encrypted, but so are viruses, worms or any other
malicious software.
An SSL portal VPN offers far less vulnerabilities, since the only thing to protect is the web server
that operates as reverse proxy. An SSL portal VPN, though, does not offer the same look-and-feel
of a tunneled network; in a portal VPN we cannot use private addresses, and we are forced to use
a web browser to access and operate into the internal network. As usual, we find that there is a
compromise between security and easiness of use. Depending on the practical case where the VPN is
to be installed, it is of great importance to choose the solution that best fits the needs.

19
Chapter 6

Conclusions

VPNs are a very powerful method to provide remote secure connectivity between a remote user and
a network or two far away networks, over an untrusted network. The VPN technology has become
of greater and greater importance with the growth and the capillar diffusion of the Internet, and the
growing request by companies of secure ways to connect remote sites or employess with the internal
network.
IPsec has been the traditional technology to implement a VPN. It is a technology that allows to
encrypt, authenticate, and check the integrity of IP packets and therefore it works at the Network
layer of the TCP/IP stack. IPsec works by encrypting and/or authenticating the payload (transport
mode) or the whole IP packet (tunnel mode). With time, IPsec has showed some problems, due to its
complexity and its need to work at strict contact with the operating system.
SSL is a technology to connect securely a client and a server, encrypting, authenticating and
checking the integrity of packets at the Session layer. SSL has many advantages compared with IPsec
in terms of flexibility and stability: every application can decide to use or not the SSL security features,
and plus this security protocol does not work at strict contact with the operating system. SSL has
been created to allow electronic commerce, but it has turned out to be really useful in a lot of different
situations. One of the most recent, and interesting, is the combination of the VPN concept and the
SSL technology.
The SSL VPN is going to become a more and more used technology, as well as the Internet diffusion
and related services will go on growing in number and quality. Nowadays it is possible to connect to
the Internet from virtually anywhere in the world, allowing a company’s employee to work from home
or while away. SSL VPN merges the semplicity of use of SSL with the high security offered by the
concept of a VPN.
On the technical side the SSL VPN it is not anything more than a normal SSL connection. There
are two ways to implement an SSL VPN: portal mode and tunnel mode. In the first mode the client
connects to a web site using an SSL channel and uses network resources by means of a portal. In the
second mode all the client network traffic is channeled through an SSL connection to the network,
allowing the user to work exactly as she was inside the remote network.
On the client side SSL can come out as a simple application plugin to be installed on the client
host and used by the user’s web browser. On the server side the main feauture is reverse proxying
that allows to translate remote requests into internal equivalent ones. After the requests are made,
the results are showed to the user using a normal web page in the portal mode, or using some applet
to give the user the illusion to operate right inside the network.
The main problem with the SSL VPN technology is that there is no official standard at the time
this report is being written and therefore all the solutions in the market vary greatly in terms of
features and level of security offered. Every single solution presents different problems because of the
different implementations and so it is necessary to pay a lot of attention on the design phase of the
VPN.
When deciding to use an SSL VPN it is necessary to spend some time to list the precise requirements
in terms of security and features wanted. After that there is the design step, when all the detail of the
solution are defined. It’s now time to build a prototype and to test it within a closed network; this

20
will help to identify the main security problems and to try to fix them. The next step is to deploy the
solution in the actual scenario and then there is the as important as often neglected managing phase.
The absence of a well defined standard makes of vital importance the management of the VPN, since
every solution is subject to different security problems.
OpenVPN is an open source implementation of an SSL tunnel VPN. It is a multiplatform program,
it’s easy to configure, and shows all th potentiality of the tunneling technology. SSL tunnel VPN are
very powerful because they allow a number of different protocols to travel through the tunnel, only
needing one port open. This is a very powerful possibility, but exposes our network to a number of
security issues; in the tunnel the network packets cannot be checked by firewalls or IDSs, because they
are encrypted. There are also some problems regarding the position of the SSL tunnel VPN server in
the network. The only possible solutions to these problems is to drop the SSL tunnel VPN architecture
and adopt the portal scheme, which is more secure but does not offer the same possibilities of the
tunnel.
Despite a few security problems, SSL VPNs are a very good alternative to IPsec based VPNs,
because of their greater flexibility and the easiness of installation and use, that result in a lower cost.
SSL VPNs are not intended to substitute IPsec VPNs, expecially when we want protection at Network
layer, but in many cases a Session layer protection offers more advantaged than drawbacks.

21
Bibliography

[1] NIST Special Publication 800-113 (Draft) — Guide to SSL VPNs.

[2] C. Hosner — OpenVPN and the SSL VPN revolution.

[3] N. Ferguson and B. Schneier — A Cryptographic Evaluation of IPsec.

[4] J. Steinberg and Timothy Speed — SSL VPN - Understanding, evaluating, and planning secure,
web-based remote access

[5] www.wikipedia.org

[6] www.openvpn.net

22