Forum Discussion
LanceLyons
Cirrus
CirrusSSL Full Proxy - SSL Re-Encryption performance degradation
Hi, We have traditionally been a shop that used SSL encryption to the F5 and decrypted text to webservers (https to F5 and http to webservers). We are being asked to encrypt the full route. We also use host headers for irule redirections in some cases and for persistence.
With this being said it seems like our only option is SSL decryption at the F5 and re-encryption back to the webservers.
with this extra encryption decryption, is there any performance degradation for sites that get high traffic? Any documentation on this specific issue?
thanks in advance.
Hello LanceLyons , Kai_Wilke provided a full list what can cause you such issues and if this helped please mark his reply as a solution. Outside of that if you are using a hardware device maybe see if hardware ssl ciphers are used for better performance as mentioned in https://support.f5.com/csp/article/K75983426 / https://support.f5.com/csp/article/K50459385 / https://support.f5.com/csp/article/K13213 and the /var/log/ltm if you are hitting some license limit for example.
- Kai_Wilke
MVP
Hi Lance,
the performance impact is hard to guess.
We would need to get more details what "high traffic" means.
When it comes to SSL encryption its also important to understand if your "high traffic" means a couple long living session with high troughput or high connection setup rates with short living session with little troughput. Bandwidth is most likelynnot killing your CPU, key exchanges are a different story...
Its also important to know if you use one of the bigger F5 appliances including SSL-Offloading cards, or if you use lets say LTM-VE units on an slightly overbooked hypervisor.
Beside of this deep analytical and sometime esoterical approach, we could just try to listen to our guts. If lets say your CPU is right now on 20% with single-sided SSL encryption, you will most likely not end having 40% after enabling it... It would be just slighly above 20%... On the other hand if your CPU peeks already at 70% you are probably shredd your LTM if you going to put even more load on your CPU.
I assume your RPS graph is not 24/7 a constant line. So how about just testing server-side SSL in non-peek hours? Real world performance data is probably better than any mild guesses...HTH and Cheers, Kai
- Nikoolayy1
Hello LanceLyons , Kai_Wilke provided a full list what can cause you such issues and if this helped please mark his reply as a solution. Outside of that if you are using a hardware device maybe see if hardware ssl ciphers are used for better performance as mentioned in https://support.f5.com/csp/article/K75983426 / https://support.f5.com/csp/article/K50459385 / https://support.f5.com/csp/article/K13213 and the /var/log/ltm if you are hitting some license limit for example.
Hi LanceLyons ,
No issues from F5 perspective as ( irules , loadbalancing and persistence shouldn’t be impacted ) because F5 interested in decrypting traffic that coming from client-side to deal with http payload decrypted.
> when you configure server ssl or ssl bridging you re-encrypt traffic again and directs it web servers encrypted , F5 hasn’t issues in this scenario , you need only to check the server itself , if it affords the process of decryption again as you know in " ssl offloading " you let F5 to be the only hop which performs decryption and offloads servers to do this exhausting task.
> usually I performs " SSL bridging (configure client and server ssl profiles )" with our customers , and we have not faced any issues regarding server ssl to re-encrypt traffic again.
Regards
LanceLyonsThanks Mohamed,
Have you all noticed any performance degradation to heavily used websites from an end user perspective with the decryption at f5 and reencrypt at f5?LanceLyons ,
No , I performs ssl bridging for high traffic virtual servers , these virtual servers serves public services over internet for ISPs and there is no issues regarding it server-ssl or re-encrypting traffic towards web-servers.
> I always offer them not to do this to lighweight the headache on webservers.
> to be sure , cofigure it and monitor your CPU periodically.
Regards
