Secure socket layer (SSL) certificates provide authentication between a server and a client computer in a Web application. Companies or businesses with a dedicated SSL certificate must host that certificate on a Web server. Heavy use of the certificate can put a strain on the machine and slow down the application.
SSL offloading takes all the processing of SSL encryption and decryption off the main Web server and moves it to a separate device designed specifically for the task. This allows the performance of the main Web server to increase and it handles the SSL certificate efficiently.
SSL offloading increases the effectiveness of the security offered by the certificates because the designated device can devote more processing time to warding off attacks. It increases the Website and application speed and prevents companies from needing to add more Web servers to keep up with the demands of a frequently used SSL certificate.
SSL termination performs decryption on the designated device, then sends the unencrypted data to the main Web server. This data passes through extra securitymeasures such as an intrusion detection system and a firewall to protect the transmission of unencrypted data. SSL bridging decrypts and checks the data for malicious code before it reaches the server. It then re-encrypts it and processes it again after the server redirects it to the designated device. The extra step slows down the process.
Problem with SSL Offloading causing traffic overhead and security issues
Now imagine the exchange of massages as a conversation like the following:
- The client asks for a website http://fu.com (without a slash at the end!)
- The loadbalancer or reverse-proxy answers the request with “I have no http:// site, but a great https:// location for you. Do you want to use that location instead?” This comes within the response location header from the proxy or loadbalancer. This is the place, which causes the further discussion…
- The client says: “Oh, great! Would you please give me the index page under the url http://fu.com ?”
- The load balancer or proxy removes the SSL certificate and relay the message as http to the webserver.
- The webserver answers “No! There is no location like http://fu.com but a location like http://fu.com/ (with a slash at the end and no https!).
- The client asks again: “Ok, then please give the page under that location: http://fu.com/“.
- The reverse-proxy/loadbalancer responses: “No! There is no location, but under https://fu.com/ (with SSL and a slash at the end) I have something nice for you.”
- The client asks again: “WTF! You damn idiot! May I have a website under that location: https://fu.com/ , please or I kill you next time I have to request you!!!”
- The proxy accepts the request of https again and replay the request to the webserver.
- The Webserver answers: “Oh, ok… well. Ok, here is your website!”
You see there is a lot of traffic and a lot of SSL offloading the loadbalancer or proxy must handle. Think about many requests and the conversation above. This will heat up your CPU a lot, because SSL offloading is hard to do for your system.
Another problem is that you will run in security issues, because the message is send out to the web without SSL and the transport to the webserver is made without SSL many times. If this is a basic authentication inside the message for a webservice for example, it wouldn’t be so nice.
If an attacker succeeds in intercepting and manipulating the redirect on the unencrypted pages, then he can perform a so-called SSL stripping attack, which allows him to listen to and manipulate the entire further communication of the client with the web service. For this purpose, freely accessible tools exist on the web.
Here you can read a little bit more about the effects: https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure
The solution to this problem is relatively simple, but efficient. In the web server configuration or in the loadbalancer correct the incorrect forwarding to the unencrypted web page. Forwarding to an unencrypted website must not take place. Simply change the location header on the webserver, in the response message, to the correct location to minimize traffic and always use SSL. This will help you avoid the many inquiries and secure communication can take place.
Workflow before fixing the location header
Workflow after fixing the location header
As always, I would appreciate your comments and will answer them as soon as possible. Thanks also to the administrators, who brought me closer to SSL offloading.