Chapter 6. Securing the Wire

Raw TCP packets flowing through a data network may be incomprehensible, even invisible, to a normal user fostering a sense of security, but in reality, the data in these packets are very accessible to those with the appropriate tools and know-how. The data networks over which these packets flow were not designed to protect the information from malicious folks and provide little or no security. With the help of programs freely available over the Internet, one can easily view, analyze and filter, on a normal PC, all the data being exchanged by machines on the same LAN. What it means is that a rogue neighbor, subscribing to the same cable or DSL ISP (Internet Service Provider) as you, can easily collect your account names and the passwords on different websites, including those from your online broker or bank, without you ever being suspicious. In fact, even if your neighbors are all perfectly honest people, it is possible that someone sitting across the ocean may take control of a machine and snoop over all the traffic. Similarly, a mischievous employee connected to an office LAN can watch all sorts of e-mail communication among coworkers and senior company officials on a normal work PC, without causing any special attention.

Outside the LAN, Internet traffic flows through a number of routers and gateways controlled by different organizations. People who have access to these systems, either legitimately or illegitimately, can collect the data, and in some cases even modify it or route it to different destinations.

Recently introduced wireless LANs offer even less security, as one can catch signals even without being physically connected. Imagine a CEO downloading confidential e-mail messages in a conference hall over a wireless LAN and some crook surreptitiously collecting all this information and benefiting from it in the stock market or in some other way.

To make matters worse, a number of widely used application protocols layered over TCP/IP, such as TELNET, FTP, SMTP and HTTP, make no attempt to protect the application data or even the account names and passwords. Essentially, communication using these protocols is not confidential (can be seen by others), is vulnerable to tampering (can be modified), and does not provide strong authentication of end points (end-point addresses can be faked).

During the early days of the WWW (World Wide Web), these security concerns were a major stumbling block for wide adoption of e-commerce, as it required transmission of sensitive financial information such as bank account numbers and passwords, credit card information and so on. in clear text. In response, Netscape Communications, an early pioneer in this area and now part of AOL Time Warner, developed SSL protocol, a layer over TCP,^[1] to secure data exchange between two communicating end points. This protocol has been widely adopted and has become the de facto mechanism to secure the exchange of sensitive information over the Internet.

^[1] SSL specification does not mandate TCP but assumes only a reliable, connection-oriented transport. However, in practice, almost all implementations are for TCP.

SSL is an important piece of the overall puzzle of system security, providing the much needed network security. Other protocols also exist but none has achieved the same level of adoption. It is also an excellent example of using basic cryptography and PKI to meet higher-level system security needs. This chapter is devoted to the discussion of SSL protocol and the Java API to develop SSL-enabled programs. The example programs can be found in subdirectories of %JSTK_HOME%srcjsbookch6. Continuing the tradition of building a more functional and usable tool around the example programs, we present ssltool, a tool that can run as an SSL client, server or proxy and can be used to explore the Java SSL environment.