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)