SSL Test

A server accelerator card (also known as an SSL card) is a Peripheral Component Interconnect (PCI) card used to generate encryption keys for secure transactions on e-commerce Web sites. When a secure transaction is initiated, the Web site's server sends its certificate, which has been provided by a certifying authority, to the client machine to verify the Web site's authenticity. After this exchange, a secret key is used to encrypt all data transferred between sender and receiver so that all personal and credit card information is protected. This process can severely overload a server resulting in fewer transactions processed per second, which means fewer sales. The server accelerator card takes over this process, thus reducing the load on the server. Server accelerator cards support a number of security protocols including Secure Sockets Layer (SSL) and Secure Electronic Transaction (SET).

A low value for this measure indicates that many SSL cards are currently Down.

The values reported by this measure and their numeric equivalents are as shown in the table:

Note:

By default, this measure reports the above-mentioned Measure Values while indicating the status of the SSL engine. However, in the graph of this measure, the states will be represented using the corresponding numeric equivalents - i.e., 0 or 1.

This measure is a good indicator of the current SSL session load on the appliance.

For an SSL transaction to be initiated, and for successful completion of the SSL handshake, the server and the client should agree on an SSL protocol that both of them support. If the SSL protocol version supported by the client is not acceptable to the server, the server does not go ahead with the transaction, and an error message is displayed.

In certain deployments, you might be concerned about network vulnerabilities between the ADC appliance and the backend servers, or you might need complete end-to-end security and interaction with certain devices that can communicate only in clear text (for example, caching devices). In such cases, you can set up an HTTP virtual server that receives data from clients that connect to it at the front end and hands the data off to a secure service, which securely transfers the data to the web server. To implement this type of configuration, you configure an HTTP virtual server on the ADC and bind SSL based services to the virtual server. The ADC receives HTTP requests from the client on the configured HTTP virtual server, encrypts the data, and sends the encrypted data to the web servers in a secure SSL session.

This measure reports of the count of those SSL sessions that are front-ended by such virtual servers.

For SSL transactions, establishing the initial SSL handshake requires CPU-intensive public key encryption operations. Most handshake operations are associated with the exchange of the SSL session key (client key exchange message). When a client session is idle for some time and is then resumed, the SSL handshake is typically conducted all  over again. With session reuse enabled, session key exchange is avoided for session resumption requests received from the client. Session reuse is enabled on the ADC appliance by default. Enabling this feature reduces server load, improves response time, and increases the number of SSL transactions per second (TPS) that can be supported by the server.

A server therefore, is said to be performing at peak capacity if the value of the Front-End SSL session reuse misses measure is low and the value of the Front-End SSL session reuse hits measure is high.

In certain deployments, you might be concerned about network vulnerabilities between the ADC appliance and the backend servers, or you might need complete end-to-end security and interaction with certain devices that can communicate only in clear text (for example, caching devices). In such cases, you can set up an HTTP virtual server that receives data from clients that connect to it at the front end and hands the data off to a secure service, which securely transfers the data to the web server. To implement this type of configuration, you configure an HTTP virtual server on the ADC and bind SSL based services to the virtual server. The ADC receives HTTP requests from the client on the configured HTTP virtual server, encrypts the data, and sends the encrypted data to the web servers in a secure SSL session.

This measure reports the count of those SSL sessions between the front-end HTTP virtual server and the backend web servers.

You can configure the back-end SSL transactions so that the ADC appliance uses SSL session multiplexing to reuse existing SSL sessions with the back-end web servers, thus avoiding CPU-intensive key exchange (full handshake) operations. This reduces the overall number of SSL sessions on the server, and therefore accelerates the SSL transaction while maintaining end-to-end security.

This is why, a large number of Backend SSL sessions multiplex attempts successes is desired. On the other hand, too many Backend SSL sessions multiplex attempts failures could imply that SSL sessions could not be reused. This in turn can result in increased full handshakes, probable session overloads on the backend web servers, and consequently, slower SSL transaction processing.