5.2. Encryption

In the early days of the Internet and first network protocols, nobody thought about the security aspects. This issue became important only when actual break-ins started happening. The two biggest oversights in the development of these technologies were allowing data to be sent in plaintext on the network and allowing network equipment to listen to all network traffic.

As was considered in Chapter 1 , there are two ways to connect computers into a network using coaxial cable. In one, computers are connected to one common bus with the ends of the bus standing free (Fig. 5.2). The other method is just a variation of the first one with the two end computers connected to each other. In the case of the common bus, all computers are connected in series and a packet is placed on the common bus and is available to all computers. Which of the computers receives the packet is decided by its network adapter: It examines all the packets and accepts only those addressed to it for further processing.

Figure 5.2: The common-bus network topology

All the network cards on the bus can see all packets placed onto it. If you really want to read other people's network traffic, you can find a sniffer program and monitor all data that pass through your network card even if they are not intended for you. Because most protocols process packets in plaintext, any hacker can monitor the network and discover confidential information traveling over it, including access passwords.

Coaxial cable as the choice of network medium is used seldom nowadays, because such connection is not reliable and its bandwidth is limited to 10 MB/sec. Also, the connection concept itself is inherently unreliable. The operation of the entire network may be disrupted if one of the computers fails. The ring topology partially solves the reliability problem, but it does not resolve other issues, such as the slow speed and difficulties constructing, servicing , and using such a network.

The star topology (Fig. 5.3) involves computers connected to one central device, a hub or a switch. The computers are connected using twisted pair wire. This arrangement is more reliable and supports 100-MB/sec bandwidth.

Figure 5.3: The star network topology

If the central connection device is of the hub type (also known as a multiport repeater), all packets that it receives from one of the computers are simply resent to the rest of the network computers. Thus, any of the network's computers can read packets addressed to any other machine in the network.

If the central connecting device is of a switch type, the packets are delivered only to the recipient, because the switch has built-in routing capabilities. The latter are mostly implemented at the MAC address (also called the physical address) level. A MAC address is a 48-bit unique number assigned to the card by the manufacturer. It is unique because each manufacturer has its own MAC address range. Each computer in the network has a unique MAC address as well and is connected to a separate port on the switch. The switch sends each packet only to the computer, to which it is addressed; the network's other computers will not see this packet.

There also are switches that can handle packets on the IP address (logical address) level, the way it is done by routers. In this case, packets are forwarded based on logical and not physical addresses and a switch can connect entire networks.

But even when a network is connected using a switch, it is possible to eavesdrop on the traffic on the server. Nobody likes this state of affairs, especially when confidential data are involved.

It is unrealistic to redesign the existing protocols, because it is expensive and in some cases simply impossible . But another more convenient , universal solution has been offered : tunneling. Tunneling allows remote access programs from different developers to interact with each other. The technique also supports several authentication methods and data compression and encryption. In general, the tunneling concept can be described (using FTP as an example) as follows :

A program to encrypt traffic is launched on a port, say Port 1, of the client computer. An FTP client connects to Port 1 on the local computer and sends data to this port in-stead of the remote computer. The encryption program encrypts the data and sends them over the network.
At the remote computer, the same encryption program is started at a certain port. It receives the encrypted data, decodes them, and forwards them in plaintext to the FTP server port.

Fig. 5.4 shows the data encryption process. Thus, all packets are sent via a middleman that encodes them. Currently, the most widely-used encryption protocol is the Secure Sockets Layer (SSL) protocol. It has earned a reputation as a reliable data-exchange tool and has been used to protect Internet transactions. For example, a secure encrypted connection is used when a buying transaction is carried out through an Internet store to protect the credit card information. When the browser connects to the server, the former automatically launches the encryption program on the client computer, via which the server sends and receives encrypted data.

Figure 5.4: Channel encryption

Thus, encryption does not change TCP/IP; data are simply encrypted and decrypted on both the server's and the client's sides. This method is convenient because it can be used to encrypt data sent using any protocol. Should the encryption program have to be modified, for example, to fix a bug or to use a longer key, the protocol will not have to be modified.

Consider an example with the Web service, which works on port 80. The encryption program can be started on the server on port 1080, decrypting all data that passes through the server and passing them to port 80. If you only want to allow access to the Web over the SSL protocol, port 80 can be blocked by a firewall (considered in Chapter 4 ) and allow connections only from the encryption server.

Addresses of sites protected with special keys are prefixed by https ://. The difference from the regular sites is the "s" letter, which means that the connection is secure. Moreover, when connecting using a browser with SSL enabled, the secure connection is indicated by an icon in the status panel in the lower right part of the browser window. In the popular Internet Explorer browser, this is an icon of a padlock (Fig. 5.5).

Figure 5.5: A secure connection indication in Internet Explorer

But even in Internet Explorer, this icon does not always appear when a secure connection is established. The type of the connection can be determined more precisely by examining the page's properties. Most browsers have a command to view the properties of the loaded page, among which is the encryption used. In Internet Explorer, page properties can be viewed by executing the File/Properties menu sequence. This will open a dialog window similar to the one shown in Fig. 5.6. The information about the connection is shown in the Connection field. In this case, it shows that the 128-bit encoding SSL 3.0 RC4 protocol is being used.

Figure 5.6: An Internet page's properties

5.2.1. stunnel

The program used most often in Linux for encrypting and decrypting network traffic is stunnel . The program itself only organizes the channel and serves as a middleman. The encryption is performed by the OpenSSL packet, which is included in most Linux distributions. If you don't already have it installed, you can do so by installing the corresponding RPM packet from the installation disc. More detailed information about OpenSSL, as well as the latest updates, can be found on the www.openssl.org site.

The OpenSSL operation principle is based on using two keys: public and private. The public key can only be used to encrypt data; the private key is required to decrypt it.

OpenSSL and the stunnel program have lots of parameters, and I will not consider all of them. What I will do is to consider a real-life example and teach you the most often used arguments.

Start the stunnel program on the server to decrypt the incoming traffic and forward it to some port, for example, port 25 (used by the sendmail SMTP server). This is done by executing the following command:

 stunnel -p /usr/share/ssl/cert.pem -d 9002 -r 25

In this case, the program was started with the following three parameters:

-p After this key, the default SSL authorization certificate is specified. It is created when the operating system or the stunnel program was installed and is stored in the /usr/share/ssl/cert/pem file.
-d This option specifies that the tunnel is to work as a daemon. The switch is followed by an optional IP address and the port, on which to expect the connection. If the address is not specified, all interfaces of the local computer will be monitored . The port was specified as port 9002. All data coming to it are considered encrypted and will be decrypted for forwarding to another port of the local computer.
-r This key is followed by an optional computer name and the port, to which the decrypted data are to be forwarded. If the host is not specified, the data will be forwarded to the local computer's port, on which the SMTP server is supposed to work, which in this case is port 25. If the data are intended for another computer, specify this parameter as 192.169.77.1:25 ; here 192.169.77.1 is the IP address of the computer, and 25 is the port number.

Things are much easier with the client. It is launched by the following command:

 stunnel -c -d 1000 -r 192.168.77.1:9002

The -c switch means that the tunnel is established for a client. By default, the stunnel program launches in the server mode.

The remaining switches are the same as for the server. The -d switch indicates the port, on which the connection is expected, 1000 in this case; the -r switch is followed by the computer and port, to which the encrypted data are to be sent.

The client program has to be configured to send mail to the port, on which the stunnel client is running (port 1000 in this case). The latter will encrypt the data and forward them to port 9002 of the 192.168.77.1 computer. The data on the destination computer are received by the stunnel server, which decrypts and then forwards them to the server's port 25.

5.2.2. Supplementary OpenSSL Features

The stunnel program was launched on the server with the use of an authorization certificate specified. But how can the authenticity of the certificate be ascertained? The control levels are specified by the -v option followed by a number indicating the control level. These are the following:

No check is performed.
1 If a certificate is present, it is checked for being genuine . A negative result causes the connection to be broken. A certificate is not necessary to establish a connection; it can be established without one.
2 A certificate must be used at this level. If there is no certificate or if it is invalid, a connection cannot be established.
3 The use of a certificate is mandatory; moreover, it must be in local storage (on a special list). In this case, the directory, in which certificates are stored, must be specified using the -a option.

An SSL server can decrypt traffic and forward it to the port of the receiving program of not just the local computer but also another remote computer. Thus, the SSL server and the server of the traffic receiver can be located on two different computers. It is desirable that, after decrypting data, the server hide the source client's IP address. This can be done by specifying the -T option.

When the OpenSSL package is installed, certificates and key pairs to be used for encryption are created on the disk in the /usr/share/ssl/ directory.

The protocol to be used can be directly specified using the -n option. The following protocols are currently supported: POP3, SMTP, and network news transfer protocol (NNTP).

For most protocols, there are port numbers that have become standard. There are even names of secure protocols, which are usually obtained by adding an "s" letter to the name of the main protocol. This letter signifies the secure SSL connection. The relevant information is shown in Table 5.1.

Table 5.1: Protocols and the corresponding ports
Protocol	SSL version	TCP port number
HTTP	HTTPS	443
SMTP	SMTPS	465
LDAP	LDAPS	636
TELNET	TELNETS	992
SHELL	SSHELL	614
FTP	FTPS	990
FTP-DATA	FTPS-DATA	989
IMAP	IMAPS	993
POPS	POP3S	995
IRC	IRCS	994

Note that two protected channels are required for FTP. One is used for the control connection, and the other to transmit data. I will return to this in Chapter 10 , where this protocol is considered.

5.2.3. File Encryption

Some servers are used for storing archive data access to which, nevertheless, has to be restricted to authorized people only. The best way to protect this information is to encrypt the files. This can be done using the OpenSSL packet.

Not only backup or archive files may have to be encrypted but also confidential information files that are sent over insecure communications channels, for example, through email or a public FTP server.

A file is encoded by executing the /usr/bin/openssl comand as follows:

 /usr/bin/openssl algorithm -in filel -out file2

There are dozens of encryption algorithms that can be used. The most commonly-used is the Data Encryption Standard (DES) algorithm. You can learn, which algorithms are supported at the OpenSSL site or from the openssl man page.

The -in parameter specifies the input file to be encrypted; the -out parameter specifies the file, into which the encryption results are stored.

A file is decoded by the same command, but with the -d option added. The -in argument specifies the file to be decoded, and the -out argument specifies the file, into which the results of the decoding are to be placed:

 /usr/bin/openssl algorithm -d -in file2 -out filel

Try using the OpenSSL program by encoding the /etc/passwd file. The file is encoded with the DES algorithm, and the results are saved in the /home/passwd file. This is done by executing the following command:

 /usr/bin/openssl des -in /etc/passwd -out /home/passwd

The program will ask you to enter a password and then confirm it to prevent potential entry errors.

Now, verify that the contents of the encoded file are unreadable by executing the cat/home/passwd command.

Decode the encoded file by executing the following command:

 /usr/bin/openssl des -d -in /home/passwd -out /etc/passwd

Encoded in this simple way, a copy of the password file can be safely stored.

5.2.4. Tunneling as Hackers See It

Hackers can use tunneling to achieve their own ends. For example, recently I connected to the Internet using the Asymmetric Digital Subscriber Line (ADSL). The monthly fee covers only 400 MB of the traffic. But for me 400 MB is a pittance. It is barely enough for a week's work in the economy mode because of my numerous contacts. Sometimes I download up to 20 MB a day from my mailbox. The fee for megabytes over the 400 MB monthly limit is rather expensive.

So I had to come up with a solution to circumvent the limitation and to obtain access to unlimited traffic. Like most providers, my provider allows unlimited free traffic from its own servers. Although there is little of use on those servers, this can be fixed easily.

My monthly fee also covers 10 MB of server disk space for a personal Web page. An-other home page is not what I am interested in, but the unlimited traffic to and from it is.

By installing a tunneling program on the server, a connection can be organized as shown in Fig. 5.7.

Figure 5.7: Connecting to the Internet via a Web server

The hacker uses the stunnel program to connect to the free Web server located on the provider's machine. From the Web server the traffic is forwarded to some proxy server on the Internet or directly to Web sites. This does not cost any money, because the two-way communication with the Web server is free.

In this way, more than 400 MB can be downloaded, all for free. There should be, however, at least some sort of a Web page placed on the Web server; otherwise , the administrator will notice right away that there is lots of traffic going to the empty Web page and will be able to figure out the tunnel.

Another nonstandard use of tunneling is expanding network access capabilities. For example, some local network may prohibit certain Internet access protocol. In my life, I have worked for companies that allowed access to Web sites only over HTTP. All other protocols were prohibited . The management justified this policy by arguing that users should not be able to send files to the Internet.

Is it possible to circumvent this limitation? Again, place a tunnel on the Web server and you can use any other protocol by hiding all traffic within HTTP. The tunnel then forwards the traffic to the necessary ports under the necessary protocol.

Suppose you need FTP access. Install a tunnel server on port 80 of some Internet server. Access to the Internet server is allowed because a Web service is supposed to be here. Configure the client to connect to the desired FTP server. On your machine, install a client to connect to port 80 of the server. The data that you now transmit will be forwarded to the desired FTP server.

Tunnels of this type do not require encoding and can be implemented with simple programs, for example, Perl scripts. Packets do not necessarily have to be sent using HTTP. Practically any TCP-based protocol will do. You can even hide the necessary protocol in DNS or ICMP packets if these are allowed in your network. Although ICMP can be blocked, it is practically impossible to block DNS, because it is difficult to work in the Internet without it.

As you can see, technology that appears innocent at first glance, which is even intended for providing network security, turns into a break-in tool for the limitations imposed on you by the administrator.

If you are good at PHP or Perl programming, you can write a Web script to access the resources you need on the server. Communicating with the necessary server using the Web browser is like working with mail through the Web interface. Most mail services have this capability and most likely many of you have used it.