When does one make a call if SSL Offloading needs to be done or not?

Hi Rameshr,

as a security guy I would recommend, to not SSL-Offload everywhere, unless there is a valid reason to do so (e.g. Network IDS, etc.).

Note: With SSL-Offloading im refering to those HTTPS-to-HTTP bridging scenarios. Using SSL-Offloading modules (Hardware Acceleration Cards) and Layer7 SSL-Inspection in a HTTPS-to-HTTPS bridging scenarios is fine and not covered by my opinions...

Pro SSL-Offload

• Less CPU overhead on your F5 and Backend servers (the saved CPU cylces are somewhat less esp. when using OneConnect)
• No administration overhead for deploying/maintaining SSL-Certs on backend servers.

Contra SSL-Offload

• More complex content switch rule set (e.g. enabling X_Forwarded_Proto/Front-End-Https support via additional headers, possible Header and STREAM rewrites for incompatible applications)
• You start to send confidential data (e.g. Passwords, Cookies, etc.) in clear text within your internal network.

Quote from the Internet: In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more. -- Adam Langley (Google)

Cheers, Kai