[JBoss JIRA] (JBWEB-294) The same JSSE cipher-suite behaves differently with various JDKs
by Michal Babacek (JIRA)
Michal Babacek created JBWEB-294:
------------------------------------
Summary: 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
10 years, 10 months
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-450:
---------------------------------------
Hello,
Perhaps you can guide me here.
If your JRE locale is FRENCH then would parsing of numeric values expect them to be formatted "1,000" (instead of "1.000" that the PNG seems to show)? AFAIK using a period as a decimal separator is reserved for other Locales (Spain, Norway and othersd). Are the values in the XLS in fact numeric or Strings? Can you can include a couple of Unit Tests in your PR with both FR and EN locales - and suitable XLS files?
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
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
10 years, 10 months
[JBoss JIRA] (DROOLS-454) Support pluggable resource types in the KieBuilder
by Davide Sottara (JIRA)
Davide Sottara created DROOLS-454:
-------------------------------------
Summary: Support pluggable resource types in the KieBuilder
Key: DROOLS-454
URL: https://issues.jboss.org/browse/DROOLS-454
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Davide Sottara
Assignee: Mark Proctor
A user should be able to register custom resource types and the associated processor.
Custom resources would be recognized by file extension and processed by the registered processor.
The processor will generate one or more "native" resources (e.g. DRL, BPMN) from each custom resource found in the KieFileSystem: the generated resources will eventually be added to the KieBase.
--
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
10 years, 10 months
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Maxime Falaize (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Maxime Falaize commented on DROOLS-450:
---------------------------------------
Hi Michael,
I think the problem is not the locale of the XLS file but the locale of the JRE. The DataFormatter is created with no relation to the xls workbook. I tested to reproduce the error with a different configuration in excel (settings to english locale) and the problem is still here. However, when I set the JRE default locale to English when I start my app (with Locale.setDefault(Locale.ENGLISH)), it works.
I am on a French Windows 7 (so french JRE). If you set your JRE Locale to FRENCH I think you could reproduce the error.
Maybe we can force the locale of the DateFormatter to English only for the numbers ? It would reduce the possibility of regressions.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
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
10 years, 10 months
[JBoss JIRA] (DROOLS-450) Cannot use decimal formatters for integers in an excel decision table
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-450?page=com.atlassian.jira.plugin... ]
Michael Anstis commented on DROOLS-450:
---------------------------------------
What is the locale settings of the computer on which you produced the error? What is the locale of he XLS workbook you produced the error with?
I'm reluctant to merge your pull request until we better understand your scenario: forcing the DataFormatter(Locale.ENGLISH) might work in your scenario but IDK ATM whether it's sufficiently generic and will not cause other users with different locale settings more problems without understanding a few more things first.
> Cannot use decimal formatters for integers in an excel decision table
> ---------------------------------------------------------------------
>
> Key: DROOLS-450
> URL: https://issues.jboss.org/browse/DROOLS-450
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.1.Final
> Reporter: Maxime Falaize
> Assignee: Mark Proctor
> Priority: Minor
> Attachments: issue_example.png
>
>
> When I use decimal formatter in an excel action column for numbers that are in fact integers, I am getting this exception :
> {noformat}
> Exception in thread "main" java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=com/sample/my_decision_table.xls, line=5, column=0
> text=Rule Compilation error The method setParameter(double) in the type MyObject is not applicable for the arguments (int, int)]]
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:260)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:400)
> at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:375)
> {noformat}
> Actually, the system uses the format number "1,00000" (with comma in french) instead of "1.00000" like it should use.
> This is causing by the line 174 in org.drools.decisiontable.parser.xls.ExcelParser :
> {code:java}
> if ( num - Math.round( num ) != 0 )
> {code}
> I don't understand why we use the formatted value when this test is not passed.
> I think the end users should have the possibility to keep the same formatter for the same column, with integers or not.
--
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
10 years, 10 months