Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'

[tony mancill]

On 02/07/2014 02:53 AM, Peter Grandi wrote:
> 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.

Hi Peter,

Thank you for the analysis.  I'm simply updating the bug with some
background information.  Please refer to  Debian #622141 [0] for
background on why/how the "drop SSLv2" patch was introduced, and to
discussion upstream [1].

tony

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622141
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51056


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140207/8ddf0003/attachment.sig>