[Nagiosplug-devel] New release planned next week

[Holger Weiß]

* Jochen Bern <Jochen.Bern at LINworks.de> [2013-09-17 14:30]:
> On 16.09.2013 14:54, Holger Weiß wrote:
> > With newer OpenSSL releases, the semantics are a bit weirdo:
> > | In order to ensure interoperability SSL_OP_NO_protocolX does not disable
> > | just protocol X, but all protocols above X *if* there are protocols
> > | *below* X still enabled.
> > [ http://www.openssl.org/news/changelog.html ]
> 
> It also means that my quick patch is broken *already*, given a
> sufficiently recent OpenSSL, as is the basic approach (which is assuming
> that there are N=3 protocols so that there's no uncharted territory
> between "1 allowed" and "N-1 allowed"). :-/
> 
> > More importantly, I guess other users might want to combine e.g.
> > SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3, so maybe we should support this?
> 
> OR'ing constant values together and passing the result to the OpenSSL
> calls should be easy enough, it might be more of a challenge to come up
> with a plugin options syntax that can keep up with future protocol
> designations. Yesterday, we had SSLv2/SSLv3/TLSv1(.0), today, versions
> 1.1 and 1.2 of TLS have appeared, and there's nothing to keep tomorrow's
> contender from going by the name of FOOBARBAZ 0.0.7 or requiring an
> explicit *en*able instead of a *dis*able, I'm afraid ...

I'd suggest exposing the options provided by the current OpenSSL API to
check_http users without worrying too much about support for future
protocols.  I think it's acceptable to have check_http users wait for us
adding an SSL_OP_NO_TLSvX knob when version X shows up.  If their API
changes in weird ways, we'll see whether and how we can support the new
options.

> (If you meant to have the CLI options say "SSL_OP_NO_SSLv2" etc., just
> as they're called by OpenSSL itself: That solves the naming problem, of
> course, but it also maximizes the dependency of the parameters I need to
> put into the Nagios config from the exact version of the underlying
> OpenSSL library - which yum etc. can happily change with every update
> window ...)

OpenSSL tends to be careful about backwards compatibility, so I think
it's highly unlikely that any currently supported SSL_OP_NO_* option
will be removed by a Yum update.

However, I have no strong preference regarding the command line syntax.
Maybe I'd go for a comma-separated list of versions to exclude (e.g.,
--ssl=-2,-3) to keep this somewhat consistent with the current --ssl
syntax.  Feel free to post the best solution as a pull request on GitHub
(preferably with a NEWS file entry describing the change) :-)

Cheers, Holger