[stunnel-users] Potentially dangerous change of behavior in handling "global option" in stunnel after version 5.45
tony.cheneau at ssi.gouv.fr
Fri Jun 29 12:15:43 CEST 2018
I was updating my version of stunnel and playing my regression suite and
I was surprised to see some tests fail.
We usually apply "verify = 2" as global option at the beginning of the
configuration file on our stunnel "server" so as to enforce the client
certificate verification. So I was a little bit surprise to see I could
establish a TLS connection with my test server without providing a
The "verify = 2" as a "global option" is parsed at some point, because I
can trigger an error message if I place a bogus value ("verify = 8").
Yet, it seems to be ignored when accepting connections.
If I move the "verify = 2" from the "global option" to a service-level
option for a specific service/tunnel, it works as expected (and
documented): it rejects my certificate-less client.
After a little bit of investigation, I was able to narrow down the
change of behavior in version 5.45 (meaning that 5.44 still follow the
old behavior). All the newer version follow this new behavior. I haven't
seen any public CVS/SVN/git for stunnel, so I was not able to narrow it
down further and I could not identify the exact change in the code that
modified the behavior.
While I understand that this option is documented in the manpage as a
service-level option, in practice, "verify" could be used as a global
option for years (my oldest documented usage at my company dates back
from stunnel 4.54).
(I know this option is going to be replaced by verifyChain/requireCert,
the observed behavior reported in this email also applies on these
options: they can't be applied program wide as a "global option")
Am I missing something obvious here ? I haven't seen the change
documented in the changelog, so it looks like a regression to me.
Thank you in advance (and thank you for the great piece of software,
More information about the stunnel-users