diploma project zcov - a zero-con g solution for...

University �Politehnica� of Bucharest

Faculty of Automatic Control and Computer Science,

Computer Science Department

DIPLOMA PROJECT

ZCOV - A Zero-con�g Solution forOpenVPN

Scienti�c Adviser: Author:

As. Drd. Ing. R zvan Deaconescu Andreea Diana Luc u

Bucharest, 2009

Acknoledgements

I would like to thank my supervisor, R zvan Deaconescu, for all the support he has given methroughout the year. Not only was his advice invaluable, but his enthusiasm and genuine

interest in this project was admirable and motivating.

I would also like to thank my project collegue, Oana Com nici.

Motto

"You should want the highest form of technology and security for your privacy information,and frankly, we don't have that today." (Richard A. Clarke, former chief counter-terrorism

adviser on the U.S. National Security Council)

Abstract

Ever since data exchange across computers situated in di�erent location became possible, theneed of privacy and security arose. People situated in di�erent areas of the globe want tosimulate that they are actually in the same LAN - this insured that no one from the exteriorcould see the data being exchanged. The result: VPNs. This paper will present a project thataims to o�er a safe and simple way of creating and managing virtual private networks.

ii

Contents

Acknowledgements i

Abstract ii

1 Introduction 11.1 The Context and the Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 VPNs in a Nutshell 32.1 Broadband Internet Access and VPNs . . . . . . . . . . . . . . . . . . . . . . . . 32.2 VPN Concepts - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Tunneling and Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Tunneling Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3.1 A Proposed Standard for Tunneling . . . . . . . . . . . . . . . . . . . . . 52.3.2 Tunneling Protocols Implemented in OSI Layer 2 . . . . . . . . . . . . . . 52.3.3 Tunneling Protocols Implemented in OSI Layer 3 . . . . . . . . . . . . . . 62.3.4 Tunneling Protocols Implemented in OSI Layer 4 . . . . . . . . . . . . . . 7

3 VPN Security 83.1 Privacy - Tra�c Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1.1 Symmetric Encryption and Pre-Shared Keys . . . . . . . . . . . . . . . . 83.1.2 Asymmetric Encryption with SSL/TLS . . . . . . . . . . . . . . . . . . . 9

3.2 SSL/TLS Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.1 SSL/TLS Certi�cates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Trusted Certi�cates and Self-signed Certi�cates . . . . . . . . . . . . . . . 93.2.3 SSL/TSL and VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 ZCOV - VPN Manager 114.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Speci�cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2.1 The Security Component . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2 Persistency and Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.3 Network Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.4 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5 OpenVPN - a Simple Tunneling Solution 145.1 Networking with OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.2 OpenVpn Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.3 Con�guration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.4 Advantages of OpenVpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.5 OpenVpn Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

iii

CONTENTS iv

6 ZCOV - Implementation Details 196.1 User Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.1.1 Available commands and usage . . . . . . . . . . . . . . . . . . . . . . . . 196.1.2 GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.2 The Architecture of the Application . . . . . . . . . . . . . . . . . . . . . . . . . 206.2.1 Data structures and meaning . . . . . . . . . . . . . . . . . . . . . . . . . 206.2.2 ZCOV Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.3 Interactions with the database . . . . . . . . . . . . . . . . . . . . . . . . 256.2.4 ZCOV Hooks in the OpenVPN Code . . . . . . . . . . . . . . . . . . . . . 266.2.5 ZCOV Error Handling and Debugging . . . . . . . . . . . . . . . . . . . . 28

6.3 Development and Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7 ZCOV - the Protocol 337.1 Policies and Security Considerationa . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Protocol API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

7.2.1 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2.2 The Work�ow for a ZCOV Message . . . . . . . . . . . . . . . . . . . . . 34

7.3 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.3.1 Create/Delete network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.3.2 Join/Leave Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.3.3 Go-online/Go-o�ine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387.3.4 Kick/Ban Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3.5 Get/Set Nick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3.6 Querying Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407.3.7 Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.4 Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8 Conclusion and Further improvements 438.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438.2 Further improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

List of Figures

2.1 VPN - Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 VPN - Tunnel Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 ZCOV - Manage Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2 ZCOV Persistency and Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 OpenVpn Message Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6.1 ZCOV Command Line Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 206.2 Extended Client Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.3 Extended Server Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.4 ZCOV Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.5 ZCOV Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266.6 Building Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316.7 Testing Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1 ZCOV Message Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357.2 Client Initialization Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

v

Notations and Abbreviations

CA � Certi�care AuthorityCLI � Command Line InterfaceCRL � Certi�cate Revocation ListHMAC � Hash Message Authentication CodeIEC � International Electronical CommisionISO � International Organization for StandardizationLAN � local area networkLZO � Lempel-Ziv-OberhumerOSI � Open Systems InterconnectionPDUs � Protocol Data UnitsPKI � Public Key InfrastructureUML � Uni�ed Modeling LanguageVPN � Virtual Private NetworkW3C � World Wide Web Consortion - W3ZCOV � Zero-con�g OpenVPN

vi

Chapter 1

Introduction

1.1 The Context and the Purpose

During the Second World War people became more aware of the value of information. Itbecame clear that information could be used as a weapon. Who had access to information,had advantages over their opponents. In that context, information exchange became a majorconcert for the every military department. The US government invested a lot of founds forfounding a secure way of exchanging information across various location on the globe. Todaywe can see the result: the Internet as we know it.

Soon, new demands emerged. First, privacy: information exchanged between two users in theInternet wanted to be invisible for an external user. Secondly, security: no other user shouldbe able to see and understand the information being exchanged. These new requirementsdetermined the apparition and development of virtual private networks.

So we are interested in a solution for easily linking users from di�erent areas of the globe sothat they could exchange information in a secure and private environment with no need forcomplicated con�gurations and settings. This is the purpose of this project. ZCOV is anapplication developed for creating and managing virtual private networks, providing users aneasy to use interface and a lot of facilities to ensure security and privacy.

1.2 Summary

Chapter 2 of this paper present the state of the art: how can we use the Internet as a privateenvironment? What are the o�cial standards? Are the any similar solutions?

Chapter 3 will show how we can obtain one of the fundamental demands: privacy and security.

Chapter 4 will present the complete functional speci�cations for ZCOV: what do we want toobtain? How do we want it to work?

In chapter 5 we present the basic infrastructure used for ZCOV: OpenVPN, an open sourcetunneling solution.

Chapter 6 will describe the architecture of the application: the user interaction, the server-client model being used and the persistency support. Also, we will present how all of thesecomponents work together.

1

CHAPTER 1. INTRODUCTION 2

Chapter 7 will describe the protocol user for attaining the desired goals: what kind of messagesdoes the server and the client exchange and in what sequence.

Finally, chapter 8 will present how the application was tested and the results obtained andchapter 9 will present the conclusions and several ideal for further improvements.

So this paper describes a new solution for creating virtual private networks. What makes itunique? First, it is an open-source solution. Secondly: it is zero-con�g (it does not require anywork to be done by the regular user). Finally: it has strong privacy and security features: it isdeveloped on top of the only tunneling solution that uses SSL: OpenVPN.

Chapter 2

VPNs in a Nutshell

2.1 Broadband Internet Access and VPNs

In former times, information exchange between branches of a company was mainly done by mail,telephone, and later by fax. But today there are some major challenges for modern companies:

• The general acceleration of business processes and the rising need for fast, �exible infor-mation exchange between all branches of a company has made old-fashioned mail andeven fax services appear too slow for modern requirements.

• Technologies like Groupware, Customer Relationship Management (CRM), and EnterpriseResource Planning (ERP) are used to ensure productive teamwork and every employee isexpected to cooperate.

• Almost every enterprise has several branches in di�erent locations and often �eld andhome workers. All of these must be enabled to participate in the internal informationexchange without delays.

• All computer networks have to ful�ll security standards to high levels to ensure dataintegrity, authenticity, and stability.

These four factors have led to the need of sophisticated networking solutions between a com-pany's o�ces all over the world. With computer networks connecting all desktops within asingle location, the need for connections between the sites has become more and more urgent.

In mid 1990s, the rise of the Internet and the increase of speed for cheap Internet connectionspaved the way for new technologies. Many developers, administrators, and, last but not theleast, managers had discovered that there might be better solutions than spending severalhundreds of dollars, if not thousands of dollars, on dedicated and dial-up access lines.

The idea was to use the Internet for communication between branches and at the same timeensure safety and secrecy of the data transferred. In short: providing secure connections betweenenterprise branches via low-cost lines using the Internet. This is a very basic description of whatVPNs are all about.

A virtual private network (VPN) is a computer network in which some of the links betweennodes are carried by open connections or virtual circuits in some larger networks, such as theInternet, as opposed to running across a single private network. The Link Layer 1 protocols ofthe virtual network are said to be tunneled through the transport network.

One common application is to secure communications through the public Internet, but a VPNdoes not need to have explicit security features such as authentication or content encryption.

3

CHAPTER 2. VPNS IN A NUTSHELL 4

Figure 2.1: VPN - Description

For example, VPNs can also be used to separate the tra�c of di�erent user communities overan underlying network with strong security features, or to provide access to a network viacustomized or private routing mechanisms.

A VPN is:

• Virtual - there is no real direct network connection between the two (or more) commu-nication partners, but only a virtual connection provided by VPN Software, realizednormally over public Internet connections.

• Private - only the members of the company connected by the VPN Software are allowedto read the data transferred.

2.2 VPN Concepts - Overview

2.2.1 Tunneling and Overhead

A network packet consists of two parts: header and data. The header is a sort of labelcontaining metadata on sender, recipient, and administrative information for the transfer. Onthe networking level of an Ethernet1 network, these packets are called frames.

In the context of the Internet Protocol2 these packets are called datagrams, Internet datagrams,IP datagrams, or simply packets.

VPN technology often is called tunneling, because the data in a VPN connection is protectedfrom the Internet as the walls of a road or rail tunnel protect the tra�c in the tunnel from themasses of stone of the mountain above. The VPN software in the locations A and B encrypts(lock) and decrypts (unlock) the data and sends it through the tunnel. Like cars or trains in atunnel, the data cannot go anywhere else but the other tunnel endpoint.

The following are put together and wrapped into one new package:

• Tunnel information - like the address of the other endpoint

• Encryption data and methods

• The original IP packet (or network frame)

1Ethernet is a family of frame-based computer-networking technologies for LANs. The name comes from thephysical concept of the ether. It de�nes a number of wiring and signaling standards for the Physical Layer ofthe OSI networking model, through means of network access at the Media Access Control (MAC) /Data LinkLayer, and a common addressing format.

2Internet is the procol used in the TCP/IP networking model for data communication accross a packetswitched internetwork.


The new package is then sent to the other tunnel endpoint. The payload of this package nowholds the complete IP packet (or network frame), but in encrypted form and thus not readablefor anyone not possessing the right key. The new header of the packet simply contains theaddresses of sender and recipient and other metadata necessary for and provided by the VPNsoftware used.

The bellow picture describes the data being put together into a package.

Figure 2.2: VPN - Tunnel Data

The amount of data sent grows during the process of wrapping. Depending on the VPNsoftware used, this so called overhead can become a very important factor. The overhead is thedi�erence between net data sent to the tunnel software and gross data sent through the tunnelby the VPN software. If a �le of 1 MB is sent from user A to user B, and this �le causes 1.5 MBtra�c in the tunnel, then the overhead would be 50%, a very high level. The overhead causedby the VPN software depends on the amount of organizational data and the encryption used.

Whereas the �rst depends only on the VPN software used, the latter is simply a matter ofchoice between security and speed. In other words, the better the encryption you use, the moreoverhead you will produce. Speed versus security is your choice.

2.3 Tunneling Protocols

2.3.1 A Proposed Standard for Tunneling

TheGeneral Routing Encapsulation (GRE) provides a standard for tunneling data, whichwas de�ned in 1994 in Request for Comments (RFCs) 1701 and 1702. Perhaps, because thisde�nition is not a protocol de�nition, but more or less a standard proposal on how to tunneldata, this implementation has found its way into many devices and become the basis for otherprotocols.

The concept of GRE is pretty simple. A protocol header and a delivery header are added tothe original packet and its payload is encapsulated in the new packet. No encryption is done.The advantage of this model are almost obvious: the simplicity o�ers many possibilities, thetransparency enables administrators and routers to look inside the packets and pass decisionsbased on the type of payload sent. By doing so, special applications can be privileged.

2.3.2 Tunneling Protocols Implemented in OSI Layer 2

Encapsulating packages on the OSI Layer 2 has a signi�cant advantage: the tunnel is ableto transfer non-IP protocols. IP is a standard used widely in the Internet and in Ethernet


networks. However, there are di�erent standards too. Netware Systems, for example, usesthe Internetwork Packet Exchange (IPX) protocol to communicate.

VPN technologies residing in Layer 2 can theoretically tunnel any kind of packet. In most cases,a virtual Point-to-Point Protocol (PPP) device is established which is used to connect tothe other tunnel endpoint. (A PPP device is normally used for modem or DSL connections.)

Four well-known Layer 2 VPN technologies, which are de�ned by RFCs, use encryption methodsand provide user authentication: Point to Point Tunneling Protocol (PPTP), Layer 2Forwarding (L2F), Layer 2 Tunneling Protocol (L2TP), Layer 2 Security Protocol(L2Sec).

Some distinguishing factors between the mentioned systems and protocols are:

• Availability of authentication mechanisms

• Support for advanced networking features like Network Address Translation (NAT)1

• Dynamic allocation of IP addresses for tunnel partners in dial-up mode

• Support for Public Key Infrastructures (PKI)2


IPsec is probably the most wide-spread tunneling technology. In fact, it is rather a set ofprotocols, standards, and mechanisms than a single technology. The wide range of de�nitions,speci�cations, and protocols are already the main disadvantages about IPsec. It is a complextechnology with many di�erent implementations and many security loopholes.

IPsec was a compromise accepted by a commission and therefore is something like a leastcommon denominator agreed upon. This means that IPsec can be used in many di�erentsetups and environments, ensuring compatibility, but almost no aspect of it o�ers the bestpossible solution.

IPsec was developed as an Internet Security Standard on Layer 3, and has been standardizedby the Internet Engineering Task Force (IETF)3 since 1995.

IPsec can be used to encapsulate any tra�c of application layers, but no tra�c of lower networklayers. Neither network frames, IPX packets, nor broadcast messages can be transferred, andnetwork address translation is only possible with restrictions.

Nevertheless, IPsec can use a variety of encryption mechanisms, authentication protocols, andother security associations. IPsec software exists for almost every platform, and compatibilitywith the implementation of other manufacturers is secured in most cases even though there aresigni�cant problems resulting from proprietary extensions.

The main advantage of IPsec is the fact that it is being used everywhere. An administratorcan choose from an abundant number of hardware devices and software implementations to

1Network address translation (NAT) is the process of modifying network address information in datagrampacket headers while in transit across a tra�c routing deviceÂ for the purpose of remapping a given IP addressspace into another.

2The Public Key Infrastructure (PKI) is a set of hardware, software, people, policies, and procedures neededto create, manage, store, distribute, and revoke digital certi�cates. A PKI binds a public key to a userâ��sidentity by using a certi�cate authority (CA). The user identity must be unique for each CA. The PKI role thatassures this binding is called the Registration Authority (RA). For each user, the user identity, the public key,their binding, validity conditions and other attributes are made unforgettable in public key certi�cates issuedby the CA.

3The Internet Engineering Task Force (IETF) develops and promotes Internet standards, cooperating closelywith the W3CÂ and ISO/IEC standard bodies and dealing in particular with standards of the TCP/IP andInternet protocol suite. It is an open standards organization, with no formal membership or membershiprequirements.


provide his or her networks with a secure tunnel. IPSecâ��s security model is probably themost complex of all existing VPN solutions.


It is also possible to establish VPN tunnels only on the application layer. Secure SocketsLayer (SSL) and Transport Layer Security(TLS) solutions follow this approach. The usercan access the VPN network of a company through a browser connection between his or herclient and the VPN server in the enterprise. A connection is simply started by logging into anHTTPS-secured website with a browser.

Meanwhile, there are several promising products available, like SSL-Explorer from http://3sp.com/showSslExplorer.do, and products like these o�er great �exibility combined with strongsecurity and easy setup. Using the secure connection the browser o�ers, users can connectnetwork drives and access services in the remote network. Security is achieved by encryptingtra�c using SSL/TLS mechanisms, which have proven to be very reliable and are permanentlyimproved and tested.

http://3sp.com/showSslExplorer.do

http://3sp.com/showSslExplorer.do

Chapter 3

VPN Security

IT security and hence also VPN security is best described by three goals that have to beattained:

• Privacy (Con�dentiality): The data transferred should only be available to the autho-rized.

• Reliability (Integrity): The data transferred must not be changed between sender andreceiver.

• Availability: The data transferred must be available when needed.

All of these goals have to be achieved by using reliable software, hardware, Internet serviceproviders, and security policies. A security policy de�nes responsibilities, standard proce-dures, and disaster management and recovery scenarios to be prepared for the worst. Under-standing maximum damage and the costs of the worst possible catastrophe can give an idea ofhow much e�ort has to be spent in security issues.

3.1 Privacy - Tra�c Encryption

Often passwords or encryption keys are used to encrypt data.

A major danger for VPNs are so-called man-in-the-middle attacks, also known as eaves-dropping. In this scenario, a hacker intercepts all data tra�c between sender and receiver,copies it and forwards it to its true destination. Neither sender nor receiver would notice thatthe data is being intercepted. The man-in-the-middle can store, copy, analyze, and perhapseven modify the captured tra�c. This is possible if the attacker can intercept and decrypt thekeys while they are being used for encryption.

There are several ways in which keys can be shared between peers in order to ensure a higherlevel of privacy and security.

3.1.1 Symmetric Encryption and Pre-Shared Keys

If both sides use the same key to encrypt and decrypt data, this is called symmetric encryp-tion. The encryption key has to be put on all machines that are supposed to take part in theVPN connection.

8

CHAPTER 3. VPN SECURITY 9

Anybody who has this key can decrypt the tra�c. If an attacker gets hold of this key, he or shecan decrypt all tra�c and compromise all systems taking part in the VPN, until all systemsare supplied with another key.

Furthermore, such a static, pre-shared key can be guessed, deciphered, or hacked by brute-forceattacks. It is merely a matter of time for an attacker to �nd out the key and to read, or evenworse, change the data.

With classical VPNs that use symmetric keying, there are several layers of authentication,exchange of encryption keys, and encryption/decryption. The following are the �rst three stepsof VPNs with symmetric encryption:

• The partners have to authenticate each other.

• They have to agree on the encryption methods.

• Then they have to agree on the key exchange methods used.

This is why VPN technology is often known as complex and di�cult.

3.1.2 Asymmetric Encryption with SSL/TLS

SSL/TLS uses one of the best encryption technologies called asymmetric encryption toensure the identity of the VPN partner. Both encryption partners own two keys each: onepublic and the other, private.

The public key is handed over to the communication partners, who encrypt the data with it.Because of the selected mathematical algorithm used to create the public/private key pair, onlythe recipient's private key can decrypt data encoded by his public key.

The private keys have to be kept secret and the public keys have to be exchanged.

The last paragraphs have described more or less the basic way in which many modern VPN solu-tions work. In a nutshell, the di�erent approaches to keying, key exchange, and authenticationof VPN partners make the main part of the di�erences between the VPN Solutions.

3.2 SSL/TLS Security

3.2.1 SSL/TLS Certi�cates

A SSL Certi�cate enables encryption of sensitive information during online transactions.Each SSL Certi�cate contains unique, authenticated information about the certi�cate owner.

A Certi�cate Authority veri�es the identity of the certi�cate owner when it is issued. EachSSL Certi�cate consists of a public key and a private key. The public key is used to encryptinformation and the private key is used to decipher it.

When a Web browser points to a secured domain, a Secure Sockets Layer handshake authenti-cates the server (Web site) and the client (Web browser). An encryption method is establishedwith a unique session key and secure transmission can begin.

3.2.2 Trusted Certi�cates and Self-signed Certi�cates

The most important information in a SSL certi�cate are the �elds Issued To and IssuedBy. If you �nd a trustworthy organization here, it should be safe to trust this certi�cate.

CHAPTER 3. VPN SECURITY 10

Trustworthy means one of several organizations who sign certi�cates, thereby guaranteeing theidentity of the owner of the certi�cate.

With a signed certi�cate the owner of the certi�cate can prove that he or she is who he or sheclaims to be, to anybody who trusts the certi�cate authority.

It is possible to use certi�cates that are not signed by authorities mentioned above, but by alocal Certi�cate Authority. Every SSL/TLS client gives you a warning when a client wants toestablish an encrypted connection with an unsigned private certi�cate.

Such certi�cates are called self-signed certi�cates, and can only be considered trustworthywhen the issuer or the CA is known to and trusted by the client. Self-signed certi�cates areoften used for testing purposes or in local networks because registering (signing) certi�cates atcerti�cate authorities is expensive and not necessary in many scenarios. However, the securitypolicy of a company should contain de�nitions about the use of signed and unsigned certi�cateson servers.

3.2.3 SSL/TSL and VPNs

SSL/TLS certi�cates work exactly the same way with VPNs" a certi�cate authority is de�nedor created and all valid certi�cates issued by this authority are accepted for the VPN. Everyclient must have a valid certi�cate issued by this CA and is therefore allowed to establish aconnection to the VPN.

A Certi�cate Revocation List (CRL) can be used to revoke certi�cates that belong toclients that must not be allowed to connect to the VPN any longer. This can be done withoutcon�guration on any client, simply by creating an appropriate revocation list on the server.This is very useful when a laptop is stolen or compromised.

An organization using a pre-shared key must put this key on every system that connects tothe VPN server. The key must be changed on all systems if one single system or key is lost.But if you are using certi�cates with revocation lists, you only have to put the certi�cate of thestolen laptop on the server's CRL. When this client tries to connect to the server, access willbe denied. There is no need for interaction on with any client.

So connections are refused if at least one of the following conditions is accomplished:

• No certi�cate is presented

• A certi�cate from a wrong CA is presented

• A revoked certi�cate is presented

Such certi�cates can be used for many purposes.VPN solutions (like IPSec), web servers, mailservers, and almost every other server application can use these certi�cates to authenticateclients. When applying this technology correctly, you can achieve a very high degree of security.

Chapter 4

ZCOV - VPN Manager

4.1 Purpose

ZCOV aims to be an easy to use application for creating and managing virtual private networks.Also, we want a lightweight solution, with a strong security component. We describe bellowthe functional requirements.

For the infrstructure part (that is creating and managing the virtual tunnels) ZCOV usesOpenVpn, an open source tunneling solution, described in the following section. This is a

4.2 Speci�cations

ZCOV has the following functional requirements:

• Zero-con�g

First of all, ZCOV should be zero-con�g - it must work without requiring any user-provided con�guration �les. Both the client and the server should be launched usingsimple commands:

zcov-server

zcov-client

Once a server is launched, it is a stand-alone application. The client then connects to theserver. If two clients are connected to the same server and they are member in the sameVPN, they can exchange data without any need of further con�guration.

• Multi-networks support

A ZCOV server should be able to manage multiple VPNs. It should know the clientsmember in every VPN and should control the tra�c accordingly: two clients can commu-nicate only if they are members in the same VPNs and they are both online at least inone common VPN. To illustrate this situation, analyze the �gure bellow.

To complete the multi-network concept, a client must be able to create, delete, join orleave a VPN. Also, if a client is member in a VPN, it should be able to control its statusin the network: it can be online or o�ine.

The �gure bellow describes this requirements: we want to be able to manage di�erent VPNson a single server and to control the network access.

11

CHAPTER 4. ZCOV - VPN MANAGER 12

Figure 4.1: ZCOV - Manage Networks

4.2.1 The Security Component

While there is a generally known trade-o� between security and usability, ZCOV makes nocompromise regarding the level of security provided by OpenVPN. A user is authenticated andauthorized using the cryptographic token (the SSL certi�cate) generated on the client machine.Although the Certi�cate Signing Request and the signed Certi�cate are sent between the serverand the client, they contain public data, which does not possess any security threat on theactual communication. We can even say that the automated process of obtaining certi�catesis a bit safer than native OpenVPN, since the clientâ��s private key is generated locally anddoes not have to travel between computers.

ZCOV has added a new level of security: each VPN is protected with two passwords, thenetwork password and the administrative password. A user is required to enter thenetwork password when joining a VPN. The administrative password is required for managingpurposes. Both passwords are supplied at network creation.

4.2.2 Persistency and Presence

Presence support1 implies that a client can be member in a VPN, but it can be online oro�ine in that particular network. ZCOV should manage this information: the client shouldbe provided with commands for controlling the presence status and the server should use thestatus for routing data: two clients that are members in the same VPN can communicate onlyif they are both online.

1Presence information is a status indicator that conveys ability and willingness of a potential communicationpartner to communicate. The client application provides presence information (presence state) via a networkconnection to a presence service, which is stored in what constitutes his personal availability record (called apresentity) and can be made available for distribution to other users (called watchers) to convey his availabilityfor communication.

CHAPTER 4. ZCOV - VPN MANAGER 13

Also, a client should be informed about the presence status of its peers: it should know whichclients are online in the networks it is member in and to present this information to the user.So the server must continously keep the clients informed about the logical network topology.

Another important feature of ZCOV is persistency. A client must be able to control the net-work topology: it can create or delete networks. Also, it can join or leave networks. The servermust accept this kind of commands from the client and update its information accordingly.But once a client has ended its execution, its actions must not be lost, so that if it resumes itsexecution, the server must provide him the exact state it was in before exit.

For example, if a client is member in two networks: testing_1 and testing_2, and it is onlinein the �rst one and o�ine in the former one, the server should register this information so thatif the client suspends its execution and then resumes it, it receives this data from the server.

The picture bellow ilustrates these demmands.

Figure 4.2: ZCOV Persistency and Presence

4.2.3 Network Query

A ZCOV server knows the con�guration and memberships of all networks. So it should be ableto answer questions such as:

• What clients are online in a given network?

• Are there any networks with the name matching a given pattern?

• Also, a client must be able to ask this kind of questions.

Also, a client must be able to ask this kind of questions.

4.2.4 User Interface

To ensure a high level of usability, a client should be provided with a graphical user interfacethat should contain information such as: the VPNs in which a client is member, its private IP,the other members of the VPN, their private IP and so on.

Also, the GUI should allow the client to create and manage VPNs.

Chapter 5

OpenVPN - a Simple Tunneling

Solution

OpenVPN is a free and open source virtual private network (VPN) program for creatingpoint-to-point or server-to-multiclient encrypted tunnels between host computers. It is capableof establishing direct links between computers across network address translators(NATs) and�rewalls. It was written in C by James Yonan and is published under the GNU General PublicLicense(GPL).

5.1 Networking with OpenVPN

The modular structure of OpenVPN can not only be found in its security model, but also in thenetworking scheme. James Yonan chose the Universal TUN/TAP driver for the networkinglayer of OpenVPN.

The TUN/TAP driver is an open-source project that is included in all modern Linux/UNIXdistributions as well as Windows and Mac OS X. Like SSL/TLS, it is used in many projects,and therefore it is steadily being improved and new features are being added.

Using the TUN/TAP devices takes away a lot of complexity from OpenVPN's structure. Itssimple structure brings increased security compared to other VPN solutions. Complexity isalways the main enemy of security. For example, IPsec has a complex structure with complexmodi�cations in the kernel and the IP stack, thereby creating many possible security loopholes.

The Universal TUN/TAP driver was developed to provide Linux kernel support for tunnelingIP tra�c. It is a virtual network interface, which appears as authentic to all applicationsand users; only the name tunX or tapX distinguishes it from other devices. Every applicationthat is capable of using a network interface can use the tunnel interface. Every technology youare running in your network can be run on a TUN or TAP interface too.

This driver is one of the main factors that make OpenVPN so easy to understand, easy tocon�gure, and at the same time so secure. A TUN device can be used like a virtual point-to-point interface, like a modem or DSL link. It operates with layer 3 packets, such as IP packets.This is called routed mode, because routes are set up to the VPN partner.

A TAP device can be used like a virtual Ethernet adapter, and it operates with layer 2 PDUsuch as Ethernet frames. This mode is called bridging mode because the networks are connectedas if over a hardware bridge.

14

CHAPTER 5. OPENVPN - A SIMPLE TUNNELING SOLUTION 15

Applications can read/write to this interface; the software (the tunnel driver) will take all dataand use the cryptographic libraries of SSL/TLS to encrypt them. The data is packaged andsent to the other end of the tunnel. This packaging is done with standardized UDP or optionalTCP packets.

UDP should be �rst choice, but TCP can be helpful in some cases. You are almost completelyfree to choose the con�guration parameters like protocol or port numbers, as long as both tunnelends agree on the same �gures.

And since OpenVPN uses standard network packets, NAT is no problem either. A host in thelocal network in Sydney with a local IP can start a tunnel to another host in the local networkin London, which also is equipped with a local IP only. This is a major advantage as opposedto IPsec VPN, where the compatibility with NAT is still an issue.

Also, if you want to use DSL lines with frequent reconnects and dynamically assigned IPs,OpenVPN will be your �rst choice. The reconnect is very fast; a Windows terminal server orSSH session does not terminate while one of the VPN partners changes its IP; the session justfreezes for some seconds and then you can continue.

5.2 OpenVpn Security

One of the most important requirements of a VPN is for it to be private. Since VPNs are widelyused by companies for building wide-area intranets, the data traveling through the tunnels isvery sensitive. Therefore, a VPN solution must provide a high level of security, protectingdata against malicious attacks in the network.

There are several types of attacks, which can be categorized into passive and active attacks.A passive attacker is an eavesdropper who has no ability to interrupt or alter the data travelingfrom one end to another. This type of attack is prevented e�ectively by means of encryption.

An active attacker has the ability to insert himself into the communication channel and add,modify or delete data packets between the two ends of the channel: the man-in-the-middleattacks. To prevent this form of intrusion, OpenVPN uses HMAC1 construction to authen-ticate packets. This involves signing every packet with a secure hash, so that the recipient canprove that it originated from a legitimate source.

Even after applying HMAC, the VPN is still vulnerable to replay attacks. This is a form ofnetwork attack in which a valid data transmission is maliciously or fraudulently repeated ordelayed. To prevent this, OpenVPN uses the Sliding Window Algorithm. The packets havea sequence number and are rejected if this number is to the left of the window or is within thewindow but previously received. When OpenVPN receives a packet with a sequence numberto the right of the window, the window is slid to the right so that its right edge is at the newsequence number.

The picture bellow describes how an OpenVpn message looks like: the private data is encrytedand the control information.

OpenVPN has protection against both passive and known types of active attacks. It uses thecryptographic support of the OpenSSL library, speci�cally X.509 certi�cates, signed by theCerti�cate Authority (CA), in this case, the OpenVPN server.

1In cryptography, a keyed-Hash Message Authentication Code (HMAC or KHMAC), is a type of messageauthentication code (MAC) calculated using a speci�c algorithm involving a cryptographic hash function incombination with a secret key.


Figure 5.1: OpenVpn Message Layout

5.3 Con�guration

OpenVPN con�guration is done by editing a text �le; the syntax is the same on every operatingsystem. The options in the con�guration �le allow the application to act either as a server ora client, using a tun or a tap device as the tunnel adapter. Also, the two entities can choose tocommunicate using either UDP or TCP as the transport layer protocol.

Here is an example of a con�guration �le:

1 remote mamba.cs.pub.ro2 float3 dev tun4 tun-mtu 15005 ifconfig 10.79.10.1 10.79.10.26 secret my_secret_key.txt7 port 50508 route 10.94.0.0 255.255.0.0 10.79.10.29 comp-lzo10 keepalive 120 60011 resolv-retry 8640012 route-up "/sbin/firewall restart"13 log-append /var/log/openvpn/ultrino.log

Listing 5.1: Simple OpenVpn Client Con�guration Example (client.conf)

There are over 50 con�guration options and settings that the user must learn to set, so it wouldbe quite easy to o�er a simpler version with no need for con�guration �les.

The following command launches an OpenVPN instance with a given con�guration �le:

1 openvpn --config config_file.conf

Listing 5.2: Lauch OpenVpn instance

5.4 Advantages of OpenVpn

With OpenVPN, a new generation VPN entered the scene. While other VPN solutions often useproprietary or non-standard mechanisms, OpenVPN has a modular concept both for underlyingsecurity and networking.


OpenVPN uses the secure, stable, and lauded SSL/TLS mechanisms for authentication andencryption, and does not su�er from the complexity that characterizes other VPN implemen-tations like market leader IPsec. At the same time, it o�ers possibilities that go beyond everyother VPN implementation's scope:

• Layer 2 and Layer 3 VPN:

OpenVPN o�ers two basic modes, which run either as Layer 2 or Layer 3 VPN. Thus Open-VPN tunnels can also transport Ethernet Frames, IPX packets, and Windows NetworkBrowsing packets (NETBIOS), all of which are problems in most other VPN solutions.

• OpenVPN connections can be tunneled through almost every �rewall If you have Internetaccess and if you can access HTTPS websites, OpenVPN tunnels should work.

• Proxy support and con�gurations

OpenVPN has proxy support and can be con�gured to run as a TCP or UDP service, andas server or client. As a server, OpenVPN simply waits until a client requests a connection,whereas as a client, it tries to establish a connection according to its con�guration.

Only one port in the �rewall must be opened to allow incoming connections: Since Open-VPN 2.0, the special server mode allows multiple incoming connections on the same TCPor UDP port, while still using di�erent con�gurations for every single connection.

• Virtual Interfaces allow very speci�c networking and �rewall rules All rules, restrictions,forwarding mechanisms, and concepts like NAT can be used with OpenVPN tunnels.

• High �exibility with extensive scripting possibilities

OpenVPN o�ers numerous points during connection setup to start individual scripts.These scripts can be used for a great variety of purposes from authentication to failoverand more.

• Transparent, high-performance support for dynamic allocation of IP addresses

By using OpenVPN, there is no need to use static IP addresses on either side of thetunnel. Both tunnel endpoints can have cheap DSL access with dynamic allocation of IPaddresses and the users will rarely notice a change of IP address on either side. BothWindows Terminal server sessions and Secure Shell (SSH) sessions will only seem to hangfor some seconds, but will not terminate and will carry on with the action requested aftera short pause.

• No problems with NAT

Both OpenVPN server and clients can be within a network using only private IP addresses.Every �rewall can be used to send the tunnel tra�c to the other tunnel endpoint.

• Simple installation on any platform

Both installation and use are incredibly simple. Especially, if you have tried to set upIPsec connections with di�erent implementations, you will �nd OpenVPN appealing.

5.5 OpenVpn Limitations

Although there are many advantages in using OpenVPN, there are also a number of limitations:

• It requires the user to edit a con�guration �le

There are many di�erent possible con�guration settings which only make it more di�cultfor an unexperienced user to set up a virtual network. Therefore, o�ering a prede�ned


con�guration �le with a standard set of options would greatly increase the usability ofthe program.

• No support for multiple networks on a single server

Currently, OpenVPN allows the creation of a single network, with the server as the centralnode and multiple clients connecting to it. This can only serve a single purpose, andtherefore multiple servers are needed to provide multiple networks, each with its ownapplicability.

Also, in this scenario, it is not possible for a client to be part of a virtual network forgaming and another for business simultaneously, using the same cryptographic identityand virtual IP address.

Chapter 6

ZCOV - Implementation Details

6.1 User Control

ZCOV has two kind of user interface for the client side:

• a simple command line interface - this was developed durring the early stages of theapplication and it was used mainly for debugging purposes. It o�ers a simple list ofcommands to the user, but it provides the full ZCOV functionality

• a graphical user interface - this is the �nal option for the ZCOV interface. It is developedusing Gtk+ and it is perfectly integrated in the Linux enironment

In the next section, we will present this two interfaces and how does a regular user can interactwith them.

6.1.1 Available commands and usage

A ZCOV user must perform two steps to use the application. First, it must have an account:an association between a nick and an X.509 certi�cate. This is performed by running

zcov-init

This utility generates a certi�cate, sends a signing request to the server, the server signs it andsends it back.

At this time an entry is created in the ZCOV database - an association between the certi�cateand a nick that uniquely identi�es a user.

After obtaining an account, a user can begin to use the application. The command line interfacesummarizes the available commands.

One major requirement for a user is to have a nick. If a doesn't have one, the list of availablecommands is di�erent: the only available commands is set-nick.

6.1.2 GUI

In order to improve the user's interaction ZCOV provides a graphical interface. This enablesthe client to create, join, leave and delete networks, in addition to having real-time knowledgeof the other users in his or her networks.

19

CHAPTER 6. ZCOV - IMPLEMENTATION DETAILS 20

Figure 6.1: ZCOV Command Line Interface

TODO:Write about GUI

6.2 The Architecture of the Application

Because ZCOV is developend as an extension for OpenVPN, it had to use the structures andthe mechanism provided by OpenVPN to integrate itself with the application. In the followingsection we will present how did ZCOV extended the OpenVPN facilities to obtained the desiredfunctionality.

6.2.1 Data structures and meaning

An OpenVPN client uses a big structure to hold all the information about a tunnel: struct con-text. This structure contains three sub-structures: struct context_0, struct context_-1, struct context_2.

struct context_0 holds information about the running OpenVPN process, such as the PID.

struct context_1 holds information about the state of the connection: the two endpointsof the tunnel. This refers to the virtual IPs, the real IPs, the interaction with the TUN/TAPinterface. Also, if using SSL/TSL, this structure keeps track of the authentication process.Because an OpenVPN tunnel uses a TUN as its virtual network adapter, it can accept routingrules. These rules are kept in the context 1. Finally, a server-side context 1 contains the poolfrom which a server allocates virtual IPs.

struct context_1 contains information about the communication channel. It knows thecommunication parameters. It holds event handlers for incoming and outgoing messages, frag-ment management information, counters. Also, this structure holds information about the TSLinstances: the data transferred across the channels must �rst be processed by the TLS layer.


Due to the fact that all the information about the real IPs is hold in the struct context_-2 structure, it also keeps track of the occurring transfers. It uses bu�ers, timers and eventhandlers.

To improve communication throughput, OpenVPN may use LZO compression1 and the dataneeded for compressing the data stream is also hold the context_2 structure. So the mainstructure, context, contains these three sub-structures and some extra data, such as:

• A global garbage collector: OpenVPN uses a struct gc_arena to manage memoryallocation

• Signal handlers: used to manage signals such as SIGKILL, SIGTERM, SIGUSR1.

An OpenVPN server uses a struct multi_context to keep track of the multiple clientsconnected to it. Each connection is identi�ed by a struct multi_instance. Also, each suchinstance has its own struct context.

A struct multi_instance contains information about a server-side tunnel endpoint. Itprovides a scheduler entry used by the server to schedule received tasks. It keeps track of thestate of the endpoint: did the endpoint is opened, is it able to receive data, what routes doesit manage? Also, a struct multi_instance has a corresponding struct context.

The server keeps track of all connections using a struct multi_context. This structureholds some global data about the endpoints of the tunnel, such as:

• Hashes containing clients indexed by virtual IP, real IP and an extra hash, with a speedimprovement

• Task scheduler, used to decide which read/write connection to server next

• Endpoints divided into groups: pending, waiting to be served, in the process of beingserved

To allow multi-network management, ZCOV adds some extra information to the original Open-VPN data structures. To ensure that a high level of modularity is attained, ZCOV adds a newstructure to the main OpenVPN struct context: struct zcov_context. This struc-ture is used both on the server and on the clients side, but it has some information needed onlyby the server.

On the client side, the struct zcov_context is used to keep track of the outgoing messages:the ones for which we expect a response from the server. To hold information about a message,zcov used a struct message. This structure waits to get a mutex. The mutex is �rst gotby the client when it sends the message. After sending the message, it waits until either themessage is received or the condition has timeout. Finally, when getting the response to amessage, the client stores the result in the status �eld of the corresponding message.

So the struct zcov_context contains an array of message_t corresponding to all avail-able messages.

Also, to keep track of the networks in which this client is member, the client has a structnetworks �eld. The client knows:

• Its nick: an unique identi�er for a client in the entire ZCOV network topology

• The number of networks it is member of

• The networks where it is member

To return response for a query, the struct zcov_context has two special �elds: search_-results and nick, used to store results for the obvious commands.

1LZO is a lossless data compression algorithm that is focused on decompression speed. OpenVpn uses onopen source implementation: liblzo.


If this struct zcov_context is included into a struct context corresponding to a server-sidetunnel endpoint, it holds a reference to the corresponding struct multi_instance and tothe server struct multi_context.

To hold all the networks, ZCOV uses a special kind of list: dlink_t. This is a ZCOV-speci�cdata type, actually, a doubled linked list used to store any kind of information. An element(adlink_cell) is described below:

1 struct dlink_cell2 {3 void *data;4 struct dlink_cell *prev;5 struct dlink_cell *next;6 };

Listing 6.1: dlink_cell_t Layout

The list has references to the �rst and the last members of the list:

1 struct dlink2 {3 dlink_cell_t head;4 dlink_cell_t tail;5 };

Listing 6.2: dlink_t Layout

ZCOV uses this structure because it allows storing any kind of data: the data �eld of thedlink_cell has void* type. Also, because it is a doubled linked list, it allows easy cellelimination and iteration. Finally, it is a dynamic structure, it doesnâ��t need to know inadvance how many elements it has to store.

So the nets �eld of the struct networks contains a list with the networks in which thisclient is member. The information about a network is stored into a struct network_info.The relevant information about a network is:

• Its name

• The client's status in the network: it can be online or o�ine

• The clients's role: a regular user or an administrator

• Information about the other members of the network

The information about the peers is hold into another list, with elements having a new datatype: struct simple_client. A client knows about the other members of a network he ismember in the following information:

• The status: the peer is online or o�ine

• The role: administrator or regular user

• The virtual IP

• The nick

Bellow there is an UML1 describing the classes used by OpenVPN with the extension added byZCOV for a tunnel endpoint.

1UML is a standardized general-purpose modeling language in the �eld of software engineering. It includesa set of graphical notation techniques to create abstract models of speci�c systems.


Figure 6.2: Extended Client Structures

On the server side, the main structure containing all the data is the struct multi_context.To keep track of all the networks it manages, the server side adds an extra �eld to the multi_-context structure: networks, with type struct server_networks.

A server_networks structure keeps track of the networks the server should manage. It knowshow many networks are currently up and has a dlink_t member with the list of connectednetworks.

To hold information about a network, this list contains cell with elements of struct server_-network type. This structure holds the name of the network, the number of connected clientsand a list with them. A list element has struct client_info type - it holds authenticationinformation: the key and the tunnel associated context. Also, it knows the virtual IP, used forrouting.

The UML bellow describes how the OpenVPN server-side structures interact with the ZCOVdata structure.

Figure 6.3: Extended Server Structures

Basically, these are the structures used by ZCOV. Their utility will be described in the following


sections.

6.2.2 ZCOV Layers

ZCOV has several layers. These layers contain several logical components (modules or units):

• CLIENT_MANAGEMENT: it holds information about the networks a client is mem-ber

• COMMUNICATION: used to send commands between ZCOV clients and the server,using the OpenVPN control channel

• SERVER_MANAGEMENT: it is used by the server side to keep track of the con-nected clients

• DATABASE_MANAGEMENT: it provides the interaction with the database â��to ensure persistency

Each of these components is independent from the other ones, so they can be changed at anytime, without a�ecting the functionalities of ZCOV. The picture bellow shows how a controlmessage travels from the user side to the server side.

Figure 6.4: ZCOV Units

The ZCOV client uses two modules: CLIENT_MANAGEMENT and COMMUNICATION.

The server uses three components: the SERVER_MANAGEMENT component, the DATABASE_-MANAGEMENT module and the COMMUNICATION module.

The user controls the client using the provided user interface (command line or GUI). TheZCOV library responds to the client's demand. There are basically two types of commands.

First, there are commands that require server communication (such as CREATE ): in thissituation, the ZCOV library provides an API with the available management commands.

Basically, to send a command to the server the client must form a string with the commandand its parameters and send it via the OpenVPN control channel. When the message arrivesat the server, it is recognized as a ZCOV command and passed to the ZCOV SERVER_-MANAGEMENT unit. This unit analyses the command. In some cases, some interactionwith the DATABASE_MANAGEMENT unit may be required. Also, the server updates itsconnections information accordingly to the command.

Finally, after executing the command on the server side, the SERVER_MANAGEMENT unitsends back a response using the COMMUNICATION module.

The API provided by the ZCOV library for sending commands to the ZCOV server is listedbellow.

1 int client_create_network(struct context *c, const char *name, constchar *net_pass, const char *admin_pass);


2 int client_ui_exit(struct context *c);3 int client_set_nick(struct context *c, const char *nick);4 int client_ui_delete_network(struct context *c, const char *name);5 int client_join_network(struct context *c, const char *name, const

char *net_pass, const char *admin_pass);6 int client_leave_network(struct context *c, const char *name);7 int client_ui_go_online(struct context *c, const char *name);8 int client_ui_go_offline(struct context *c, const char *name);9 char* client_search_networks(struct context *c, const char *pattern)

;10 int client_ban(struct context *c, const char *nick, const char *name

);11 int client_kick(struct context *c, const char *nick, const char *

name);

Listing 6.3: ZCOV API(I)

Another kind ofcommands are those which the library can respond using runtime information.For example, the client always knows the membership and the presence information concerningthe networks it is member in and it can transfer this information to the user interface.

The API corresponding to this commands is:

1 char* client_get_ip(struct context *c);2 char* client_get_nick(struct context *c);

Listing 6.4: ZCOV API(II)

Also, the server may want to send update messages (for example, if a client leaves a network,all the other members of the network must receive a noti�cation). When sending these kind ofmessages, the server must get the list with all the clients a�ected by the change and send themthe update message.

For this update messages to reach the user interface, ZCOV needs several callbacks:

1 void2 set_add_network_cb(struct context *c, void (*f)(char *name, int

status, int role));3 void4 set_update_cb(struct context *c, void (*f)(char *name, char *nick,

char *ip, int status, int role, int op_code));5 void6 set_set_nick_cb(struct context *c, void (*f)(char *nick));7 void8 set_delete_network_cb(struct context *c, void (*f)(char *name, int

code));9 void10 set_ui_cb(struct context *c, void* (*f)(struct context *c));

Listing 6.5: ZCOV Callbacks

6.2.3 Interactions with the database

ZCOV uses a sqlite3 database. This database has the following structure:

So the ZCOV database contains 4 tables:


• Networks - contains the list of networks managed by this server - net_name must byunique for the server, so it is used as primary key. A network is associated with a networkpassword: net_pass and an administrator passwords: admin_pass

• Connections - contains the list of connections managed by this server. A record in thistable says that a client (uniquely identi�ed by its certi�cate signature â�� the UID�eld) is connected to a certain network (net_name â�� the network name must be alsoregistered in the networks table). Also the client can be online/o�ine in the given networkâ�� accordingly with the status �eld. The role �eld encodes the role of the client inthat particular VPN: a regular client or an administrator. The ip is the last virtual IPthe client is registered with.

• Banned - contains the list of banned clients (identi�ed the same way as in the previoustable) from a VPN - the net_name �eld.

• Users - contains an association between a user name (the nick) and a certi�cate.

Because the most signi�cant part of a server's job will be to route date, we've considered thatthis is the su�cient amount of information a server should store about a client. Every timethere are changes in the topology of the networks, these changes are recorded into the database,so they could be restored - keeping this information in the server's memory is not secure enough.

The picture bellow describes the layout of the tables in the database.

Figure 6.5: ZCOV Database

6.2.4 ZCOV Hooks in the OpenVPN Code

ZCOV aims to be a light extension over OpenVPN. To ensure this, we wanted the changessu�ered by OpenVPN to be as small as possible.

First of all, we must mention that ZCOV uses some basic OpenVPN functions. One of the mostimportant ones allows sending string messages over the control channel:

1 bool2 send_control_channel_string (struct context *c, const char *str, int

msglevel)

Listing 6.6: OpenVpn Message Passing Method


This method is used for sending ZCOV protocol messages. So these messages use the controlchannel1. So this method requires a string argument: the command to be send over the tunnel.

But a regular ZCOV command has several parameters. Some of them are strings, some of theminteger values. To put together all of these values, ZCOV has several functions for assemblingcommands arguments and, on the other side of the tunnel, to parse the incoming string.

All of these methods are located in the zcov_helper.c and zcov_helper.h �les. These�les contain two types of functions:

• assembly functions, with the name beginning with send_...: they are used to puttogether the command name and various arguments formats

• parsing helper functions, with the name beginning with parse_: they are used to parsethe command name and the parameters on the receiver's side

For example, to parse a command with the format COMMAND_TEXT param we can use onthe server side:

1 bool send_simple_message(struct context *c, const char *message,const char *extra, int debug)


by calling

1 send_simple_message(c, "COMMAND_TEXT", "param1", ZCOV_DEBUG_LEVEL)


where c is the struct context associates with sender's tunnel endpoint.

OpenVPN has a strict policies about the allowed control channel messages: only certain mes-sages are recognized as valid control channel messages and are passed for further processing,once they are received. To ensure that ZCOV messages pass this phase, ZCOV added a hookin the method that analyses incoming control channel message:

1 void check_incoming_control_channel_dowork (struct context *c)


Actually, from time to time, the tunnel manager checks if new data was received on the controlchannel. This is done by calling the following inline function:

1 static inline void check_incoming_control_channel (struct context *c)

2 {3 #if P2MP4 void check_incoming_control_channel_dowork (struct context *c);5 if (tls_test_payload_len (c->c2.tls_multi) > 0)6 check_incoming_control_channel_dowork (c);7 #endif8 }

Listing 6.10: OpenVpn - check the control channel for new data

1ZCOV trans�ers data on two channels: data channel (used for information exchange among peers) andcontrol channel(used for passing con�guration messages)


So if some data was received on the control channel, it calls check_incoming_control_-channel_do_work to analyze the message and process as needed. In this last method ZCOVadds extra conditions for ensuring that the ZCOV protocol messages are processed as needed.OpenVPN allowed only two types of messages: push messages, send by the server to the clientwith its virtual NIC con�guration details and auth-failed: a noti�cation that the clientâ��sauthentication has failed.

ZCOV adds support for all of the necessary messages. For example, to allow passing CREATEmessages (requests on the servers side and replies on the client side), ZCOV adds the followinglines of code:

1 if (buf_string_match_head_str(&buf, "CREATE_"))2 incoming_create_net_message (c, &buf);

Listing 6.11: ZCOV - Allow New Messages

So from this point, the management of the VPNs is done by executing the code for handlingthe commands received on the control channel of an OpenVPN tunnel.

Another important intervention the OpenVPN code has the purpose to ensure that data cannotpass across networks: two clients can exchange information only if they are online it at leastone VPN.

First, OpenVPN performs the routing on the server side: clients do not communicate using sep-arate tunnels, they pass the data to the server, the server identi�es the corresponding outgoinglink and forwards the data. To apply the extra restriction, regarding membership in at leastone common network, ZCOV added some code in the routing section of the server:

1 bool multi_process_incoming_link (struct multi_context *m, structmulti_instance *instance, const unsigned int mpp_flags)

Listing 6.12: ZCOV - Allow New Messages

The �ow for this method is as follow: �rst, mark the incoming link as pending (it is beingprocessed). Then, get the incoming data. Check if the source address is associated with thecorresponding tunnel endpoint instance, then check if the destination client is a known client,currently connected.

If so, ZCOV adds at this point its extra processing section:

1 if (same_networks(si, mi))2 {3 multi_unicast (m, &c->c2.to_tun, mi);4 register_activity (c);5 }

Listing 6.13: ZCOV - Routing

It checks if the source link and the destination link are ful�lling the membership condition. Ifthey do, then data passes from source to destination and the action is registered.

As a conclusion, ZCOV adds only two hooks in the OpenVPN code: it allows passing ZCOVprotocol messages and it routes the data packages according to the known network topology.

6.2.5 ZCOV Error Handling and Debugging

When a client sends a command to a server, it expects for the server to process the commandand return with a status code - this is the result of running the command on the server side.


Only if the operation was successful, the client will take the corresponding action on the clientside.

ZCOV uses several de�ned error codes for every kind of messages. The �le zcov_error.hcontains the error codes used by the ZCOV control protocol. The error codes common to allmessages will be explained here and the codes speci�c to certain messages will be detailed lateron, when explaining the particular message.

The most important ZCOV error codes are:

• SUCCESS - this actually indicates a successful operation

• DB_ERRORS - a server side returns this error code if a given command could not beexecuted on the server side because the database could not perform the required operations

• BOGUS_NET_NAME - this error code indicates that the user tried to perform an op-eration on a network that is not registered in the database

• CERT_ERROR - this error code is returned when the server could not read the certi�catecorresponding to the client's tunnel endpoint â�� so it was not able to check the identityof the client

• NOT_MEMBER - a client receives this error codes when it tries to perform some network-speci�c operation (for example go-o�ine) on a network he is not member of

• NOT_ADMIN - indicates that a client tried to perform some operations that requiredadministrator privileges (for example kick, ban, delete)

• TIMEOUT_ERROR - this error code is returned if the server didn't respond to theclient's message and the condition waiting for the response has expired

• NOMEM_ERROR - this error code indicates that there were memory allocation problemduring the execution of the command

Every ZCOV operation returns such kind of error code. The CLIENT_MANAGEMENT mod-ule acts according to these error codes. Mainly, it will execute some action only if the commandhas returned with SUCCESS error code.

Also, the error code can be used to give a proper feedback to the user interface. For example,the ZCOV command line interface has a special module designed only for given the properinformation about the result to the user. For example, when the CLI receives the result forgo_online, it can call cli_go_online to print out the proper information message:

1 void2 cli_go_online(const char *name, int status)3 {4 switch (status)5 {6 case SUCCESS:7 ....8 case NOT_MEMBER:9 ....10 case DB_ERRORS:11 ....12 case TIMEOUT_ERROR:13 ....14 default:15 ....16 }17 }


Listing 6.14: Error Codes Processing - Sample

To allow easy debugging, OpenVPN uses logging levels. Logging is done using a special macro:

1 define msg(flags, ...) do { if (MSG_TEST(flags)) x_msg((flags),__VA_ARGS__);

2 } while (false)

Listing 6.15: Logging function

Basically, this macro check if the current set log level allows printing messages with the "�ags"logging level. The function x_msg prints the log messages in a format that o�ers some ex-tra information, beside the user supplied string and format parameters. An example of loginformation:

1 Sat Jun 27 21:59:38 2009 UDPv4 link local (bound): [undef]:11942 Sat Jun 27 21:59:38 2009 UDPv4 link remote: [undef]3 Sat Jun 27 21:59:38 2009 MULTI: multi_init called, r=256 v=2564 Sat Jun 27 21:59:38 2009 IFCONFIG POOL: base=10.8.0.4 size=625 Sat Jun 27 21:59:38 2009 IFCONFIG POOL LIST6 Sat Jun 27 21:59:38 2009 Initialization Sequence Completed

Listing 6.16: ZCOV Log Sample

So the logging method adds date and time information. OpenVPN allows the user to controlthe logging level in the con�guration �le, using the verb con�guration options. The minimumvalue is 0 - no logging messages are printed to the standard output - and the maximum is 9 -extremely verbose.

ZCOV uses default con�guration �les for the client side and the server side. On the client sideno logging is done to the user interface so verb is set to 0. On the server side, the log level isset to 3 â�� a reasonable value, useful for debugging.

To ensure easy debugging, ZCOV uses two basic logging levels, de�ned in errlevel.h:

1 #define D_ZCOV_ERRORS LOGLEV(1, 80, M_NONFATAL)/* show zcoverrors */

2 #define D_ZCOV LOGLEV(3, 80, 0) /* show zcov info */

Listing 6.17: ZCOV Logging Levels

So ZCOV messages are visible mainly on the server side and are useful for tracking the �ow ofthe control messages.

6.3 Development and Deployment

ZCOV uses OpenVPN for its infrastructure so the development process is based on the originalOpenVPN sources and build �les. In order to compile and run the application, there are severalutilities needed for development: automake, autoconf and autoheader.

The application has one Makefile base file: Makefile.am. This �le is used by automaketo generate the corresponding Makefile. There are several ways of running Make�le:

• make zcov_client - used by the client-side, this will build the executable for the clientside: ui_control


• make zcov_server - used by the server side, will build the executable for the serverside

• make clean - will erase all binaries and executable

• make install - will actually install the executables in the /usr/bin folder

Another basic build �le is configure.ac, used by autoconf to generate the con�guration�le.

After adding a new source �le to the project, there are several necessary steps to perform inorder to build the project: generate the dependencies �les (autoheader), generate Makefile(automake) and generate con�guration �le (autoconf).

The picture bellow describes the steps for obtaining an executable using this utilities.

Figure 6.6: Building Process

Finally, the building steps for a regular ZCOV user are as follow:

./configure

make zcov_server (for the server side)

make zcov_client (for the client side)

make install

6.4 Testing

ZCOV developping begun by incrementally adding messages. First, after setting up the exten-sion to the OpenVPN structures, we've added the create and delete commands and then addednew messages to extend the functionalities.

In order to test the application we've user a public server (mamba.cs.pub.ro), that listenedfor incoming connection on 1194 - the port used by OpenVPN and also by ZCOV. Becausethe recommended OpenVPN transport level protocol is UDP, the testing had focused on thisprotocol.

Basically, to test the application, we've used several clients that connected to the server andmodi�ed the network toology in order to test various commands. Also, in order to test thatthe network topology respects the logical connections, we've performed data transfers betweenclients.

The picture bellow describes a tipical testing topology.

We've used two stations in the same LAN, the ones with 10.38.*.* IPs. The stations with192.*.*.* are situated in di�erent LANs, with di�erent ISPs. The server manages two VPNs:NetZCOV_1 and NetZCOV_2.


Figure 6.7: Testing Topology

Chapter 7

ZCOV - the Protocol

7.1 Policies and Security Considerationa

Because ZCOV is developed on top of the OpenVPN infrastructure, in order to preserve thelevel of security, it needs several security policies - how the user can control the network infras-tructure, how should the server authenticate users and so on.

The �rst step for a ZCOV client is creating a server-signed X.509 certi�cate. For this pur-pose, ZCOV provides a special authentication and authorization module. A client launcheszcov-init it will issue a certi�cate signing request, send it to the precon�gured ZCOV cer-ti�cate authority, who signs it and the copy it in a default folder.

After this initialization process, when launching a ZCOV client, using zcov-client the clientwill load the signed certi�cate from this location and use it during the current session.

ZCOV distinguishes between two kinds of users:

• regular users - they are allowed to join/leave networks and change their status

• network administrators - they are the only ones allowed to delete networks

To di�erentiate between this user types, ZCOV can protect a network with two kinds of pass-words

• a networks password - if it is supplied with the â��join networkâ�� request, then theclient can login as a regular user

• an administration password - if it is supplied, the client has administration rights for thatnetwork. By default, the client who creates a VPN is its administrator.

Both passwords are supplied when the VPN is created. They are both optional. If they are notsupplied, they are considered to be â��â�� - the empty string.

A ZCOV user can create a VPN - this network can be protected with two kinds of passwords:a networks password (used to join a network as a regular user) and an administration password(used to authorize operations such as kick, ban or delete network).

Because we wanted to be able to delete users that are not currently connected, we needed away to uniquely identify a user. The signature of the certi�cate was not a proper solution,because a user cannot memorize such a large amount of data. Also, the virtual IP was not avalid solution, because we had no guaranty that a user will always be assigned the same IPaddress.

33

CHAPTER 7. ZCOV - THE PROTOCOL 34

So the solution was to add a unique identi�er: a user name (or NICK). The nick cannot bechanged and it is used in operations such kick or ban.

7.2 Protocol API

To provide all of its functionally, ZCOV passes messages between the client and the server.In this section we will present the �ow of a regular ZCOV message and then we will explaindi�erent types of messages.

7.2.1 API

ZCOV messages travel using the control channel o�ered by OpenVPN. ZCOV has several meth-ods to transfer back and forth a message and to parse and analyze it. First, to send a messagewith a given content to a peer, ZCOV uses the already mentioned method:

1 bool send_control_channel_string (struct context *c, const char *str, int msglevel)

Listing 7.1: OpenVpn API

where c is the context information about the connection between the peers, str is the contentof the message and msglevel is used for establishing the debug level.

To read a control channel string, ZCOV has made same changes to an already existing OpenVPNmethod:

1 void2 check_incoming_control_channel_dowork (struct context *c)


This method searches if new data is available on the control channel and, if it is, it passed toan appropriate method, according to its header. For example, if the control channel containsa package starting with the CREATE_ keyword, the package will be parsed by the followingmethod:

1 void2 incoming_create_net_message (struct context *c, const struct buffer

*buffer)


7.2.2 The Work�ow for a ZCOV Message

All control package manager method follow the same control path:

The incoming_*_msg calls process_incoming_*_msg - here we �nally check if we arethe server side or the client side and process the request accordingly to this quality. Most ofthe messages are request/reply. Usually, the reply contains a copy of the request and a code:was the operation successful? If not, which were the causes?


Figure 7.1: ZCOV Message Flow

7.3 Messages

ZCOV has several types of messages and we present bellow the most important ones, explainingthe format and how it is interpreted.

7.3.1 Create/Delete network

To create a new network, the client sends the following control string to the server:

1 CREATE_REQUEST [the name of the network],[the password for joiningthe network],[the password for administrating the network]

Listing 7.4: ZCOV Message: Create

The server analyzes the message. It extracts the most important �elds: the network name andthe passwords.

It then processes it: it creates a network with the given input data and the client that createdthe network automatically will join the network with administration privileges.

This changes are recorded in to database â�� for the create operation we add a new entry tothe networks table and for the join operation, we add a new entry to the connections table.After completing this operations, the server sends the answer on the same control channel:

1 CREATE_REPLY [the name of the network] [operation result code]

Listing 7.5: ZCOV Message: Create


If the operation was successful (result code = SUCCESS), the client adds a new network toits in-memory network topology. Otherwise, if there were some errors processing the request,ZCOV examines the error code to detect the cause and informs the user.

The error codes associated with the create command are: CREATE_USED_NET_NAME(this network name is already used), DB_ERRORS, NOMEM_ERRORS (memory allocationerrors) and TIMEOUT_ERROR.

To delete a network the user is provided with a delete [network name] command. Actu-ally, the client will send on the control channel the following message:

1 DELETE_REQUEST [the name of the network]

Listing 7.6: ZCOV Message: Delete

Once the server receives this message, it will try to delete the network with the given name.First, it checks if the client that send the command has the right to delete the network - it mustbe an administrator.

If so, the server sends to all clients members in this network a LEAVE_REPLY message - sothat the clients will leave this network. Also, the server will update its in-memory topologyand will update the database: it will delete all entries with the given net_name from all threetables. Also, all clients that are members of the given network are send leave messages with acode indicating that the network was deleted.

After this set of operations, the server sends back the answer:

1 DELETE_REPLY [the name of the network] [operation result code]

Listing 7.7: ZCOV Message: Delete

If the result code is SUCCESS, the client will also update its information regarding the networktopology. Otherwise, it will examine the error code and report the problem. The error codesused for the delete command are: BOGUS_NET_NAME, NOT_ADMIN (only administra-tors can delete a network), NOT_MEMBER, DB_ERRORS and TIMEOUT_ERRORS.

7.3.2 Join/Leave Network

A user has the option to join an existing network. To become a member of an already existingnetwork, a user must provide the name of the network and the networkâ��s password.

This way, he will become a normal user in that network. Also, if the provides the administrationpassword, the user will be an administrator and he will have the right to delete the networkand to kick/ban other users.

To join a network a ZCOV client sends the following message to the server:

1 JOIN_REQUEST [the name of the network],[network password],[administrator password]

Listing 7.8: ZCOV Message: Join

The server will search the database for the existing network. If the network exists, it willcheck if this client wasnâ��t previously banned from the network. If all this conditions areaccomplished, the server adds the client to the required network: it will update its in-memorynetwork topology and the database.


To update the database, the server inserts a new entry in the connections table: the clientidenti�er, its private IP address, the name of the network, the status in this network: CLIENT_-OFFLINE for the moment and the role of the client in the network.

To determine the role of the new client in the network, the server check the password the clienthas provided. If the network is protected by a network password and the client has providedone in its connection request, the client will be a regular network member. If the network alsorequires an administration password and the user have provided it, the client will be a networkadministrator.

If the network is not protected in any way, a client can be registered as administrator with ajoin request as simple as:

1 JOIN_REQUEST net_name, ,

Listing 7.9: ZCOV Message: Join Sample

After performing this management operations, the server send back the answer:

1 JOIN_REPLY [the name of the network] [operation result code]

Listing 7.10: ZCOV Message: Join

When receiving a join request answer, the client �rst analyzes the operation result code. Joinhas the following codes:

• Regular ZCOV error codes: CERT_ERROR, BOGUS_NET_NAME, DB_ERRORS,NOMEM_ERRORS, TIMEOUT_ERROR, BANNED_CLIENT (if this client was banned)

• JOIN_ADMIN â�� the client has successfully joined the network as a network adminis-trator

• JOIN_MEMBER â�� the client is now a regular network member

• JOIN_AUTH_FAILED - the user hasnâ��t provided the right passwords for joining thenetwork

If the joining was successful, the client will also update its topology information â�� it will addthe network to the list of connections for the current user. Also, on the server side, if a clientjoins a network, the server will send update messages to inform all of its peers that a new clienthas joined the network.

In a symmetrical way, if a client can join a network, it will also be able to leave it. If a userdecides he wants he leave a network, he will send a leave message. When receiving a leavecommand, the ZCOV client will send the following message to the server:

1 LEAVE_REQUEST [the name of the network]

Listing 7.11: ZCOV Message: Leave

When receiving a leave-request message, the server will check if the client is member of thespeci�ed network and, if it is, it will remove the corresponding entry from the connectionstable. Also, it will update its in-memory network topology and send update messages to all theother members of the network.

After performing these operations, the server will send the answer to the client:

1 LEAVE_REPLY [the name of the network] [operation result code]

Listing 7.12: ZCOV Message: Leave


The client analyzes the return code and, if successful, it will remove the networks from itsconnections list. The leave operation has several return codes, with di�erent meanings:

• Regular ZCOV error codes, received when the leave operation has failed: CERT_ER-RORS, BOGUS_NET_NAME, NOT_MEMBER, DB_ERRORS and TIMEOUT_ER-ROR

• CLIENT_KICKED and CLIENT_BANNED - the client received this leave messagesbecause it was kicked/banned from the network

7.3.3 Go-online/Go-o�ine

Being member of a network is not the only condition for data exchange. A client has associatedpresence information. It can be online or o�ine in a given network. So ZCOV also providesmessages for changing the presence status.

Once a client joins a network, its associated status is CLIENT_OFFLINE. Once the go-onlinecommand is received, the client will send a corresponding message to the server:

1 GO_ONLINE_REQUEST [the name of the network]

Listing 7.13: ZCOV Message: Go-online

On the server side, when this message arrives, if all the security conditions are accomplished,the server will change the status for the client: it will update the entry in the connections tablefrom the database from CLIENT_OFFLINE to CLIENT_ONLINE. Also, its internal networktopology is updated. Because the topology is a�ected, the server will also have to inform theclient's peers in the given network that this client has gone online.

After all of these operations are completed, the server will send back a reply:

1 GO_ONLINE_REPLY [the name of the network] [operation’s status]

Listing 7.14: ZCOV Message: Go-online

This message has the regular ZCOV error codes: NOT_MEMBER, DB_ERRORS, TIME-OUT_ERROR. If the operation has SUCCESS status, then the client will update its topologycorresponding to the new presence status value.

Once a client has gone online, it has the option to go o�ine, using the corresponding command:go-offline. The client request message is similar to the go-online command:

1 GO_OFFLINE_REQUEST [the name of the network]

Listing 7.15: ZCOV Message: Go-o�ine

The server processes the messages similar with the go-online situation: it updates the corre-sponding entry in the connections table, it updates the server's topology and sends updatemessages to the peers. Finally, the server sends back a reply:

1 GO_OFFLINE_REPLY [the name of the network] [operation’s status]

Listing 7.16: ZCOV Message: Go-o�ine

The error codes have similar values to the go-online situation: NOT_MEMBER, DB_ER-RORS, TIMEOUT_ERROR. If the operation has SUCCESS status, then the client will updateits topology as needed.


7.3.4 Kick/Ban Messages

To allow a greater control over the network, ZCOV allows the administrator of a network tocontrol the access to the network: it can kick or ban another member of the network.

When a client is kicked, actually it is forced to leave the network, but it can join it again atany moment. On the other side, when a client is banned, it can no longer join the network inthe future. A client must be online in order to kick it, but it can be o�ine and not event amember to ban it.

The message exchange is similar. First, the client sends a request:

1 KICK_REQUEST [peer’s nick] [the name of the network]2 BAN_REQUEST [peer’s nick] [the name of the network]

Listing 7.17: ZCOV Message: Kick/Ban

The server checks if the client that issued the request is actually network administrator. If so,it proceeds. First, for both kick and join, the server deletes the client from the connectionstable and from the current topology. Also, it sends update messages to all the correspondingpeers.

Ban assumes an extra step: adding an entry in the banned table, an association between a nickan UID. After completing these steps, the server sends back a reply:

1 KICK_REPLY [peer’s nick] [the name of the network] [status]2 BAN_REPLY [peer’s nick] [the name of the network] [status]

Listing 7.18: ZCOV Message: Kick/Ban

When the client receives the reply for kick/ban, it may have the usual ZCOV error codes:BOGUS_NET_NAME, NOT_ADMIN, NOT_MEMBER, DB_ERRORS and TIMEOUT_-ERRORS. After properly processing the code, the client doesn't need to do any action: it willreceive updates from the server that its peer has left the network.

7.3.5 Get/Set Nick

ZCOV is based on an association between an X.509 certi�cate and a nick for easily identifyinga client. To initialize this association, a ZCOV client must send a set-nick request to the serverin the initialization phase:

1 SET_NICK_REQUEST [nick]

Listing 7.19: ZCOV Message: Get/Set Nick

All the server will do is to add an entry in the users table: the nick and the signature of thecorresponding X.509 certi�cate. After registering the information, the server will send back areply:

1 SET_NICK_REPLY [nick] [status]


The client will receive a message with the usual error codes.

At login, the �rst information a user is interested in is its nick and its virtual IP. So it will senda get-nick request to the server:


1 GET_NICK_REQUEST


The server will search the users database for the corresponding association and will return amessage with the following format:

1 GET_NICK_REQUEST


The client will store the nick and will be able to send it to the user interface if needed.

1 GET_NICK_REPPLY [nick]


7.3.6 Querying Messages

ZCOV o�ers several messages for interacting with the persistent data. One of the basic ones issearch - it searches a network using a user-provided pattern. The client sends a request:

1 SEARCH_NETWORK_REQUEST [pattern]

Listing 7.24: ZCOV Message: Search

The server actually searches for this pattern in the networks table and forms a string with theresponse. The response will contain all the network names matching the pattern, divided bycommas. After extracting the result from the database, the server sends back the result:

1 SEARCH_NETWORK_REPLY [net1,net2âAe]

Listing 7.25: ZCOV Message: Search

The client will parse the result and output it to the user according to the user interface methodbeing used.

When a client logs in, it wants to know the networks it is member in and their components. SoZCOV provides two ways of getting to know a clientâ��s initial network topology. First, theclient must �nd out the networks it is member in. To do so, it will send a nets request:

1 NETS_REQUEST

Listing 7.26: ZCOV Message: Nets

The server will search the connections table for entries corresponding to the given client andwill form a string containing information about the client: its status and role in the network.

So the string will contain several items having the following format: network:status:role,divided by commas. If the client has logged on for the �rst time, it will automatically beconsidered member of the DEFAULT network, with ONLINE status and ADMIN role. Also,once the server updates its topology, the peers are sent update messages. After extracting thedata, the server sends back the reply:

1 NETS_REPLY [result]

Listing 7.27: ZCOV Message: Nets


The client will parse the result and update its network topology â�� it will have the list ofnetworks he is member in.

To populate this list on the client side, the client will issue a request for listing each network.

1 LIST_NETWORK_REQUEST [network name]

Listing 7.28: ZCOV Message: List Network

The server searches the connections table for all the entries having the given network nameand forms a string containing records about each network member. A record contains the nick,the virtual IP address, the role and the status â�� the client is currently connected or not. Sothe server sends a reply with the following format:

1 LIST_NETOWKR_REPLY [network name] [nick:ip:status:role,âAe]

Listing 7.29: ZCOV Message: List Network

The client will parse the reply and will �ll in the network topology.

7.3.7 Exit

Before a client could properly exit ZCOV, it must send a noti�cation message to the server.Actually, the log out message sequence implies exchanging several messages. First, the clientwill send a message corresponding to the phase 1:

1 EXIT_REQUEST 0

Listing 7.30: ZCOV Message: Exit

At this stage the server will delete from its network topology entries corresponding to thecurrent client and send the corresponding update messages. Also, it will send a phase 1 reply:

1 EXIT_REPLY 0


When receiving this reply, the client will delete all the network topology information it wasstoring. Also, it will send a con�rmation to the server:

1 EXIT_REQUEST 1


When the server receives this message, all the topology information is updated and this clientis already disconnected from all the networks, so the server can close the corresponding com-munication channel. On the client side, the client waits a reasonable amount a time until thesecond message should have reached the server and then it closes its end of the tunnel and�nally exists.

7.4 Initialization Sequence

When a client connects to the server, there are exchanged several messages. The diagrambellow describes the messages exchanges betweend the client and the server at the initialization,assuming that this is a valid client: it has already set a nick.

If the client doesn't have a nick, NICK_REQUEST will receive NULL and will force to user tosupply a nick. After setting the nick, the message exchange is the same as in the above picture.


Figure 7.2: Client Initialization Sequence

Chapter 8

Conclusion and Further

improvements

8.1 Conclusions

As a conclusion, we can state that started from OpenVPN, which is a simple, easy to maintainalternative for implementing a VPN. Adding the zero-con�g extension makes we obtain a newVPN solution, easy to use and con�gure, with no compromise regarding its strong level ofsecurity.

We wanted to develop a VPN solution with a high level of security and �exibility. Also, one ofthe main goals was to get am easy to use user interface.

After analyzing di�erent tunneling solutions, OpenVpn was chosen to assure the VPN infras-tructure. This is an open source solution, developed under GNU license. It uses SSL/TSL toensure a high level of security. Also, to obtain a high throughput, it uses LZO compression.

One of OpenVpn's weakness is its need of a con�guration �le, with intricate options. To ensurethe ease of use, one of the main demands, we needed to add some automation tools.

First, we separated the client and the server. The server preserves most of the initial OpenVpnfeatures. The client, on the other side, needs to be provided with a X.509 certi�cate to authen-ticate it. ZCOV provides the user with a tool for generating and installing security certi�cates:zcov-init. This tool is used to issue a certi�cate, send it to the zcov-ca server, sign it there andsend it back to the client. Once a sign certi�cate is received, it is places in the clientâ��s homedirectory.

A ZCOV client is uniquely identi�ed by the signature of its certi�cate and a nick. So, beside thecerti�cate, a client needs to set its nick. ZCOV is provided with a special interface for settingthe nick.

So after a client has an X.509 certi�cate and a nick, it can use the API provided by the ZCOV.By now, the zero-con�guration demand is accomplished. To obtain the possibility to managemultiple networks on the same server, we added new �elds to the main OpenVpn structures.So the server can route data only amongst members of the same VPNs. Also, a client knowsthe members of his networks.

To ensure the �exibility and the management possibilities, we've provided the user with severalcommands. For example, a user can create, delete, join or leave networks. To ensure the

43

CHAPTER 8. CONCLUSION AND FURTHER IMPROVEMENTS 44

security, several special users can be network administrators. They have special rights, such asdelete networks or kick/ban clients from the network.

Finally, we've added a connection to a sqlite3 database, to store information about clients,networks and connections.

In order to ensure a high level of modularity, we've conceived ZCOV as a library that exposesan API to the user interface module. Also, the library contains several modules for client, serverand database management and for communication.

As a conclusion, we can say that we've attained our purpose: we've created a solution formanaging VPNs: ZCOV. This extension added to OpenVpn has several strong points: no needfor con�guration, ease of use, great administrative power, high security, dynamic topology andpersistency. This solution is distinguishable among other similar ones because it is an opensource implementation and it uses SSL/TSL to ensure the high level of security. Also, themodularity and the ease of use are remarkable advantages.

8.2 Further improvements

Since we've reached the zero-con�g purpose, to enhance the application, we should add morefacilities.

As further improvements, we can add more messages to the protocol. For example, a client cansend invites to a network. Also, we can add a command interface for the server side. As anextra persistency solution, we can duplicate the database from time to time.

Because OpenVpn is portable across many platforms, we can extend this feature to ZCOV -provide it with support for Windows and MacOs.

Bibliography

[1] Markus Fielner, OpenVPN Building And Integrating Virtual Private Networks, December,2006

[2] Keir Davis, John W. Turner, Nathan Yocom, The De�nitive Guide to Linux Network Pro-

gramming, September, 2004

[3] Charlie Hosner, OpenVPN and the SSL VPN Revolution, September, 2006

[4] Mike Owens, The de�nitive Guide to Sqlite3, January 2006

[5] Jon Snader, VPNs Illustrated: Tunnels, VPNS, and Ipsec, 2005

45

diploma project zcov - a zero-con g solution for...

Documents