SSL

SSL is a protocol developed by Netscape in the early 1990s that allows certain applications running over TCP/IP to be encrypted, as well as providing authentication mechanisms. It is typically used across public and private networks. SSL has evolved into Transport Layer Security (TLS) with the guidance of the Internet Engineering Task Force (IETF). We will refer to this protocol as SSL throughout the book, as this is the accepted terminology. SSL sessions encrypt the data portion of the session providing no clear content other than the IP, TCP, and SSL headers that can be used for persistence. For example cookies, URLs, and so forth will be encrypted, as they reside in the data portion of the packet.

SSL is a fairly complex protocol and in order to provide insight into this important protocol we covered the basics in Chapter 3, Understanding Application Layer Protocols , which will be extremely helpful when we discuss SSL Offload in this chapter. However, should more detailed information be required, many good articles and books are available on this subject exploring it in far more detail than we have here.

SSL Session ID Persistence

As we have seen, the use of IP address persistence can have many issues if mega proxies are being used, but would work when using SSL because any other information you might want to use is encrypted. Using hashing in this scenario would depend on network design. If used in a network where all users have unique addresses, hashing is a simple and effective method to maintain persistence. Unfortunately, in most cases, this is not always possible, and other more intelligent mechanisms are required. Now that we have seen how SSL works and the importance of the SSL Session ID, we can understand why it makes session persistence really simple when other unique identifiers are encrypted.

The SSL Session ID is part of the unencrypted SSL header, and each time a client connects to the server and sets up a SSL session, a unique SSL Session ID is used. This is a simple and easy to implement method against which to ensure distributed persistence when all clients are using the same SIP. Unfortunately, using SSL Session ID persistence is flawed, not because of the content switch's ability but rather the functionality of the Microsoft Internet Explorer (IE) browser. In order to enhance security, the MS IE browser renegotiates the SSL Session ID every two minutes. This provides erratic and unstable behavior for sessions requiring persistence that are longer than 120 seconds. Windows 2000 browsers have been changed to allow the SSL Session ID to wait 60 minutes before renegotiating the ID with the server. All Netscape Communications browsers do not exhibit this behavior. This again does not resolve this issue permanently, and as Microsoft's IE browser is one of the predominant browsers used, the use of SSL Session ID for persistence is basically obsolete unless you can ensure that all users connecting to your Web site are using Netscape browsers.

We are now basically faced with the issue that we cannot guarantee persistence in an encrypted session unless we use hashing. This hinders the ability to provide an effective service. However, this can be fixed. It does require additional hardware and design, but allows for intelligent persistence in encrypted sessions.

Fixing the Model with SSL Offload

Moving the point of SSL processing from a server to a dedicated device has many benefits. Let's look at these benefits before we explore the workings of SSL offload and the different models and deployment scenarios.

One of the primary benefits is a massive increase in performance. As we all know, a slow responding site can be extremely frustrating and in some cases can be the difference between doing business or moving on to a site that provides rapid and efficient service. Many studies have been carried out to try to determine the cost of a slow site when performing online transactions, and while the results indicate that many millions of dollars are lost, the only true gauge is how you feel and what you would do if faced with a painfully slow connection. Human nature dictates that we would react differently depending on the day or mood. What we all know is that the faster a site responds to our needs, the better we feel. Therefore, our goal should always be to enhance the user 's experience.

Unfortunately, SSL is typically a slow performer. SSL transactions, due to their nature, need to be encrypted and decrypted. As discussed earlier, the larger the encryption algorithm and key, the more processor intensive they are. Processors have a finite amount of capacity, and as we increase SSL sessions into a site, the more processing a server has to do. Remember, it is not only the initial transaction that needs to be decrypted, but all subsequent ones as well. Sure, the setup process is by far the most compute intensive, and it is this reason why servers tend to buckle under heavy SSL loads. The setup session rate can very quickly bring a server to its knees.

Servers all have the ability to listen on TCP port 443 for SSL connections. On completion of the three-way handshake, it is up to the server to perform the key exchange and decryption. Most servers are also processing HTTP traffic, responding to health checks from a content switch, answering management requests regarding availability, and generally keeping their house in order with all the other processes required by the operating system. All of this requires CPU cycles. With heavy SSL session setups, the CPU can quickly become swamped, and the server not only degrades the service for SSL but as all other processes are competing for a slice of the CPU, they in turn will begin to decline. This has a knock-on effect and ultimately affects the user who is trying to access your sitethe one person you want to keep happy. Therefore, SSL can impact an entire server and all its processes in busy sites. The secret is to offload this function.

SSL Offload Types

How do we perform SSL offload without degrading server performance? A popular method has been to install an SSL encryption card within the server itself. This is a hardware-based solution and has its own CPU for carrying out all SSL encryption and decryption. This relieves the CPU of the server from having to perform this, and allows it to concentrate on serving files and maintaining an adequate level of speed. In small organizations with a single server, this solution is seen as cost effective and provides an increase in performance that cannot be beaten. However, using SSL cards in larger sites comes with a few issues that are not insurmountable, but definitely require a fair amount of thought before committing to that solution.

SSL cards do not provide the same performance increase as dedicated SSL offload appliances because they are using the processing capabilities of the host server. In addition to this limitation, and probably one of the most crucial issues in large sites, is the management of certificates. Some leading-edge dedicated SSL offload appliances can provide central management of these. While it may only be a single certificate to begin with, as the site grows and more services are required (remember that certificates are tied to domain names ), more certificates are required. Another point to remember is that the cards are third-party products; operating system upgrades could affect the drivers and the workings of the card. Therefore, care must be taken when performing an upgrade. This may require that additional software be loaded to allow the card to function.

Dedicated SSL offload appliances allow for a huge increase in performance as they perform the task themselves , which allows a server to perform its function (i.e., respond to requests) without impacting performance. There are many appliances dedicated to this on the market today, but due to the deployment models supported, not all are created equal.

A SSL offload appliance's sole purpose in life is to listen for SSL traffic, typically on TCP port 443, and encrypt and decrypt this traffic. How this is done differs from vendor to vendor but ultimately the end result is the same.

1. Traffic ingresses the device, is decrypted, and is sent to the server.

2. The return traffic enters the device, is encrypted, and is sent back to the client.

This occurs until the session is complete. The issue all designers have to address is how to get the SSL traffic into the appliance. Simple, place the appliance in the data path . However, this creates performance and resilience issues. What if the device fails, then all SSL and other non-SSL traffic to and from the site ceases. In addition, all non-SSL traffic has to pass through the appliance, thus degrading performance, and we are almost back to where we started. It is much better to let the SSL appliance concentrate on what it is designed for. In this case, however, it is the SSL processes that are compromising non-SSL data. To overcome this, it is easy to place a pair of these SSL appliances in parallel as can be seen in Figure 7-7. This provides a resilient route in to and out of the site. Again, the scalability of this approach has to be questioned. Not only is the above still true, but also a single failure of an SSL appliance will degrade access to and from the site by 50 percent.

Figure 7-7. SSL offload appliances in parallel offer some resilience, but any failure of an appliance will impact half of the network traffic.

Adding additional devices in parallel merely adds complexity without providing the benefits of a device that sits out of the data path. However, many vendors have manufactured these devices, and deploying them in parallel, while not optimal, is still seen as a step up in performance from SSL cards in the server. The best method is to place the device out of the data path and rely on another device to intercept and forward only SSL traffic to the appliance. This method is by far the most efficient and allows for performance, scalability, and resilience unmatched by the other methods .

To make this work, a content switch is required. A content switch has the ability to understand Layer 4 information. Most switches are able to perform this function by redirecting TCP port 443 traffic into a SSL offload appliance without impacting other protocols. By sitting out of the data path, the SSL offload appliance does not have to forward other traffic. Most importantly, if it fails then there is no degradation to the site for all other protocol types. This allows designers to deploy this method, understanding that they only need to provide enough capacity to cater for SSL throughput only.

Let's now look at how this is done. We'll also examine some of the design pitfalls and benefits that can be achieved by implementing this.

To begin, you need a content switch and it has to sit in the data paththis is true for all content switches as discussed in previous chapters. There are a few approaches that can be used to send required traffic to the SSL offload appliance:

• Redirect all traffic with a specific IP address

• Redirect all traffic on TCP port 443

• Sending all traffic using a combination of both

Using the IP address only method is typically not used, as most sites use the same domain for both HTTP and SSL ( HTTPS ) traffic (e.g., http://www.foocorp.com and https://www.foocorp.com ), which would break this specific deployment model. Once the content switch has determined the criteria, it forwards the traffic on by maintaining the source and destination IP addresses. The only thing that should change is the destination MAC address. Some SSL appliances can act as a proxy and therefore are seen as the end device to the client and the source device to the server. Using proxies has its advantages and disadvantages. However, most sites are not fond of using the SSL appliances as a proxy, as all requests are seen as coming from the SSL offload appliance and not from the actual user. This makes tracking and logging difficult. We will discuss ways to overcome this later in the chapter. For now, let's see what happens to the traffic from here on.

1. Packets are forwarded to the SSL offload appliance with the DIP being that of the domain that the user requested .

2. The SSL offload appliance performs the three-way handshake back to the client and then begins the intensive task of exchanging keys and agreeing on a cipher spec as discussed earlier in the chapter. All this time, the backend servers are unaware of this session.

3. On completion of the SSL handshake, the device then creates a new TCP session with the backend servers on another unencrypted port. This can be configured on any port.

4. The server receives the request in clear text, carries out the requested function, and sends the response back to the client. Because the server has no knowledge of the SSL offload appliance, it will send this back to the client on the "new" unencrypted TCP port.

5. The content switch intercepts this and based on its session table forwards this back to the SSL off load device that originated the initial session.

6. The SSL off load device, using its session table, encrypts the data and sends it back to the user over SSL with all the right TCP acknowledgement and sequence numbers .

7. This continues until the session is complete.

While it appears that there is an increase in processing, the ability to split the load and have different devices providing this service can increase the SSL performance from 20 to 50 transactions per second on a traditional server with no SSL offload ability up to the 750,000 markdependent on offload appliance and deployment model. This far outweighs any perceived overhead and latency that might be introduced by the content switch and SSL offload appliance. Figure 7-8 shows a resilient SSL offload design.

Figure 7-8. Resilient SSL offload design offers true redundancy, as the appliances are not in the data path and will not impact network traffic.

One issue that is often raised is that of using a clear TCP connection for the decrypted traffic from the SSL offload appliance into the backend servers. This is seen as a potential security breach, as data that should be secure is now flowing over your network in an unsecured fashion. Sure, this is true, but is often allowed since it takes place within a secure data center. The perception is that if people can trace this, they have to have access to the data center. If they do, then they typically have access to the backend servers where the "crown jewels " are stored, and performing a packet capture is irrelevant as access to the servers and their databases becomes the major concern. Saying that, however, there are organizations that require true end-to-end encryption, and in some cases, particularly financial companies, this can be a regulatory requirement. Using an SSL offload appliance at first glance appears to have no benefit, as the server still has to decrypt the data and therefore has to perform those compute intensive transactions that we have been desperately trying to minimize over the last few pages. While this is certainly true, we mustn't forget that the SSL offload appliance still plays an extremely important part in this process. For starters, the SSL offload device is the only thing that can actually decrypt the traffic, and while it is still inside the device (therefore secure), it can scan for cookies or any other Layer 7 parameter defined. Once it has found a match, it can maintain persistence using the associated values as seen in the section about cookie persistence earlier in this chapter. It will then encrypt the data and send it to the correct server, thus maintaining persistence on information that is normally considered encrypted in an SSL transaction. It should be pointed out that not all vendors are able to implement this solution today and some provide a clumsy approach to this, as it sends clear text out over the infrastructure albeit for a small amount of time. The goal of end-to-end encryption is to ensure that no clear text from a secure session ever traverses the network.

While this solves the persistence problem in an end-to-end encryption session, it does not appear to decrease the backend servers' load. Let's look at the ways around minimizing the load on the servers for SSL traffic.

Backend Encryption

To achieve this, there are multiple methods that can be used. One of the easiest to implement is to use a very low encryption strength for the backend servers so they do not have to perform such a compute intensive function for every connection. This adheres to the requirement for end-to-end encryption, but still forces the server to create and tear down an SSL session for each user request. This can negate the effects of carrying out end-to-end encryption, as busy sites may receive so many new user requests that the CPU may still become the bottleneck.

Another approach makes use of "old" connections. When a new session has been created and then another new session is started, the server and user will always try to reuse their existing keys to minimize SSL session setup. With the SSL offload appliance actively participating in all SSL sessions, it has an understanding of sessions that have expired and has the ability to put these aside for later use. This is known as connection pooling or connection splicing . This method requires that the SSL offload appliance must act as a proxy. Again, for logging purposes, this is not always acceptable, but we will discuss later how to overcome this in a secure encrypted environment.

When a new session is created between the SSL offload appliance and the user, the offload appliance looks in its pool of unused, but still potentially active sessions to the backend servers. It selects one and performs the session setup reusing the key from the original session. As discussed earlier, this makes a huge difference to performance, as it is the new key exchange that requires the most computing power and this process is no longer needed. The server can receive encrypted sessions without worrying about the huge CPU overhead required for new session setup. This is an ingenious method and one that provides true backend encryption without compromising the performance associated with servers and SSL termination.

Let's now address the final point in thishow we provide the ability to perform logging, when using the SSL offload appliance as a proxy.

Every session that is created has a unique Session ID that can be forwarded within the HTTPS header to the backend server. The source IP address can also be forwarded to the server using the X-Forwarded-For header. This provides the ability to determine how many unique connections were used and allows network and server administrators to provide accurate reports on user connectivity in a secure, encrypted environment.