Thanks for replying Mike. It turns out the FIPS performance wasn't really the issue. After turning on debugging and taking the time to carefully read through the stunnel.log output, it turns out the open file limit and max user process limit was choking the performance of stunnel. After adjusting the limits, performance has returned to acceptable levels. It does take a while for stunnel to "warm up" after a restart but after a minute or two, it seems to work just fine. Thanks again for replying.
Maybe as a suggestion, a quick note on the stunnel performance page would be nice. I did stumble across that page while searching for a fix and saw that stunnel should be able to handle the load it was getting. I just didn't know how to fix/tune it.
Thanks again!
Owen
On Thu, Jan 12, 2012 at 2:35 AM, Michal Trojnara
<Michal.Trojnara@mirt.net> wrote:
Owen Ching wrote:
we're using a rackspace cloud machine to run stunnel and haproxy. we're using the x-forwarded-for stunnel patch for now with plans to upgrade to send-proxy method once haproxy 1.5 is considered the stable branch.
So I built one machine and ran into the "FIPS_mode_set: 2D06C06E: error:2D06C06E:FIPS routines:FIPS_mode_set:fingerprint does not match" error message.
Failed FIPS fingerprint verification indicates a problem with your OpenSSL build rather than a problem with stunnel.
Make sure to read OpenSSL FIPS 140-2 User Guide before you compile your OpenSSL in FIPS mode.
So I changed the config to fips=no and stunnel started up but the https seems really slow (multiple browsers).
It's hard to say anything without your stunnel.conf, the output of stunnel -version, and a sample of your log files.
Options with serious performance impact include:
- TIMEOUTclose (should be set to 0 to work properly with buggy Microsoft SSL implementations)
- compression
- libwrap
Best regards,
Mike
_______________________________________________
stunnel-users mailing list
stunnel-users@stunnel.org
http://stunnel.mirt.net/mailman/listinfo/stunnel-users