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