Yesterday I’ve updated a CentOS 6.6 VM with a simple yum update. A couple of packages were updated and to be honest: I haven’t checked which packages were updated. Today I noticed that an application, that uses a secure tunnel to connect to another application, doesn’t work. While browsing through the log files, I found this message from Stunnel.
LOG3[1145:140388919940864]: SSL_accept: 14076129: error:14076129:SSL routines:SSL23_GET_CLIENT_HELLO:only tls allowed in fips mode
I rised the debug level and restarted Stunnel. Right after the restart, I found this in the logs.
LOG5[1385:140679985747904]: stunnel is in FIPS mode
LOG5[1385:140679985747904]: stunnel 4.29 on x86_64-redhat-linux-gnu with OpenSSL 1.0.1e-fips 11 Feb 2013
So Stunnel was working in FIPS mode. But what is FIPS and why is Stunnel using it? I recommend to read the Wikipedia article about the Federal Information Processing Standards (FIPS). To be precise, Stunnel follows FIPS 140-2. My stunnel.conf is really simple and there’s nothing configured that is, or might be related to FIPS. A short search with man -K fips led me to the stunnel man page.
fips = yes | no
Enable or disable FIPS 140-2 mode. This option allows to disable entering FIPS mode if stunnel was compiled with FIPS 140-2 support default: yes
This explains a lot. FIPS is enabled by default with this version. So it was enabled with the updated Stunnel version. With FIPS enabled, only TLS can be used. More interesting: FIPS is disabled by default with beginning of version 5.0. But I’m running version 4.29. So I had two options to get rid of this error:
- Disable FIPS
- Enable TLS
To disable FIPS, you have to add the following line to the stunnel.conf on the server-side:
fips = off
You can have FIPS enabled when you enforce the use of TLS. In my case, I added the following line on the server- and client-side:
sslVersion = TLSv1
After a restart of Stunnel on the server-side, the connection began to work again.