Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
Peter Grandi
pg at debugs.for.sabi.co.UK
Fri Feb 7 10:53:18 UTC 2014
Package: libtcnative-1
Version: 1.1.24-1
Severity: important
Symptoms:
The Tomcat 'SSLProtocol' configuration attribute is documented
as accepting several values, but on Debian 7/Wheezy (and
presumably others) only the values "SSLv3" and "TLSv1" are
accepted; notably the default value of "all" is rejected.
Cause:
The Debian packaging of 'libtcnative-1' contains a patch that
simply removes the 'SSL_PROTOCOL_SSLV2' bitmask constant and
related code, but does not remove it from the matching Tomcat
sources.
So some other bitmask constants in the Tomcat sources contain
that bitmask constant, and therefore will never match the
supposedly equivalent bitmasks in 'libtcnative-1'.
Comments:
Given that 'libtcnative-1' is essentially a Tomcat internal
plugin, a native implementation of a Tomcat Java API,
introducing an incompatibility between interface and
implementation creates a surprising, undocumented,
user-visible breakage.
Anyhow it seems to me misguided to simply disable SSLv2 in
'libtcnative-1' on other grounds:
* The other role of 'libtcnative-1' is as wrapper around
'libopenssl', and the maintainers of that, both upstream and
Debian ones, have not felt any need to disable SSLv2 entirely
within it. Just like the Tomcat ones, both upstream and
Debian, have also felt no need to entirely disable SSLv2 in
it either. It is amazing that a library that is a bit of glue
between Tomcat and OpenSSL prevents the use of a feature that
both explicitly support.
* Some aspects of the SSLv2 protocol, in particular the SSLV2
"hello", supported by the 'SSLv23*' OpenSSL functions, are
widely used by clients, even when SSLv2 itself is not used.
It also quite safe to use the 'SSLv23*' OpenSSL functions by
setting the cipher suites to "HIGH:MEDIUM" as that disables
all the SSLv2 ciphers, making SSLv2 native negotiation fail.
* Perhaps it would be sufficient to print a warning message
when SSLv2 is requested, but this should be done in Tomcat,
not in a user-invisible glue layer between Tomcat and OpenSSL.
More information about the pkg-java-maintainers
mailing list