6.1. Introduction

The most ubiquitous transport-layer tunneling protocol, by far, is the Secure Sockets Layer (SSL)the protocol used to, among other things, secure HTML (Hypertext Markup Language) transactions on the Web. As we shall see, SSL has many applications and can easily be used to build general-purpose transport-layer tunnels. In this chapter, we examine the SSL protocol, watch its operation on the wire by means of the tcpdump and ssldump utilities, see how we can use it to build a tunnel between two programsone or both of which need not be SSL-awareand, finally, see how we can use it to build a VPN between two networks.

The first SSL specification originated in 1994 at Netscape, which was interested in a way to secure certain transactions made with its Netscape Navigator Web browser. The first version was not released outside Netscape. Later that same year, the specification for version 2 of SSL (SSL 2) was released [Hickman 1995], and an implementation appeared in Netscape Navigator 1.1 early in 1995.

Unfortunately, the SSL 2 protocol had security problems, and the Netscape implementation, in particular, had serious security flaws due to the way the pseudorandom number generator was seeded.

The seeding method and the exploit that took advantage of it are described in [Goldberg and Wagner 1996]. Because the seed was calculated from the time of day, the UNIX process ID (pid), and parent's process ID (ppid), Goldberg and Wagner were able to significantly reduce the number of possible keys to try. An attacker who had an account on the same machine and thus knew the user's pid and ppid, could recover the key in about 25 seconds. According to [Rescorla 2001], even without direct access to the pid and ppid, Goldberg and Wagner were able to discover the key in about an hour.

At the same time, other vendors were producing their own implementations. One of these, Microsoft's Private Communications Technology (PCT), addressed several shortcomings of SSL 2, had better security, and was backward compatible with SSL 2.

In late 1995, Netscape released the version 3 (SSL 3) specification. SSL 3 was a complete rewrite of SSL, which included many of the features of PCT, added new cipher suites, and introduced a closure notification that prevented truncation attacks.

Before SSL 3, it was possible for an attacker to send a forged TCP FIN to one or both sides, making it appear that less data was transmitted than actually was. The closure notification prevents this by sending what amounts to an EOF as part of the (authenticated) protocol. We'll see the close notification in action shortly.

Most browsers and servers currently use SSL 3, although as we'll see, many browsers first try to negotiate an SSL 2 connection. The latest edition of the SSL 3 specification is [Freier, Karlton, and Kocker 1996].

This document was published as an Internet Draft but never became an RFC. Netscape continues to make it available as the best written specification of SSL 3.

We'll discuss the security properties of SSL 3 shortly.

In 1996, the IETF began an effort to standardize the SSL protocol. For political reasons, the new protocol was named the Transport Layer Security (TLS) protocol. TLS is based mostly on version 3 of SSL but with enough "minor" changes to make it incompatible with SSL 3. The TLS specification was finished in 1999 and published as RFC 2246 [Dierks and Allen 1999].

At the time of this writing, SSL 3 remains the dominant protocol. Deployment of TLS has been slow, but its use is increasing. We use SSL to stand for both TLS and the various versions of SSL. We use the specific names SSL 2, SSL 3, and TLS when it's necessary to distinguish which version we are speaking about.