7.9. Securing the Connection

In Section 14.5 , various technologies for monitoring network traffic will be considered . These are mostly effective in local networks, with hackers preferring Internet connections because they provide more interesting material and because attacks can be carried out remotely.

How is it possible to intercept traffic between two locations in the United States from Europe? I believe there is no need for the packets' detour to Europe on their way from one U.S. location to another, and they will travel over the U.S. channels. Yet if a hacker makes his or her computer a middleman in the data transfer, sort of a proxy server, this can be done.

What confidential data can the hacker intercept when the client is viewing Web pages? Passwords, credit card numbers , bank accounts, and other sensitive information that people enter on Web forms every day, mostly without even thinking that it may fall into the wrong hands or can be intercepted. The most difficult thing here is to organize for the client to connect not to the real Web server requested but to the hacker's computer. Although people enter the addresses of the sites they want to visit as symbolic names, the actual connection is carried out using IP addresses. The task of mapping symbolic names to the corresponding IP address is performed by DNS servers. It is possible to fool the client with a fake DNS answer or a fake DNS server, thereby redirecting the traffic to the hacker's computer.

Afterwards, the computer in the middle will forward requests from the client to the real Web server and likewise return its answers to the client (Fig. 7.3). In this way, all traffic will pass through the hacker's computer.

Figure 7.3: Intercepting traffic

But this method is a thing of the past; now it is of little use because of the protection against intercepts provided by HTTPS and an SSL connection.

As you should remember, when establishing an SSL connection, any client program (for example, a browser) and the Web server exchange keys used to encrypt the ensuing data exchange. HTTPS, in addition to the public and private keys, requires signed certificates, which are issued by special companies. The client program checks the certificate and, if it is valid (the digital signature belongs to the authorized company), allows the connection to be made. While the certificates can be faked, it is practically impossible to fake signatures.

Simply forwarding encrypted data between the client and the server does the hacker no good. The only way to decrypt the traffic is to use the following technique:

The hacker generates a key pair and a certificate on his or her computer.
The client connects to the hacker's computer and exchanges keys with it.
The data sent by the client are encrypted with the key supplied by the hacker, so he or she has no problems decrypting them.
The hacker's computer connects to the Web server and obtains its public key.
A connection is established between the hacker's computer and the Web server using the key provided by the Web server.

With this arrangement, the client receives a key that was generated by the hacker and has no required signature. This means that a message will be displayed on the client's computer informing the client that the connection is to be established without a signed certificate. This is the moment most users commit a grave security lapse: Having been working on the Internet for a long time, they have tired of paying close attention to various warning messages, so they just automatically click the OK button to continue working, thus accepting an unsigned certificate.

The problem with the man-in-the-middle attack can only be solved by protecting the DNS server to prevent hackers from inserting themselves between the client and the server. Never use a proxy server whose origin you are not certain of: It may belong to a hacker, and all your traffic will be at his or her disposal.

Another thing would be training users to pay close attention to all messages displayed by the browser. But this would be difficult to achieve. To make users react to critical information, the browser would have to display it in a format different from the rest of the messages. Seeing a message about a potential danger that stands out from the rest of messages, the user will be more likely to read it. Thus, if the message about connecting to a site without a signed certificate is displayed in a critical-message format, the user is more likely to react to it and break off the connection. Although there are many sites that do not offer signed certificates, it does not mean that they are of the dot-con variety; most of them are quite respectable and protected. It simply costs money to obtain a signed certificate, and not every site owner wants to spend it. Only commercial enterprises offer signed certificates. But even these resources are not free of trouble. A signed certificate is only valid during the specified period, and if the administrator does not update it timely , the certificate lapses.

Users must remember that unless they connect to a site using a secure connection, it is not a good idea to provide credit card numbers to this site. The browser should display this warning in big red flashing letters when connecting to a server without a signed certificate.