Uploaded image for project: 'mod_cluster'
  1. mod_cluster
  2. MODCLUSTER-400

Failover with SSL breaks sticky sessions on HP-UX v11.3, hpws22

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Critical
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.2.8.Final
    • Fix Version/s: 1.2.11.Final
    • Component/s: None
    • Labels:
      None

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            jfclere Jean-Frederic Clere
            Reporter:
            mbabacek Michal Karm
            Tester:
            Michal Karm Michal Karm
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: