SSL VPN

Vittorio Picco

February 19, 2008

Contents

1 Introduction 2

2 VPN and SSL technologies 32.1 VPN overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 SSL overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 IPsec vs. SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Network and Transport layer security . . . . . . . . . . . . . . . . . . . . . . . 42.3.2 Relation with the operating system . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.3 IPsec is a complicated protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3.4 IPsec advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 SSL VPN details 73.1 SSL VPN as a black-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.1.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Technical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3.1 Reverse proxying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.2 Application translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.3 Network extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 OpenVPN 11

5 Security issues 165.1 Client side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Network and connection problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Endpoint security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17In the end: the stupid user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18The 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 companiescommunicate with their customers and relate to their employees. E-banking, e-commerce, teleworkingare just some of the many possibilities that the Web offers. As soon as all these services wheredeveloped it was clear that they were as powerful as useless if not implemented with a lot of attentionon the security aspects. In particular two technologies fully satisfied this needs, and made thempossible: 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 emailclients, 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 networksor PCs over an untrusted network like the Internet. Using a VPN a company can allow employees toconnect 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 traditionaluse of IPsec but with SSL. IPsec shows several drawbacks, due both to the OSI layer to which it isapplied 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 VirtualPrivate 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 generalway, expecially for what relates the security issues. Each product available in the market should beevaluated 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 computersecurity 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 anad-hoc link between, for example, two different plants or the CEO home and his office. The solution isto use already existing networks. Internet on the pros side has got its ubiquitousness and the very lowcost; the only cons is probably also the hardest to deal with: the complety unsafety. Packets travellingon the internet can be sniffed, manipulated, hijacked, deleted so that nobody can feel completely safeout there.

2.1 VPN overview

VPNs are a way to create a link between two routers or two PCs over the Internet, or, generallyspeaking, any untrusted network, encrypting and authenticating the packet’s flow, so that both endsof the communication can trust each other. VPN are usually used by companies to allow theiremployees to access the company’s internal network remotely. Another use of VPNs is to connect tworemote sites of the same company, to share common resources like file servers. The distinguishingcharacteristic of VPNs are not security or performance, but that they overlay other network(s) toprovide 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 securityfeatures, so we have a lot of other questions to anwser, like: how do we encrypt packets? how dowe authenticate them? how can we feel reasonably sure that they can’t be manipulated? The mostcommon 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 thecryptografic operations. IPsec protocols operate at the network layer, layer 3 of the OSI model. Theyallow 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 isnot. In this way all the routers along the path can read the source and destination address and thusperform the routing correctly.

In tunnel mode the whole IP packet is incapsulated in a brand new packet, whose source anddestination addresses are not anymore the one of the two ends of the communication, but the one ofthe first and last router. If somebody sniffs a packet, he can’t neither understand who are the actalsender and recipient of the message. On the other hand, this does not allow a host-to-host link, butonly 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 withresponsability for the management of a secure, encrypted, communication channel between a serverand a client. SSL is implemented in the major Web browsers. One of the most basic functions of SSLis message privacy. SSL can encrypt a session between a client and a server so that applications canexchange 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 theiridentities by exchanging certificates. All traffic between the SSL server and SSL client is encryptedusing a shared key and a negotiated encryption algorithm. This is all effectuated during the SSLhandshake, which occours at session initialization. Another feature of SSL protocol is that SSLwill ensure that messages between the sender and the receiver have not been tampered during thetransmission. 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 originalTCP/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 towhich 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 madeup 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 theflexibility, 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 whichapplication is sending the packets, no matter which TCP socket the packets are directed, they are allencrpyted and/or authenticated.

On the other hand, SSL operates at the session level. This could sound strange, because TCP/IPhas no session layer! In fact SSL operates in what is called a “secure session layer”, which lies betweenTransport and Application layers. This is a small modification of the classical TCP/IP layers, butallows to implement security in a better way. Why? To answer this question, we must briefly analyzethe behaviour of a security protocol when applied to a certain stack layer. Let’s consider the classical4 TCP/IP layers.

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

• Transport: at this layer the security policies are application independent and therefore wehave not the same flexibility as before, but we do not need to modify each application we wantto protect. The security protocol can be implemented, for example, as a plugin, with manyadvantages in terms of easiness of installation and use. We can consider SSL as operating atthis 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 levelallow 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 applicationhas created which packet, so all the traffic belonging to a specific IP address is controlled. Atthis 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 toencrypt all the information travelling on a network, including application data, IP and physicaladdresses. The problem is that since this layer handle physical links between two ends, it’snot a layer where is possible to create a VPN, because a VPN is, by definition, something thatoperates on an untusted network, and not on a physical link. If you can afford a direct connectionbetween your company site in Europe and the other one in Argentina you don’t have any needfor a VPN.

From this brief description we can understand how do security protocols work: the more youimplement it at a high level the more you will gain in flexibility but with a growing cost of usabilityand easiness of installation, and also protecting less informations; the more the security protocol isimplemented 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 ofcompanies has moved toward Transport (or Session) layer security for different reasons. A this layer wecan have more customization possibilities, and in particular we can protect in a different way differentTCP sockets. For example we can decide to encrypt the HTTP traffic but leaving uncrypted the FTPtraffic, and so on. It is true that at this level we cannot protect IP addresses, but this is not a highprice to pay: unless we provide authentication with IP there is a web portal that is the interface ofthe application proxy (located inside the internal trusted network): it is the proxy that operates withadministrative privileges.addresses (and nobody should do), an attacker performing IP spoofing on asystem secured at transport layer can only perform Denial of Service attacks. Describing IPsec, wehave also seen that protecting low level information like IP addresses need us to work at tight contactwith the Operating System, and this is discouraged. A transport (or session) layer application cancome 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 theOS 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 withthe hardware, like peripheral drivers; in Ring 1 there are some system tasks and so on. Usually, userapplications lie in Ring 3. The OS ring architecture states that applications running in a certain ringcannot 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 applicationswith far less privilieges. Let me state one point: the OS ring architecture is not something sacred or ofvital importance, but is a system that has been proved as secure and easy to maintain. If one choosesnot 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 Linuxone, or a MacOS one, since different kernels requires different IPsec implementations. Once the codesare written and inserted in the kernel you must be sure that 3 different implementations of the sameprotocols can talk to each other with no problems. Furthermore, in systems like Linux, subjected toperiodic kernel updates, we must guarantee that the protocol is able to work fine after every kernelupdate.

As a result IPsec results quite difficult to install and maintain, expecially in devices like mobilephones 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 protocolthey can be easily installed and configured, without the need to worry about the kernel. On thecontrary, updates of the kernel will not require a particular attention to be sure that SSL would stillwork. We cansee the difference between SSL and IPsec like the one between a normal program anda device driver. Managing drivers requires more attention than managing programs, right becausedrivers 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 simplythat 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 onlygame 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, bugscan be easily found and corrected, thus resulting in a higher security level. In contrast, IPsec wasdeveloped by a commitee and we know the maxim: “A camel is a horse designed by committee”. Theresulting protocol was something too large, even with too many functionalities than desired. The bestexample 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 differentmodes causes a high rise in the complexity of the protocol, with all the risks in term of securitywe just summarized. A protocol with only tunnel mode will have no more possibility to distinguishbetween host-to-host and gateway-to-gateway links, and this is probably a reasonable cost to pay ifthe 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 requirementfor SSL to work fine is that both ends support the SSL protocol. There could be some cases wherethe machines or the servers in a network are very old and can’t even run a browser, or simply nobodyhas 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 problembecause in large networks we may have a lot of applications, requiring many different ports. Everyapplication should then open an SSL communication with the other end, exchanging certificates andso on. This could result in quite a big overhead both in terms of network traffic and of work neededto configure all the applications.

The last inconvenient when using SSL is caused by packets drop. When a host receives a packetmanipulapted by an attacker, malformed or duplicated, he must drop it. With IPsec this happens atnetwork level, while with SSL the packet must travel through Data Link, Network and Transport layersand finally be rejected. This can cause a bigger computational effort in an SSL protected system, butit 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, constantlymaintained and updated protocol, that does not need difficult configuration and does not interferewith the operating system; it allows to define application layer policies to choose which applicationshould make use of the secure connection and which not. It does not work at kernel level, simplifyingthe installation and maintenance phases. SSL has been designed having in mind Internet based moneytransaction and secure exchange of data; probably in the 90’s Netscape didn’t realized that SSL couldalso be a very efficient way to implement a VPN. Long story short, the advent of the Internet era, ofa constantly increasing speed of the connections and the availabaility in almost every computer in theworld (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 useand 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 aVPN. 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 thenumber 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 managerthe possibility to fix problems also when he is not on-site.

• High availability and Scalability: high availability is the property for a network to workalso in the case of a device failure. This goal can be achieved setting up two parallel SSLconnection. There are two ways to manage them: in the active/passive mode one connectionis used to transfer the packets and the other one stands by; if the first connection fails, thesecond one becomes active. In the active/active solution there are two connections handling thenetwork traffic; this solution allows the same failure recovery feature as the previous, but, inaddition, it can provide scalability. Scalability is the ability to balance the network load on thetwo 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 featureis simply the possibility to customize the web site used to access the remote network. This isneeded 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 thepossibility 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 aVPN environment both client and server authentication are needed. Authentication can beachieved 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 agroup 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 useror group must use which authentication form.

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

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

• Endpoint security controls: since theoretically with SSL we can access network resourcesfrom anywhere in the world, we would like to be sure that the computer the user is runningis secure, or at least offers some security. Probably from public internet kiosks the antivirusinstalled is not updated: this represents a risk for the company network, therefore we shouldallow that user only a limited access to the internal resources. This is of particular concern withan 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 carriedthrough 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 encryptand decrypt packets, SSL VPN operations could result slow. This problem affects in particularthe SSL VPN server, that by definition must handle many different SSL connections. To avoidserver overload the SSL operation can be done by external cards connected to the server or by adedicated computer connected to the network. In both cases the CPU load needed to performthe cryptografic operations is left to the external components, so that the server can manage thenetwork traffic.

This very long list of features shows clearly that any implementation of an SSL VPN can varygreatly depending on the particular requests of the VPN users. Before building any SSL VPN it isof great importance to understand the needs of the company, and write a precise authentication andaccess 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 therequests for some services come from the managers, the employees, in general from the people thatwill use the network. The goal of the network manager is to collect all the requests and then to choosethe best technical solution to satisfy all the requests. Usually there is a compromise to make betweensecurity and easiness of use. This consideration is important because tells us that is important toknow 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 standardSSL connection to a Web site to securely access multiple network services. The site accessed istypically called a portal because it has a single page that leads to many other resources. SSLportal VPNs act as transport-layer VPNs that work over a single network port, namely theTCP port for SSL-protected HTTP (443)”. An user wanting to access such a VPN needs a webbrowser able to handle an SSL connection. He will connect to the portal, and through the portalhe will access the network resources, like files in file servers or company email, or internal webpages, or everything that can be channeled through a web page. SSL portal VPNs can be usedfrom any computer in the world that have a web browser SSL enabled. In such a VPN we don’thave internal IP addresses, but all internal network references are translated by the portal to beaccessible also from outside.

It is important to understand that the even though the user acess a web page, and networkservices are channeled through web pages, it does not mean that an SSL VPN is a link betweenapplications. It is a VPN implementation, it works at those secure session layer added to theTCP/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 secureapplication level protocols. The application’s data are encapsulated and sent through a securesession 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, butjust 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 thereis an SSL connection between the remote user and the local network, and inside this tunnel aretravelling a number of different application protocols. This means that the user does not need aweb 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 exclusivelyHTTP traffic, but every kind of protocol. It is still possible to use a browser, but there must besome 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 weare going to take a look to which are the technical features, called functions that allow us to implementan 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 toget a service acts as a proxy: it receives the request of the user and on his behalf retrieves the dataor makes a request to the remote, trusted network. The SSL connection is established between theuser’s browser and the remote proxy, that must therefore encrypt and decrypt entering and leavingdata. The term reverse is due to the fact that usually a proxy receives requests from a private networkand forward them to the Internet; in this case the proxy receives requests from the outside world andtranslates them into internal requests. The user would not need to configure any HTTP or SOCKSproxy 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 toconvert one application protocol into another, to make it available in a web browser. One example issimply the web mail. With web mail you don’t need an e-mail client to access a POP server, but youcan 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 VPNyou can connect to the secure access web page, and then browse the files you’re interested to in thecompany 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 atyour disposal. As a good network manager you always think about the health of your network, sonow you want to ping your company’s file server to see if it’s still alive. If you built an SSL portalVPN, what you have to do is to access the portal web page, authenticate as the network manager andthen you’ll be showed the portal. Using the browser you will click on the button “Ping test” that youput in the portal web page; the other end of the communication will receive your request as a HTTPrequest, but understands that you want to perform a ping test. Your HTTP request is translated intoan ICMP request toward the file server. The result of the ICMP ping operation is translated again inthe form of a text that will show up again in the portal, letting you know that the file server is fineand 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 networkremotely. From the user’s point of view nothing changes from being physically inside the trustednetwork. This is a classic function provided by an SSL tunnel VPN. The network’s services aretunneled through the SSL connection and received by your browser that, with the help of a Javascript interpreter or any other active contents handler, will show the user an interface; using thisinterface the user can use the company’s network services exactly as he was inside it. The activecontent agent is required to ask the internal network administrative privileges. In an SSL tunnel VPNthe 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 toperform the same ping test. If you built an SSL tunnel VPN you log in the system with a web browseror another application, authenticating as the network manager. This time your laptop is actually apart of the remote network with a virtual internal address. If you know that the file server has got10.8.0.34 IP address you can just open a terminal and type ping 10.8.0.34. You will get the pingoperation results exactly as if you were inside the network. We see that it is not important that weuse a terminal, or a plugin of your web browser that emulates a terminal: the important thing is thatthere 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. OpenVPNis available for different operating systems like Linux, Windows, MacOS X, FreeBSD. It offers thesame 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, inparticular in the case of different operating systems. OpenVPN supports different authenticationtechniques and the access control policy can be created on a per-user or per-group basis. The mostimportant characteristic of OpenVPN is its easiness of configuration and use. Both in Windows andLinux it can work as a simple terminal program, which only need a configuration file to be properlyset 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 kernelintervention. 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. OpenVPNworks well also in bridged networks, and in such cases it makes use of dev tap. These two devices areavailable 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 creationof tunnels.

Explaining the features of OpenVPN can be quite long and tiring. To avoid this, we are nowgoing to see a practical example that will show how to install and set up a simple VPN between tworemote hosts; the client and the server authenticate each other by means of X.509 certificates. Theexample relates to the Linux operating system, but for Windows only a minimum number of changesare 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 tomanage 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 theclient.

Certificates and keys creation

The first thing we need to do is to create the Certification Authority (CA), that will sign both serverand client certificates. This operation can be done on any machine of the network. Once in theOpenVPN 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 fieldswith 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 theclients. If we decide to use X.509 certificates OpenVPN force us to authenticate both the serverand the client. This is an optional operation of the TLS protocol, that usually authenticates onlythe server, but OpenVPN makes it compulsory for security reasons. Since at the end the client willbe tunneled into the remote network, we must be sure that he really is who he claims to be. Theinstruction is:

./build-key CLIENT_NAME

This instruction must be replicated for each client we want to be able to access the network. At theend 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 theprivate keys that are needed. Now we have to move the files to their recipient, being careful whenmoving the secret keys. Every host must have its X.509 certificate, its secret private key and thethe CA certificate. The server must also have the file with the parameters for the Diffie-Hellmanalgorithm.

Configuration files

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

Server side

port 1194 ;or any otherproto udp ;or tcp

These are some of the most important directives for the server. OpenVPN official port is the UDP1194; if for any reason we cannot use that port or even the UDP protocol, we can change the portnumber (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 (bridgednetwork).

ca /etc/openvpn/keys/ca.crtcert /etc/openvpn/keys/server.crtkey /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 machinewill 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 serverwill automatically take the first address as its own. It is very important to note that this is an addressbelonging to the set of IANA private addresses. This is because we are going to create an SSL tunnelVPN, hence we will have an internal address exactly as if we were inside the network. Both clientsand 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, eachclient 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 notwith current user or root priviliges, but only with user nobody’s. This is a very important feature ofOpenVPN: if a malicious remote user is able to gain access to the server he will not have more thatuser 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 tocompress the network traffic, to assign to the clients fixed IP addresses, to make possible that whena client logs in, also all the computers of her network are made part of the VPN, and others. Sincethe goal of this chapter is only to give an OpenVPN overview, to understand the concept of tunneledVPNs, 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 inthe above line, or IP addresses. In contrast to what is done in the server configuration files there is noport 1194 instruction, but the port number used for the connection is written here. It is necessaryto 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 whereare 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.confon the client. The server will stands by, waiting for the client, and the client will begin the TLStransaction. 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, theclient with a different one, for example 10.8.0.6. What we can do now? We can test some protocolsto 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 whathappens. The result is showed in figure 4.1. We see that the ping test is succesfully carried out: theserver answers to the pings and that the Time To Live (TTL) is 64, as if the server was just one hopaway; 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 wewill 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 worksfine 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 tryanother protocol that lies in the Application layer of the TCP/IP stack: SSH. SSH is a protocol thatallows 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 lettravel many protocols. The use of this kind of VPN is not straightforward though, simply becauseSSH 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 aconnection to the remote VPN server, using its private address and not the public one. To do so we haveto 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 remoteserver. Remember that since we only have user nobody privileges, we can’t do harmful operations onthe 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 localnetwork; he will be showed a portal or will be tunneled into the remote network, giving the user aninterface to use network resources. There are some problems, though:

• Internal IP addresses: it is common, in a network environment, to use a NAT to separateinternal reserved addresses from those accessible from a computer external to the network. Insuch 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 addresslike 192.168.x.x we won’t be able to open it, because that address has no meaning outside theinternal 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 isnot 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 beforebut this time specyfing http://sales-server.mycompany.com we will get another error if thisaddress has never been published by the DNS server of the company. If nobody in the worldknows 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 linksthat are built within an active script, like a JavaScript or a Flash plugin. In this case the linkcould 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 willbe 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 VPNstandard. 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 theinternal 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 ifthe translation engine of the SSL VPN solution cannot for some reason work properly. This canhappen with links built whitin a Flash plugin or a JavaScript, or when a web page redirects toanother one. In these cases the translation simply does not work. The solution is to tunnel all theVPN 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 makesense for the user, because any user request will be tunneled and treated as a request comingfrom 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 ofvulnerable places, like public internet cafes, wi-fi spots, your friend’s computer. It is impossible toguarantee a priori that such systems are secure, and it’s impossible to know in advance from whichcomputer 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 securityissue. 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 informationsabout what has been done, without the need of any particular hacker rootkit. This is a real problemthat could make the use of a complex SSL VPN implementation completely ineffective from theconfidentiality point of view.

There are many different solution and again the lack of an official standard leaves the softwarehouses free of implementing their own methods. Some typical are:

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

• 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 consequencedo not store locally data. This trick does not solve the problem since the command NOCACHEdoes not affect form fields and history, can slow down some applications and not every browsercan 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 thesensible 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 hardlyreadable from an unauthorized user. This solution does not protect data stored in the virtualmemory (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 nottechnical, 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 inthe system, but this can create some problems to the user, because after a period of inactivity he isforced to log in another time. A very smart (dumb) user can use some trick to bypass this securitymeasure. It could, for example, use a very small program performing a ping command to a server orrefreshing a web page on a regular basis. The SSL VPN system detects some network activity andnever shuts down the connection.

The solutions are not simple, and should consider that the user will always have a new ace in thehole to ruin your system. One possible solution makes use of non-intrusive timeouts. They consistof 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 phonyactivities such as page refreshes. This solution requires to identify which are the activities that canbe defined as phony, an operation that can require a long time and eventually reduce the operationsan user can do.

The list could last forever

There is a thing that at the same time scare and hearten a network administrator: problems neverend! 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 useof spyware, keystroke loggers, and even video cameras aimed to an user’s computer! Furthermore, ahacker who has gained control of an user’s host can bridge that host toward another network that hecontrols. In this way the compromised device will be part of two different networks and the hackercan 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. Thereare security issues on the client side and on the server side of the connection. Since there isn’t anystandard that has been fixed yet, it is very difficult to list all the problems, because obviously they arestrictly 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 toboth protecting the internal network from compromises made possible by the presence of the SSLVPN, 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 twopossible 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 forSSL, or 1194 UDP if we use OpenVPN. In any case we need to open one more port than usual. Thisarchitecture 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 unsafeplace by definition. Furthermore in the DMZ travels uncrypted data. This exposes the networkto attackers performing sniffing.

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

• Remote node used as a bridge: a compromised remote host can be exploited to serve as abridge to another network. The server cannot be aware that the requests are coming from anunauthorized 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 theSSL server inside the internal network; this means that either the exterior firewall or the firewallbetween the DMZ and the internal network are useless, because any kind of protocol can betunneled 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 IDSsworking 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 toa remote attacker to make trivial DoS attacks on the internal network, at least on the SSL VPNserver.

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. Packetstravelling in the tunnel are safe, because they are encrypted, but so are viruses, worms or any othermalicious software.

An SSL portal VPN offers far less vulnerabilities, since the only thing to protect is the web serverthat operates as reverse proxy. An SSL portal VPN, though, does not offer the same look-and-feelof a tunneled network; in a portal VPN we cannot use private addresses, and we are forced to usea web browser to access and operate into the internal network. As usual, we find that there is acompromise between security and easiness of use. Depending on the practical case where the VPN isto 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 anda network or two far away networks, over an untrusted network. The VPN technology has becomeof greater and greater importance with the growth and the capillar diffusion of the Internet, and thegrowing request by companies of secure ways to connect remote sites or employess with the internalnetwork.

IPsec has been the traditional technology to implement a VPN. It is a technology that allows toencrypt, authenticate, and check the integrity of IP packets and therefore it works at the Networklayer of the TCP/IP stack. IPsec works by encrypting and/or authenticating the payload (transportmode) or the whole IP packet (tunnel mode). With time, IPsec has showed some problems, due to itscomplexity 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 andchecking the integrity of packets at the Session layer. SSL has many advantages compared with IPsecin 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 hasbeen created to allow electronic commerce, but it has turned out to be really useful in a lot of differentsituations. One of the most recent, and interesting, is the combination of the VPN concept and theSSL technology.

The SSL VPN is going to become a more and more used technology, as well as the Internet diffusionand related services will go on growing in number and quality. Nowadays it is possible to connect tothe Internet from virtually anywhere in the world, allowing a company’s employee to work from homeor while away. SSL VPN merges the semplicity of use of SSL with the high security offered by theconcept of a VPN.

On the technical side the SSL VPN it is not anything more than a normal SSL connection. Thereare two ways to implement an SSL VPN: portal mode and tunnel mode. In the first mode the clientconnects to a web site using an SSL channel and uses network resources by means of a portal. In thesecond 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 clienthost and used by the user’s web browser. On the server side the main feauture is reverse proxyingthat 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 appletto 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 timethis report is being written and therefore all the solutions in the market vary greatly in terms offeatures and level of security offered. Every single solution presents different problems because of thedifferent implementations and so it is necessary to pay a lot of attention on the design phase of theVPN.

When deciding to use an SSL VPN it is necessary to spend some time to list the precise requirementsin terms of security and features wanted. After that there is the design step, when all the detail of thesolution 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 thesolution 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, sinceevery 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 arevery powerful because they allow a number of different protocols to travel through the tunnel, onlyneeding one port open. This is a very powerful possibility, but exposes our network to a number ofsecurity issues; in the tunnel the network packets cannot be checked by firewalls or IDSs, because theyare encrypted. There are also some problems regarding the position of the SSL tunnel VPN server inthe network. The only possible solutions to these problems is to drop the SSL tunnel VPN architectureand adopt the portal scheme, which is more secure but does not offer the same possibilities of thetunnel.

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 Networklayer, 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