[stunnel-users] Potentially dangerous change of behavior in handling "global option" in stunnel after version 5.45

Fri Jun 29 12:15:43 CEST 2018

Hello everyone,

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
client certificate.

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,
obviously!).

Regards,

    Tony Cheneau