The Secure Sockets Layer

SSL technology was first developed by Netscape in 1994, then standardized by the Internet Engineering Task Force (IETF) in 1996. SSL is a security protocol that provides private communication over the Internet or a corporate intranet. Its purpose is to allow client and server applications to communicate in such a way as to prevent eavesdropping, tampering, or message forgery. It does this by encrypting data carried by transport protocols such as Transmission Control Protocol (TCP).

The Two Layers of SSL: Record and Handshake

SSL itself is composed of two layers: the Record Protocol and the Handshake Protocol. The Record Protocol makes sure the connection is private, using symmetric cryptography such as Triple Data Encryption Standard (3DES) or RC4 (Ron's Code 4—an RSA variable-key-size encryption algorithm developed by Ron Rivest). It also ensures that the connection is reliable, using secure hash functions such as Secure Hash Algorithm (SHA) or Message Digest 5 (MD5—a one-way hash algorithm) for keyed message authentication code (MAC) computations.

The Handshake Protocol allows the server and client to authenticate each other by utilizing asymmetric or public key cryptography such as Rivest-Shamir-Adleman (RSA) encryption or electronic data handling (EDH). This authentication process, known as handshaking, allows the server and client to negotiate a shared secret that is secure. This in turn ensures that the communicated negotiation is reliable.

SSL Events

During any transaction completed over the Internet—whether it is a consumer purchasing online or two dotcoms completing a transfer of data—the first step is to establish a connection through the Internet. This is the part known as the handshake. If it is to be a security-conscious transaction, the initial contact can be passed on to a secured connection. The URL sometimes indicates whether a transaction is secure: The unsecured connection is labeled http:// and the secured one is denoted by https://.

When the need for security is established, encryption and decryption starts to take place on the back end of the Web server. All data coming from the user is encrypted and then decrypted only on the receiving server—as though a virtual private network exists for this one secured connection. This is demonstrated in Figure 16-1.

The downside is that it is a huge drain on CPU cycles. The difference in processing power needed between secured and unsecured transactions is substantial.