How SSL Protocol Acceleration Works
How SSL works
SSL is the standard protocol for establishing a secure encrypted link between a remote application server and the client Web browser on the local user computer. The SSL protocol secures each session link by automatically establishing connections on-demand using standards-based protocols, encryption techniques, and certificate exchange.
SSL encryption requires a certificate on the server to authenticate the identity of a server. A certificate is an electronic confirmation that you, as the owner of a public key, are who you claim to be, and that you hold the private key corresponding to the public key in the certificate.
You create this certificate by generating a certificate and sending a certificate signing request to a Certificate Authority (CA) using your public key. The CA checks with a registration authority to verify your identity and then signs and returns the certificate. You then upload the signed certificate and public key onto the server.
When a client browser visits a web site hosted on the server over HTTPS, the server offers the signed certificate and public key. The client browser verifies that the certificate is valid for the site that is being visited and that it has not expired. Then it will verify the chain of trust by looking at who has signed the certificate:
- If the certificate is a root-certificate, it will compare it against the ones shipped with the OS or browser.
- If it is a non-root-certificate, it will follow the chain of trust up each level until reaching a root-certificate.
Now the server has the private key and the client has the public key effectively creating a private encrypted tunnel that allows them to appropriately communicate by encrypting and decrypting the traffic between them. When the session is over, the connection is automatically terminated.
There are other certificate signing options
You can create a self-signed certificate, where the certificate has signed itself and therefore there is no chain of trust. The browser will issue a warning, telling the user that the site certificate cannot be verified. To continue, the user will have to confirm that they trust the site. When the browser visits this site again later, the warning will not be presented again since the user has already confirmed their trust of the site. An alternate use case, is the company that created the self-signed certificate can provide the certificate to the client users and tell them to load the certificate into their browsers. This is equivalent to confirming trust when the warning is shown. Using self-signed certificates is reasonable in situations where you want encryption but you do not need the third party verification, such as an internal system where you want your internal users to have password protection, however as the clients and the server are behind a firewall so you do not need the third party verification.
You can create your own self-signed CA certificate for signing other certificates. In this case, the certificates that your self-signed CA certificate signs will have no chain of trust. Similar to self-signed certificates, using your own self-signed CA certificate to sign other certificates is reasonable in situations where you want encryption but you do not need the third party verification. The difference is that a warning is shown to the client for each server when using self-signed certificates, whereas when using a self-signed CA certificate to sign multiple other certificates, the warning will only be shown once for all the certificates that were signed by the CA certificate, that is, once the client trusts a certificate that is signed by the self-signed CA certificate, the client automatically trusts all other certificates signed by that self-signed CA certificate.
In the case where there are multiple virtual hosts on a single server, a Server Name Indication (SNI) is used to indicate what virtual hostname the client is attempting to connect to during the handshaking process. This allows a single server to present individual certificates for each of its multiple secure websites without requiring all of the sites to use the same certificate.
How Exinda accelerates the SSL protocol
For SSL acceleration, a server-side Exinda appliance and a client-side appliance is put in line for this SSL traffic. The traffic between these appliances are accelerated. The benefits that can be gained by generic application acceleration on encrypted data are limited. For example, the Exinda WAN Memory technology achieves higher reductionmeasures the amount of redundant data that has been removed from the network, increasing capacity on clear text rather than encrypted data. However, the SSL acceleration feature is designed to overcome these limitations by transparently decrypting accelerated traffic, performing the relevant application acceleration techniques such as TCP Acceleration and WAN Memory, then re-encrypting the traffic again. This means Exinda can apply all application acceleration technologies to the traffic as if it were clear text, while still maintaining SSL connections.
The server-side appliance will act on behalf of the client in the communication between the appliance and the server and the client-side appliance will act on behalf of the server for communication between the client and the appliance. In order to decrypt and re-encrypt the traffic, the Exinda appliances must have access to the appropriate certificate and public key for each server that clients will communicate with over SSL. Furthermore, the Exinda appliances must be configured to know which servers can receive traffic that is SSL accelerated. These servers are defined by IP address and port, certificate, and other details. Only traffic to servers that are explicitly configured in this way is SSL accelerated. If the server is hosting multiple virtual hosts, when defining the server, you can define an acceleration server for each of the virtual hosts by specifying the SNI virtual host so that the virtual host name is presented during the handshake process with the appliance.
If you upload the appropriate certificates and configure SSL Acceleration Servers on the server-side appliance, the appliance will use the Exinda acceleration community feature to push these certificates and server configurations to the other appliances in the community. Configurations that have been pushed to the remote appliances will appear in the Remote SSL Acceleration Servers list on the Optimization > SSL page.
By default, the Exinda appliances are pre-loaded with several root CA certificates. The site-specific certificates will be loaded onto the appliances by the user (or distributed using the community feature). When the client attempts to access the website, during the handshake, the appliance sends to the client all of the certificates in the chain of trust.
If you are concerned about any decrypted data on the Exinda appliance, then you can choose to use storage disk encryption.
- Configure SSL certificates and private keys (or configure SSL CA certificates and private keys) to use for SSL acceleration.
- Configure the servers to use for SSL acceleration. For more information refer to Configure SSL Acceleration Servers.
- Create Optimizer policies that allow SSL traffic to be accelerated.
- If you're concerned about decrypted data on the appliance, then enable storage disk encryption.
- Ensure that the SSL Acceleration Server is ok by seeing its status on the SSL server configuration page. There is a green checkmark next to each SSL Acceleration Server that has a good state.
- On the real-time conversations page, turn on Show Policies and ensure the SSL traffic that you are interested is accelerated. If the traffic shows in a gold band, then it is processed by an accelerated policy. If the traffic has a lock icon, then it is being SSL accelerated.
If your traffic is not accelerating and you need to trouble-shoot, try the following:
- Check that the polices seem to be configured properly and that they are in the proper order. You want to ensure that another policy earlier in the tree is not capturing your desired traffic.
- Check the SSL Acceleration Server details. Ensure you are using correct spelling, etc. More troubleshooting help for disabled SSL Acceleration Servers is offered in the Configure SSL Acceleration Servers section.
- Check that the Exinda community feature has distributed the certificates and SSL Acceleration Server configuration properly to your appliance. They will appear as "remote"