The main role of SSL is to provide security for Web traffic. Security includes confidentiality, message integrity, and authentication. SSL achieves these elements of security through the use of cryptography, digital signatures, and certificates.

SSL protects confidential information through the use of cryptography. Sensitive data is encrypted across public networks to achieve a level of confidentiality. There are two types of data encryption: symmetric cryptography and asymmetric cryptography (refer to Table 1).

Symmetric cryptography uses the same key for encryption and decryption. An example of symmetric cryptography is a decoder ring. Alice has a ring and Bob has the same ring. Alice can encode messages to Bob using her ring as the cipher. Bob can then decode the sent message using his ring. In cryptography, the “decoder ring” is considered a preshared key. The key is agreed upon by both sides and can remain static. Both sides must know each other already and have agreed upon what key to use for the encryption and decryption of messages. Remember that the same key is used for encoding as well as decoding messages — thus the term symmetric cryptography.

Asymmetric algorithms use one key for encryption of data, and then a separate key for decryption. Asymmetric algorithms are more favorable than symmetric algorithms because even if the encryption key is learned in one direction, the third party still needs to know the other key in order to decrypt the message in the other direction.

Table 1: Symmetric Cryptography vs. Asymmetric Cryptography

Symmetric Cryptography	Asymmetric Cryptography (PKI)
• Symmetric cryptography uses a single key for encryption and decryption.	• Asymmetric cryptography was designed in response to the limitations of symmetric cryptography.
• Symmetric cryptography requires that both parties have the key.	• Information encrypted with one key can be decrypted only with another key.
• Key distribution is the inherent weakness in symmetric cryptography.	• Public key infrastructure (PKI) cryptography is up to 1000 times more CPU intensive than symmetric cryptography.
• Minimal CPU cycles are required to verify keys.	• The Rivest, Shamir, Adelman (RSA) algorithm uses modular arithmetic to enable the concept of public and private keys.
• Symmetric ciphers are fortified by algorithmic strength and key lengths.	• All SSL transactions begin with an asymmetric key exchange.
• SSL symmetric key lengths range from 40 to 168 bits.

With asymmetric encryption, both sides can spontaneously spawn a transaction without ever having met. This is achieved by the use of a public and private key pair. The public key of the entity is public knowledge and is used for encryption, whereas the private key of the entity remains secret and is used for decryption. PKI is the more common name for asymmetric cryptography. Although PKI is more secure, it also is more expensive in terms of processing speed. The encryption and decryption of the PKI can take up to 1000 times the processing than symmetric cryptography.

To ensure message integrity, each message exchanged in SSL has a digital signature attached to it. A digital signature is a hashed message digest with public key information. The message digest is based on the checksum of the message. The message digest is difficult to reverse. Both parties compute the message digest separately and compare the hashed results. Matching results means that the checksum was unaltered during transit, minimizing the chance of a compromised message (refer to Figure 1).

Figure 1: Digital Signatures Client sends a message Client has message and a public key Client hashes message with public key Server takes random message and knows public key Server hashes message with public key Server sends hashed message Client compares its own hashed message to server’s message If the two match, then the message has not been tampered

How do you trust the person to whom you are sending your message? SSL uses digital certificates to authenticate servers. (SSL also includes an optional authentication for clients.) Certificates are digital documents that will attest to the binding of a public key to an individual or other entity. They allow verification of the claim that a specific public key does, in fact, belong to the specified entity. Certificates help prevent someone from impersonating the server with a false key. SSL uses X.509 certificates to validate identities. X.509 certificates contain information about the entity, including public key and name. A certificate authority then validates this certificate (refer to Figure 2).

When you go to a bar or nightclub, security checks your ID to verify who you are. Your driver’s license validates your ability to drive; more importantly, however, your driver’s license is a trusted form of identity because your license was issued by a trusted third party. In the same way, a digital certificate is a mere statement of the identity of the body or individual who wishes to be authenticated. A trusted third party outside the server and client pair is needed to validate the certificate. This third party is the certificate authority. Reputable certificate authorities, such as VeriSign, are responsible for ensuring the trust of all World Wide Web entities.

In some cases it may be necessary to create a chain of certificates, each one certifying the previous one until the parties involved are confident of the identity in question. This process is called certificate chaining. Certificate chaining is important in situations where the first line of certificate authorities may not be as well known or trusted as another certificate authority. A hierarchy of trust is formed (refer to Figure 3). This hierarchy of trust is vital to the authentication of an entity.

Figure 3: Hierarchy of Trust

SSL has two distinct entities, server and client. The client is the entity that initiates the transaction, whereas the server is the entity that responds to the client and negotiates which cipher suites are used for encryption. In SSL, the Web browser is the client and the Web-site server is the server. Three protocols lie within SSL, the Handshake Protocol, the Record Protocol, and the Alert Protocol. The client authenticates the server during the Handshake Protocol. When the session is initiated and the handshake is complete, the data transfer is encrypted during the Record Protocol phase. If there are any alarms at any point during the session, the alert is attached to the questionable packet and handled according to the Alert Protocol (refer to Figure 4).

Figure 4: SSL Protocol Stack

The client always authenticates the server, and the server has the option of also authenticating the client. In general, Web servers do not authenticate the client during the Handshake Protocol because the server has other ways to verify the client other than SSL. For e-commerce, the Web-site server can verify the credit card number externally from the SSL session. In this way, the server can reserve precious processing resources for encrypted transactions.

During the Handshake Protocol, the following important steps take place: the session capabilities are negotiated, meaning the encryption (ciphers) algorithms are negotiated; and the server is authenticated to the client.

SSL uses symmetric cryptography for the bulk data encryption during the transfer phase; however, asymmetric cryptography, (that is, PKI) is used to negotiate the key used for that symmetric encryption. This exchange is critical to the Handshake Protocol. Note that the server may optionally ask the client to authenticate itself. However, it is not necessary to the protocol. Table 2 gives the steps of the Handshake Protocol.

The encryption for all messaging in SSL is handled in the Record Protocol. This protocol provides a common format to frame all Alert, ChangeCiperSpec, Handshake, and application protocol messages. SSL records consist of the encapsulated data, digital signature, message type, version, and length. SSL records are 8 bytes long. Because the record length is fixed, encrypted messages sometimes include padding and pad length in the frame, as shown in Figure 6.

Figure 6: An Example of an SSL Record

As mentioned earlier, the Alert Protocol handles any questionable packets. If either the server or client detects an error, it sends an alert containing the error. There are three types of alert messages: warning, critical, and fatal. Based on the alert message received, the session can be restricted (warning, critical) or terminated (fatal).

The traditional deployment of SSL in a Web environment consisted of a Web server with an integrated SSL module (an SSL-enabled network interface card [NIC]). The client initiated a session with the server, and the server was directly responsible for the SSL termination. This process adds load to the server, which is already responsible for all Hypertext Transfer Protocol (HTTP) information that is sent to and received from the client. The Web server processor is shared across both the SSL processing and HTTP processing. Figure 7 displays a traditional SSL deployment.

Figure 7: Traditional Deployed SSL

Server performance is predicated on the performance of the system as a whole. Cryptography is expensive. The cost of using SSL can dramatically slow down the Web servers and, therefore, interfere with the Web site itself. The two relevant cryptographic operations of SSL occur during the data transfer phase. Remember that the data transfer phase occurs at the record protocol level in SSL. The SSL records are encrypted, and a digital signature of the Media Access Control (MAC) is included with each record transferred. The record encryption and the record MAC signature operations account for most of the cost during data transfer.

The other process that slows down SSL is the public key cryptographic operations that are associated with the SSL Handshake Protocol. An SSL handshake occurs at the initiation of every SSL session requested of the server. The session key exchange accounts for most of the cost. One way to cut down on the number of handshakes is to use session resumption. This way, the server maintains a cache of clients. However, this cache can grow to be very large if the server is talking to a large number of clients. In this case, the memory and CPU can be at maximum capacity just to maintain session caches because a Web server may be handling hundreds of transactions a minute, meaning possibly hundreds of session resumptions as well. The ramifications include a slowdown in the Web server overall, in both HTTP and SSL transactions, which could turn into down time for the server as well. This slowdown—or even down time—translates into lost revenue that potentially can be generated during that time.

SSL accelerators can be implemented in a Web server infrastructure or deployment in order to offload the servers from the expensive part of SSL transactions. The SSL accelerator serves as a central point for negotiating handshakes and also encrypting and decrypting data. This allows the servers to process other HTTP processes unrelated to SSL and remove the load off the Web server. In most cases the SSL accelerator is typically connected to a content switch in the path between the client and the server. This external accelerator is commonly referred to as an SSL termination device. Other SSL accelerator modules can be integrated into the content switch for the termination of SSL traffic.

The most recommended SSL design to deploy is called nontransparent, which is also referred to as “proxy mode SSL” and “nontransparent proxy mode.” Transparent is sometimes referred to as “transparent proxy mode.” Nontransparent mode scales well and is a more secure deployment design. In a nontransparent design, the client source address does not get to the server. This setup is beneficial because it provides privacy on the client side and scalability on the server side.

Uptime for servers is critical for all business. For example, it is important to the business of an online shopping site to have high availability for its servers at all times—any down time can be considered a loss in revenue because purchase transactions cannot be completed. If an SSL accelerator fails, the connection should be load balanced to the next accelerator. In the high-availability configuration, shown in Figure 8, the user should experience no noticeable change in his or her session because any failure in equipment is automatically rerouted to the backup SSL accelerator.

Figure 8: High Availability

As stated previously, the most recommended design for deploying SSL is nontransparent because this architecture has the most flexibility and scalability. User tracking is done through cookies and optionally by having the SSL accelerator log the client addresses to a syslog server. This cache of client addresses allows the capability to not only track but also resume sessions that have been terminated gracefully. This saves processing overhead, thereby freeing more bandwidth for even more SSL transactions. SSL accelerators can also be shared between applications and content switches.

The reason it is called nontransparent is that the source addresses of all the packets decrypted by the SSL accelerator have a source address of that SSL accelerator. From the server perspective, the request came from the SSL accelerator. Some customers initially had a problem with this setup because they usually track the client’s source address on the server. Some SSL termination devices still have the ability to send the client’s source address to a syslog server for tracking purposes. However, with cookies, you can gather much more granular information about a client. In addition to IP address information, cookies can track where the client goes to and comes from on a Web site, as well as personal information (that is, passwords, shopping lists, and user preferences). Table 3 shows the packet flow for the nontransparent design, and Figure 9 shows the nontransparent design architecture.

Figure 9: Nontransparent Design Architecture

An SSL termination module is an external SSL accelerator that is co-located within a device other than the Web server system itself. The module is still solely responsible for all SSL transactions, but it resides within another device with ample memory and CPU processing speed. This other device can be either another router or a switch within the network. Today content switches that have SSL termination modules fully integrated are available (refer to Figure 10).

Figure 10: Switch with Integrated SSL Module

An SSL accelerator that is connected to the content switch in the Web server environment is a termination device. This device is external from the other servers in the network and is solely responsible for SSL transactions. This is another way to offload the network by using an external device with more available resources (both memory and processing power) to handle SSL transactions. In this way, the termination appliance can be dedicated to handle the SSL transactions alone. This does not interfere with any network processing time on the switch or Web server. Figure 11 shows the packet flow using an external SSL termination device.

Figure 11: Packet Flow of SSL with External SSL Termination Appliance