[mod_cluster-issues] [JBoss JIRA] (MODCLUSTER-400) Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
Michal Babacek (JIRA)
issues at jboss.org
Fri May 2 12:47:56 EDT 2014
Michal Babacek created MODCLUSTER-400:
-----------------------------------------
Summary: Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
Key: MODCLUSTER-400
URL: https://issues.jboss.org/browse/MODCLUSTER-400
Project: mod_cluster
Issue Type: Bug
Affects Versions: 1.2.8.Final
Environment: HP-UX v11.3, hpuxws22Apache B.2.2.15.15 HP-UX Apache-based Web Server, libaprutil-1.sl.3.9, libapr-1.sl.4.2
Reporter: Michal Babacek
Assignee: Jean-Frederic Clere
Priority: Critical
Fix For: 1.2.9.Final
Attachments: hp-ux_error_log-ajp-failover.zip, hp-ux_error_log-ssl-failover.zip, rhel_error_log-ssl-failover.zip
Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22
With the following configuration on a single box:
{panel:title=mod_cluster.conf| borderStyle=dashed}
{code}
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>
{code}
{panel}
{panel:title=standalone-ha.xml| borderStyle=dashed}
{code}
+++
<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>
+++
{code}
{panel}
One gets the following weird session loss. This log [^hp-ux_error_log-ssl-failover.zip] covers the undermentioned test servlet output:
{code}
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`";
{code}
{code}
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
{code}
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]):
{code}
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
{code}
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]).
{code}
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
{code}
To date, I don't have any more info to share.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
More information about the mod_cluster-issues
mailing list