[Show/Hide Left Column]


1. Introduction


1.1. Why this wiki ?


The motivation of this wiki has it roots in the experience with the computer security courses at Lund University. Part of the courses is devoted to network security where the students learn the most important details of the SSL, TLS, and IPsec secure connection protocols. The focus in these courses lies on understanding how these protocols are designed and function. Students are also given an insight in how to select an appropriate secure connection protocol when the end application(s) is/are known. Practical experience with SSL through the courses is given but several details and aspects can not be addressed. In particular data networking aspects due to routers, gateways, and firewalls need to be left out because of time limitations. Where the offered practical experience to the students is incomplete for SSL/TLS, it is essentially lacking entirely for IPsec. As the reader will find out there is a reason for why this is so; IPsec, although conceptually not difficult to understand, is in practice not easy to use. On the other hand IPsec based Virtual Private Networks (VPNs) are very regularly deployed and many employees use VPN technologies to connect their laptops to their company’s or organization’s network. Also we see new secure connection protocols emerging that combine existing technologies in alternative ways, e.g. OpenVPN that combines SSL with the notion of VPN. This made that in the past years the situation of not being able to offer a more in depth experience with the most important protocols has become quite unsatisfactory and the desire grew to counter this by offering a set of laboratory lessons to the students. To make this successful one needs to bring in a fair amount of ip network knowledge. Yet the focus of the material should be the connection protocols. We therefore suppress knowledge if ip by offering setups where the necessary Ip related configurations are already carried out. The more ambitious students may of course try to repeat the experiments while also do all the required network configuration work.


1.2. Secure Connections


SSL or TLS is likely the secure connection protocol that most students learn first. It is often described in computer network, computer security, and/or advanced Java and Web programming courses. SSL and TLS are also the two protocols that most people use when performing home banking, doing purchases via the internet, or when booking tickets. But what makes a data connection into a secure one? The answer to this question is that it depends on what kind of protection the users of the connection need. Is it the case that the users want confidentiality or is it the case that confidentiality is of no concern but instead message integrity and correct origin identification are important? For example a connection over which one sends control commands to power grid switches needs protection against false messages being inserted, or send messages from being repeated or modified, but there is little concern about the confidentiality of the commands. In this booklet we consider general purpose data secure connections and consequently such connections need to provide protection against the most threats to any type of data. For each threat a secure protocol should have at least one protection mechanism. In Table xxx we gave the most common threats for which one seeks protection
In Table xx we also list some mechanisms that can be used. The reader should however be warned not to take this table too literal as certain combinations of choices may not make sense. Yet the table gives an insight of the wide number of choices that can be made. For example, confidentiality protection is provided by encryption which can be a stream cipher or a block cipher and can be of symmetric or public-key type and then there are several choices for stream ciphers and block ciphers, etc. That fact that public-key encryption is rather complex makes that this choice is usually not realistic for confidentiality protection of large data amounts. In section xxx we look closer at the basic mechanisms that we find in most secure connection protocols.

The SSL protocol was pioneered by Netscape and standardized with minor modifications as TLS 1.0 by the IETF. TLS/SSL is a protocol that allows a client to securely connect to a server using the TCP protocol. Today it is the standard protocol for browser and Java applications to connect securely to servers and as we see later there are also tunnel (VPN) variants. The nature of the design makes that applications (clients) that want to utilize TLS/SSL instead of TCP directly have to be modified. This means that if one has several TLS/SSL enabled applications running in parallel then each application has a secure connection to a server as illustrated in Figure 1.1.




Figure 1.1: Three TLS/SSL enabled applications, each connecting to its server.

So each application is in principle responsible for selecting the protection features that the secure connection protocol offers. This characteristic of a protocol can be viewed as positive if one wants to be sure that the applications really use the desired protection. At the same time the very same characteristic can be viewed as a disadvantage because the networking interface of the application has to be modified to use the interface to the given protocol. Another way to provide secure connections would be that of a secure channel between the PC and a gateway from which the servers can be reached. Figure 1.2 shows this alternative. For the applications it somehow appears that the PC is connected to the network on the right hand side of the gateway.




Figure 1.2 Three applications of Figure 1.1 but now their connections are tunneled to a gateway from which the servers can be reached.

Such a setup is commonly referred to as Virtual Private Network (VPN) tunnel. In this book we adopt the principle that a VPN solution should provide applications (running in the user space of the operating system) a secure connection WITHOUT a need for adaptation to use the secure tunnel. We would like to write that the application is not affected at all but in general the application may notice side effects of the secure tunnel such as reduction in data transfer throughput and response times. When it comes to VPN type setups one can distinguish two typical cases. One is the so-called RoadWarrior scenario and the other we call the InterConnect scenario. In a RoadWarrior setup one considers the case of a person that is connecting via an external (public) internet to a local, corporate network, say. The goal is to create the illusion that the person’s computer is in the local network and thus can use the same services as anybody else who has his/her computer connected to the local network. This case is typically that of an employee on a business trip or working at home and wants to use his computer at home in the same manner as when being in the office. Here a VPN solution does provide a way to achieve this.




Figure 1.3: Roadwarrior and InterConnect scenarios.


Menu [toggle]