Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
Thank you for the feedbak Sergio. You are right, disabling the SSLv23_* calls was a mistake, I'll fix that. Since this is a different issue I'll clone this report though. I also agree that the whole patch is no longer necessary. It was initially required to avoid a warning caused by the removal of the SSLv2 functions in OpenSSL (#622141). But upstream has now caught up and guarded the SSLv2 calls with a #ifndef OPENSSL_NO_SSL2 directive, so the warnings no longer occur. The hunks related to the examples are not critical, and the hunks related to SSL_CTX_set_options are useless. I'll try to get the SSLv23 issue fixed in Jessie, and I'll then remove the patch in Jessie+1. Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
I think the issue originally reported by Peter has been fixed in tomcat-native/1.1.32~repack-1 currently in testing and unstable. In this version the SSL_PROTOCOL_SSLV2 constant has been restored in ssl_private.h, and the SSL_PROTOCOL_ALL constant is aligned with the org.apache.tomcat.jni.SSL.SSL_PROTOCOL_ALL constant in tomcat7 and tomcat8. https://sources.debian.net/src/tomcat-native/1.1.32~repack-1/debian/patches/drop_sslv2_support.diff Emmanuel Bourg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
The SSLv23 issue has been cloned as #780447. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
found 737969 1.1.32~repack-1
thanks
I'd bump up the severity to serious if this weren't a maintainer's /
release manager's prerogative. This bug does force me to maintain my
own fork of the package.
The main problem, I think, is the following hunk:
@@ -121,12 +123,14 @@
/* requested but not supported */
#endif
} else {
+#ifndef OPENSSL_NO_SSL2
if (mode == SSL_MODE_CLIENT)
ctx = SSL_CTX_new(SSLv23_client_method());
else if (mode == SSL_MODE_SERVER)
ctx = SSL_CTX_new(SSLv23_server_method());
else
ctx = SSL_CTX_new(SSLv23_method());
+#endif
}
if (!ctx) {
The SSLv23_* methods in OpenSSL have misleading names. They are the only
ones that support more than one protocol version at the time, and must be
used in order to support any two or more of SSLv2, SSLv3, TLSv1, TLSv1.1,
TLSv1.2. So it's wrong to comment them out if OPENSSL_NO_SSL2 is defined.
I'd also encourage the Debian maintainers to ponder whether the rest of
the drop_sslv2_support.diff patch is still needed in light of upstream
changes to the package. In my own builds I just disable it.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737969: libtcnative-1 breaks Tomcat's 'SSLProtocols'
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 signature.asc Description: OpenPGP digital signature
