What is SSL?
SSL stands for Secure Sockets Layer. It is a protocol that enables secure communications on shared networks like the Internet by providing server authentication, data encryption and message integrity.
SSL Certificates are provided to the servers/websites by Certificate Authorities (CA). These certificates are provided only after due verification of the domain name, domain ownership, physical address, company incorporation certificate etc (depending on the terms of the CA). So, when a user is visiting a website through an Internet browser, there appears a lock symbol at the bottom of the browser if the website has a digital certificate. When that lock symbol is clicked, further information on the website/ certificate authority/ type of encryption etc are displayed. So, people can verify this information before doing any commercial transactions etc.
Secondly, all the communications between the SSL-protected website and the users (web-browser) are encrypted. Most of the modern web-browsers can decrypt these SSL sessions themselves, but on the server side, generally there are so many connection requests and a bulk of them might involve SSL processes like SSL handshaking (deciding which encryption type can be used etc), SSL message decryption etc as SSL is used for basic processes on the Internet like User-name/Password authentication, Credit card payment transactions and other secure processes.
Why SSL processes are considered resource hungry?
SSL processes are an additional computational requirement for the server processors, as each message needs to be decrypted in addition to the initial SSL handshaking. So, the server processor’s load increases. Secondly, the generic x86 based processors of the servers are not specialized/efficient in doing the repetitive computation intensive processes like SSL decryption. So, the server is not able to perform the job of processing for requested client information to its full capacity, in such a scenario.
To solve this problem, separate ASIC (Application Specific Integrated Circuit) processors were developed which are limited to performing only the repetitive and computation intensive SSL processes but are very efficient for performing such operations, when compared to generic x86 based processors. So, if the SSL processes are offloaded to such special processors, the servers could allocate their processors to manage the original applications/web page loading requests etc.
PCI based SSL ASIC Cards for the Server:
The above mentioned SSL ASIC processors were manufactured as PCI based add-on cards for the servers. So, now all the SSL processes can be offloaded by the server to these ASIC processors so that the server’s applications can be processed at full capacity. This is the best solution for single server applications/smaller websites. But for larger websites which needs multiple ASIC processors, each come at additional cost and every server needs a separate ASIC processor. The cost of the digital certification license also goes up as it needs to be bought separately for each server.
Application Delivery Controllers and SSL Offloading:
When there are many servers to serve the users of a single website (due to very high traffic etc), Application load balancers are used for distributing the load across these servers. Of course, this is just one function of an Application Delivery Controller – click here if you want to read the other functionalities of an Application Delivery Controller.
So, when an Application Delivery Controller(ADC) is used, it is better to offload the SSL processes to the ADC, which has an integrated SSL ASIC processor to do the same. Now, there is only one higher capacity processor to take care of the entire SSL process load and only one digital certificate to manage. There is one more advantage of offloading the SSL processes to the ADC – Connection persistence for SSL connections.
In certain secure processes like shopping cart (online purchases), the user needs to be connected to the same server till the entire session is elapsed (generally check-out). But when an ADC is used, the users may be distributed to other servers also for each request (for load balancing). So, in these special cases, ADC identifies the application, and keeps such visitors in the same server. This was initially done based on the user IP addresses, but with the advent of proxy servers and NAT, that became ineffective. So, these days, cookies are forwarded to the user browsers either by the ADC or application servers and these cookies are returned by the browsers while reconnecting and hence helping the server/ADC to identify returning visitors for particular applications and keep them connected in the same server.
In SSL environments, it becomes difficult to inspect the cookies. But in SSL v3, the SSL Session ID (which is a unique 32 bit identifier) is moved out of the encrypted portion in to the clear. So, the ADC is able to identify this identifier and hence balance the traffic appropriately. But in certain newer browsers, even this Session ID is changed every two minutes. So, if the SSL decryption is done in the ADC itself, the ADC can interpret the data/cookie information as it is in the clear now(out of the encrypted state).
SSL can be used for other online applications which needs sensitive data to be transferred over the Internet as well, than just restricting the same to user-name/password verification and credit card transactions. And SSL offloading can help secure the whole website as well, instead of securing it in parts.
In case you have any questions, you can contact us using the contact form or leave a comment below. You can also subscribe with your email address (on the right side of this site) to get intimated when a new article is published on this site.