The IP Security Protocol, Part 1

Explaining IPSec, different levels of security and how to be safe sending and receiving packets over the network.

Real-world communications over the Internet are becoming more and more widespread. In particular, commercial transactions, which deserve a high level of security, often take place over our beloved--though insecure --packet network. Furthermore, VPNs (virtual private networks, i.e., private networks deployed over a public packet infrastructure) are definitely emerging as the solution of choice for the interconnection of distant offices belonging to the same company.

Unfortunately, IP packets carry our precious data in a clear form that is easily intercepted by malicious users. Doing this on a common Linux-based PC is actually quite easy, provided that one has access to the network segment over which the desired packets are traveling.

Several different solutions exist that allow us to cope with this problem, each operating at a different level of abstraction. In this article, we will discuss the differences between and purposes of application-level security, socket-level security and network-level security.

Application-Level Security

An application that needs to transmit protected data over an insecure network may adopt internal mechanisms in order to achieve data integrity and privacy. The application developer must take care of all the intricacies of authentication, encryption and key exchange. Eventually, he or she will come out with an allegedly secure mechanism allowing the application to achieve what was requested. Other developers, working on different applications, will have to do it all over again, coming out with different solutions. The probability of a security flaw hidden inside one of those applications greatly rises as their number increases. Also, most programmers are not security experts, and even if they are, they usually are not skilled mathematicians with a deep knowledge of encryption algorithms as well. Chances are high that, sooner or later, one of them will make a mistake that spoils the whole security infrastructure.

It is amazing to discover how a single bit that turns out to be not quite random enough can dismantle a thoroughly designed security system. The case of GSM (Global System for Mobile Communications, the cellular phone standard adopted in Europe) card cloning is an example of how such subtle details can become baleful. The bottom line is developers should always rely on widespread, possibly open-source solutions for their encryption needs.

Socket-Level Security

Transport Layer Security (TLS) and Secure Sockets Layer (SSL) are common solutions to protect users' data from the prying eyes of malicious eavesdroppers. They basically provide applications with enhanced sockets that automatically encrypt any data flowing through them. SSL is used, for example, by web browsers when they are using the HTTPS protocol. The advantage of TLS and SSL over generic application-level security mechanisms is the application no longer has the burden of encrypting user data. Using a special socket and API, the communication is secured.

The problem with SSL is an application wishing to exploit its functionality must be written explicitly in order to do so (see Resources). Existing applications, which constitute the majority of data producers on the Internet, cannot take advantage of the encryption facilities provided by SSL without being rewritten. Think of the common applications we use everyday: mail clients, web browsers on sites without HTTPS, IRC channels, peer-to-peer file sharing systems and so on. Also, most network services (such as mail relays, DNS servers, routing protocols) currently run over plain sockets, exchanging vital information as clear text and only seldomly adopting application-level counter-measures (mostly integrity checks, such as MD5 sums).

Network-Level Security

Going one step down the OSI stack, IP Security (IPSec) guarantees the data privacy and integrity of IP packets, regardless of how the application used the sockets. This means any application, as long as it uses IP to send data, will benefit from the underlying secure IP network. Nothing has to be rewritten or modified; it even is possible that users won't be aware their data is being processed through encrypting devices.

This solution is the most transparent one for end users and the one most likely to be adopted in the future in the widest range of situations. The main drawback of IPSsec lies in its intrinsic infrastructural complexity, which demands several components to work properly. IPSec deployment must be planned and carried out by network administrators, and it is less likely to be adopted directly by end users.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix