-
Bug
-
Resolution: Cannot Reproduce
-
Critical
-
1.2.8.Final
-
None
-
None
Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
With the following configuration on a single box:
mod_cluster.conf
MemManagerFile "/hell/workspace/hpws22/apache/cache/mod_cluster" ServerName 10.16.92.191:2081 <IfModule manager_module> Listen 10.16.92.191:8745 LogLevel debug <VirtualHost 10.16.92.191:8745> ServerName 10.16.92.191:8745 <Directory /> Order deny,allow Deny from all Allow from all </Directory> KeepAliveTimeout 60 MaxKeepAliveRequests 0 ServerAdvertise on AdvertiseFrequency 5 ManagerBalancerName qacluster AdvertiseGroup 224.0.3.47:23364 EnableMCPMReceive SSLEngine on SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS" SSLHonorCipherOrder on SSLCertificateFile /vault/certs/server.crt SSLCertificateKeyFile /vault/certs/server.key SSLCACertificateFile /vault/certs/myca.crt SSLProxyEngine On SSLVerifyDepth 10 <Location /mcm> SetHandler mod_cluster-manager Order deny,allow Deny from all Allow from all </Location> </VirtualHost> </IfModule>
standalone-ha.xml
+++ <subsystem xmlns="urn:jboss:domain:web:2.1" native="false"> <connector name="https" protocol="HTTP/1.1" socket-binding="https" scheme="https" enabled="true" secure="true"> <ssl name="https" ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" certificate-file="/vault/certs/client-cert-key.jks" password="tomcat" verify-client="false" key-alias="javaclient" cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/> </connector> <connector name="ajp" protocol="AJP/1.3" scheme="http" socket-binding="ajp"/> <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http"/> <virtual-server name="default-host" enable-welcome-root="true"> <alias name="localhost"/> <alias name="example.com"/> </virtual-server> </subsystem> +++ <subsystem xmlns="urn:jboss:domain:modcluster:1.2"> <mod-cluster-config connector="https" advertise-socket="modcluster"> <dynamic-load-provider> <load-metric type="busyness"/> </dynamic-load-provider> <ssl ca-certificate-file="/vault/certs/ca-cert.jks" certificate-key-file="/vault/certs/client-cert-key.jks" password="tomcat" key-alias="javaclient" cipher-suite="SSL_RSA_WITH_DES_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_RSA_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_NULL_MD5,SSL_DHE_RSA_WITH_DES_CBC_SHA,SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,SSL_DH_anon_WITH_3DES_EDE_CBC_SHA,SSL_DH_anon_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_MD5,SSL_DHE_DSS_WITH_DES_CBC_SHA,SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA,SSL_DH_anon_WITH_DES_CBC_SHA,SSL_RSA_WITH_NULL_SHA,SSL_RSA_EXPORT_WITH_DES40_CBC_SHA" protocol="TLS"/> </mod-cluster-config> </subsystem> +++
One gets the following weird session loss. This log hp-ux_error_log-ssl-failover.zip
covers the undermentioned test servlet output:
echo -e "`date` `curl https://10.16.92.191:8745/clusterbench/requestinfo --cert /vault/certs/client.crt --key /vault/certs/client.key --cacert /vault/certs/myca.crt --insecure -c cookiefile.txt -b cookiefile.txt 2> /dev/null`";
Wed, Apr 30, 2014 11:50:11 AM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8544
JVM route: jboss-eap-6.3
Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
Session isNew: false
Wed, Apr 30, 2014 11:50:13 AM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8544, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8544
JVM route: jboss-eap-6.3
Session ID: vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3
Session isNew: false
-- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
Wed, Apr 30, 2014 11:50:18 AM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=vjZSMs4fZ8j0h+VIQ-GLAz+F.jboss-eap-6.3, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8645
JVM route: jboss-eap-6.3-2
Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
Session isNew: true
Wed, Apr 30, 2014 11:50:20 AM Request URI: /clusterbench/requestinfo
Headers: {host=10.16.92.191:8645, user-agent=curl/7.30.0, accept=*/*, cookie=JSESSIONID=tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2, x-forwarded-for=10.16.92.191, x-forwarded-host=10.16.92.191:8745, x-forwarded-server=10.16.92.191, connection=Keep-Alive}
Host header: 10.16.92.191:8645
JVM route: jboss-eap-6.3-2
Session ID: tYnoHJhX73UYrr3QCaUikR9h.jboss-eap-6.3-2
Session isNew: false
One could note that in the moment of fail-over from worker jboss-eap-6.3 to worker jboss-eap-6.3-2, the original session vjZSMs4fZ8j0h+VIQ-GLAz+F had been lost and a new one, tYnoHJhX73UYrr3QCaUikR9h was created.
If we comment out all the SSL settings and switch to the AJP connector, the failover seems all right though (see the hp-ux_error_log-ajp-failover.zip):
Wed, Apr 30, 2014 12:04:11 PM Request URI: /clusterbench/requestinfo
Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
Host header: 10.16.92.191:8745
JVM route: jboss-eap-6.3
Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3
Session isNew: false
-- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
Wed, Apr 30, 2014 12:04:14 PM Request URI: /clusterbench/requestinfo
Headers: {user-agent=curl/7.30.0, host=10.16.92.191:8745, accept=*/*, cookie=JSESSIONID=v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3}
Host header: 10.16.92.191:8745
JVM route: jboss-eap-6.3-2
Session ID: v-hPRQD5FsZUAqZa3ZxRBXIF.jboss-eap-6.3-2
Session isNew: false
Note that the session hPRQD5FsZUAqZa3ZxRBXIF remained the same during the failover, only a new jvmRoute were appended.
The most bewildering thing is that this behavior is specific to hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server,
i.e., I've carefully followed the same scenario with the same config on RHEL 6 x86_64, Apache/2.2.22 and the session is kept both with AJP and HTTPS connectors (see rhel_error_log-ssl-failover.zip).
Fri May 2 09:47:13 EDT 2014 Request URI: /clusterbench/requestinfo
Headers: {host=192.168.122.204:8443, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
Host header: 192.168.122.204:8443
JVM route: jboss-eap-6.3
Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3
Session isNew: false
-- stop jboss-eap-6.3 -- (the same behavior with jvm kill) --
Fri May 2 09:47:16 EDT 2014 Request URI: /clusterbench/requestinfo
Headers: {host=192.168.122.204:8544, user-agent=curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.3.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2, accept=*/*, cookie=JSESSIONID=wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3, x-forwarded-for=192.168.122.204, x-forwarded-host=192.168.122.204:8847, x-forwarded-server=192.168.122.204, connection=Keep-Alive}
Host header: 192.168.122.204:8544
JVM route: jboss-eap-6.3-2
Session ID: wdeSdhbahzVweKc5F9mUprJr.jboss-eap-6.3-2
Session isNew: false
To date, I don't have any more info to share.
