[jboss-jira] [JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
Michal Babacek (JIRA)
issues at jboss.org
Thu Mar 13 06:44:13 EDT 2014
[ https://issues.jboss.org/browse/JBWEB-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12952599#comment-12952599 ]
Michal Babacek commented on JBWEB-294:
--------------------------------------
@[~jfclere]: I guess you might want to comment on it as well. (perhaps tear apart my configuration... :) )
> The same JSSE cipher-suite behaves differently with various JDKs
> ----------------------------------------------------------------
>
> Key: JBWEB-294
> URL: https://issues.jboss.org/browse/JBWEB-294
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.4.0.GA
> Reporter: Michal Babacek
> Assignee: Remy Maucherat
> Fix For: JBossWeb-7.4.0.GA
>
>
> Hi guys, I believe this is a bug, but correct me if it's just a feature unknown to me.
> I have the following settings:
> h3. Apache HTTP Server (mod_cluster load balancer)
> {code}
> Listen 10.16.92.111:8847
> LogLevel debug
> <VirtualHost 10.16.92.111:8847>
> ServerName 10.16.92.111:8847
> <Directory />
> Order deny,allow
> Deny from all
> Allow from all
> </Directory>
> KeepAliveTimeout 60
> MaxKeepAliveRequests 0
> ServerAdvertise on
> AdvertiseFrequency 5
> ManagerBalancerName qacluster
> AdvertiseGroup 224.0.5.98:60220
> EnableMCPMReceive
> SSLEngine on
> SSLCipherSuite AES128-SHA:ALL:!ADH:!LOW:!MD5:!SSLV2:!NULL
> SSLCertificateFile /mnt/hudson_workspace/proper/server.crt
> SSLCertificateKeyFile /mnt/hudson_workspace/proper/server.key
> SSLCACertificateFile /mnt/hudson_workspace/proper/myca.crt
> #SSLVerifyClient require
> #SSLProxyVerify require
> SSLProxyEngine On
> SSLVerifyDepth 10
> <Location /mcm>
> SetHandler mod_cluster-manager
> Order deny,allow
> Deny from all
> Allow from all
> </Location>
> </VirtualHost>
> {code}
> h3. JBossWeb subsystem
> {code}
> <subsystem xmlns="urn:jboss:domain:web:1.5" native="false">
> <connector name="https" protocol="HTTP/1.1" socket-binding="https"
> scheme="https" enabled="true" secure="true">
> <ssl name="https" ca-certificate-file="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> certificate-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" verify-client="false" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </connector>
> <virtual-server name="default-host" enable-welcome-root="true">
> <alias name="localhost"/>
> <alias name="example.com"/>
> </virtual-server>
> </subsystem>
> {code}
> h3. mod_cluster subsystem
> {code}
> <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="/mnt/hudson_workspace/proper/ca-cert.jks"
> certificate-key-file="/mnt/hudson_workspace/proper/client-cert-key.jks"
> password="tomcat" key-alias="javaclient"
> cipher-suite="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,!TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,!TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,!TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,!TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,!TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,!TLS_RSA_WITH_AES_128_GCM_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA256,!TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA"
> protocol="TLS"/>
> </mod-cluster-config>
> </subsystem>
> {code}
> h3. Some properties
> {code}
> <system-properties>
> <property name="javax.net.ssl.trustStore" value="/mnt/hudson_workspace/proper/client-cert-key.jks"/>
> <property name="javax.net.ssl.trustStorePassword" value="tomcat"/>
> <property name="jboss.mod_cluster.jvmRoute" value="jboss-eap-6.3"/>
> <property name="jboss.node.name" value="jboss-eap-6.3"/>
> </system-properties>
> {code}
> The test runs several standalone-ha instances, client accesses the AS7 instances directly, then via mod_cluster load balancer. Some of the AS7 instances are being shut down, failover takes place. Client uses client certificate for authentication.
> The result of this test is as follows:
> ||JDK||Arch||Error||Test result||
> |Oracle JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |Oracle JDK 1.7|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |Oracle JDK 1.8|RHEL6 x64|javax.net.ssl.SSLHandshakeException (i)|(x)|
> |IBM JDK 1.6|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |IBM JDK 1.7|RHEL6 x64|JBWEB002081: No cipher match|(x)|
> |OpenJDK 1.7|RHEL6 x64| |(/)|
> |OpenJDK 1.6|RHEL6 x64| |(/)|
> |HP JDK 1.7|HP-UX v11.3|JBWEB002081: No cipher match|(x)|
> h4. (i) javax.net.ssl.SSLHandshakeException
> The funny thing here is that the client can access the AS7 server directly, HTTPS connector is up and running just fine, certificates valid, no problem.
> Yet, the AS7 server fails to do handshake with the Apache HTTP Server instance.
> Please, note that in the aforementioned cipher-suite, some (those leveraging AES-128) methods are prefixed with *!*, so are some methods in the aforementioned Apache HTTP Server configuration.
> {noformat}
> [0m[31m12:58:35,574 ERROR [org.jboss.modcluster] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) MODCLUSTER000043: Failed to send INFO to 10.16.94.122/10.16.94.122:8847: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.7.0_45]
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312) [jsse.jar:1.7.0_45]
> at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702) [jsse.jar:1.7.0_45]
> at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122) [jsse.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) [rt.jar:1.7.0_45]
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) [rt.jar:1.7.0_45]
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) [rt.jar:1.7.0_45]
> at java.io.BufferedWriter.flush(BufferedWriter.java:254) [rt.jar:1.7.0_45]
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:494)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:583)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:370)
> at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:350)
> at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:458)
> at org.jboss.modcluster.container.catalina.CatalinaEventHandlerAdapter.lifecycleEvent(CatalinaEventHandlerAdapter.java:249)
> at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:115) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1323) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1588) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1574) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> h3. Question
> How come that some JDKs does not know these JSSE cipher-suite methods, some JDKs do, but fail to do handshake with Apache HTTP Server whereas OpenJDK simply passes with "all green"?
> What is actually a bug? Is it that OpenJDK should fail as well, because the configuration is wrong, or the other JDKs should pass?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list