The IP Security Protocol, Part 1
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.
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.
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).
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.
|Bitcoin on Amazon! Sort of...||Sep 28, 2016|
|Free Today: September Issue of Linux Journal (Retail value: $5.99)||Sep 27, 2016|
|nginx||Sep 27, 2016|
|Epiq Solutions' Sidekiq M.2||Sep 26, 2016|
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Bitcoin on Amazon! Sort of...
- Android Browser Security--What You Haven't Been Told
- Nativ Disc
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Epiq Solutions' Sidekiq M.2
- Identity: Our Last Stand
- The Many Paths to a Solution
- Ascensio System SIA's ONLYOFFICE
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide