[JBoss JIRA] (ELY-386) Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-386?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-386:
---------------------------------
The EDH <-> DHE mapping isn't done in the database, it's actually done in code. It might be that the mapping is failing for some reason though.
Does replacing the EDH with DHE fix the problem for you?
> Unable to create HTTPS connection when some opnessl cipher suite with DHE are used
> ----------------------------------------------------------------------------------
>
> Key: ELY-386
> URL: https://issues.jboss.org/browse/ELY-386
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.0.2.Final
> Environment: Oracle java 1.8.0_66
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Can't configure OpenSSL cipher suites EXP-DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC-SHA, DHE-RSA-DES-CBC3-SHA, EXP-DHE-DSS-DES-CBC-SHA, DHE-DSS-CBC-SHA, DHE-DSS-DES-CBC3-SHA [1] for HTTPS connection. Seems like everlasting problem DHE vs. EDH [2] - these cipher suites don't work neither in EAP6. IMHO problem is in MechanismDatabase.properties, where these DHE cipher suite are mapped to openssl EDH cipher suite what contradict openssl documentation [1]:
> {code}
> SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = alias:TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
> SSL_DHE_RSA_WITH_DES_CBC_SHA = alias:TLS_DHE_RSA_WITH_DES_CBC_SHA
> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = alias:TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,true,EXP40,false,40,56
> TLS_DHE_RSA_WITH_DES_CBC_SHA = EDH-RSA-DES-CBC-SHA,DHE,RSA,DES,SHA1,SSLv3,false,LOW,false,56,56
> TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = EDH-RSA-DES-CBC3-SHA,DHE,RSA,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = EXP-EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,true,EXP40,false,40,56
> SSL_DHE_DSS_WITH_DES_CBC_SHA = EDH-DSS-DES-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = EDH-DSS-DES-CBC3-SHA,DHE,DSS,3DES,SHA1,SSLv3,false,HIGH,true,168,168
> {code}
> Note that MechanismDatabase.properties is inconsistent in mapping DHE cipher suites to openssl cipher suites, as there also exist couple of them which map DHE to DHE, for example
> {code}
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = DHE-RSA-AES128-SHA256,DHE,RSA,AES128,SHA256,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = DHE-RSA-AES256-SHA256,DHE,RSA,AES256,SHA256,TLSv1.2,false,HIGH,true,256,256
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = DHE-RSA-AES128-GCM-SHA256,DHE,RSA,AES128GCM,AEAD,TLSv1.2,false,HIGH,true,128,128
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = DHE-RSA-AES256-GCM-SHA384,DHE,RSA,AES256GCM,AEAD,TLSv1.2,false,HIGH,true,256,256
> {code}
> In MechanismDatabase.properties is also said that
> ??Note that all EDH ciphers automatically get a DHE OpenSSL-style alias (and vice-versa)??
> I think this JIRA contradict this comment.
> Last thing, based on [1] shouldn't be SSL_DHE_DSS_WITH_DES_CBC_SHA defined as
> SSL_DHE_DSS_WITH_DES_CBC_SHA = DHE-DSS-CBC-SHA,DHE,DSS,DES,SHA1,SSLv3,false,LOW,false,56,56
> ?
> [1] https://www.openssl.org/docs/manmaster/apps/ciphers.html#CIPHER-SUITE-NAMES
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123304
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1991) TCP_NIO2: copy on demand
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1991?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1991:
---------------------------
Description:
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
Example: we want to write 3 buffers of 100, 200 and 700 bytes in a gathering write (the buffers are allocated from reusable byte[] arrays).
If the write returns 1000, we know that all 3 buffers have been written and there is no need to copy any of the buffers. However, if only 500 bytes were written, then we can trash the first 2 buffers, but need to make a copy of the 3rd buffer in range [201 .. 700].
This allows the sender to reuse previously allocated buffers, as all transports (UDP, TCP, TCP_NIO2) now guarantee that, on return of the send(), either the data was written completely, or a copy was made.
[1] https://issues.jboss.org/browse/JGRP-1961
was:
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
[1] https://issues.jboss.org/browse/JGRP-1961
> TCP_NIO2: copy on demand
> ------------------------
>
> Key: JGRP-1991
> URL: https://issues.jboss.org/browse/JGRP-1991
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
> However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
> Example: we want to write 3 buffers of 100, 200 and 700 bytes in a gathering write (the buffers are allocated from reusable byte[] arrays).
> If the write returns 1000, we know that all 3 buffers have been written and there is no need to copy any of the buffers. However, if only 500 bytes were written, then we can trash the first 2 buffers, but need to make a copy of the 3rd buffer in range [201 .. 700].
> This allows the sender to reuse previously allocated buffers, as all transports (UDP, TCP, TCP_NIO2) now guarantee that, on return of the send(), either the data was written completely, or a copy was made.
> [1] https://issues.jboss.org/browse/JGRP-1961
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5520) EAP 6 HA migrated configs fail to boot server
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-5520:
--------------------------------------
Hi [~lthon], yes we do want to fix this and that's the goal of this issue. It is not yet clear what the best fix is, ideally if we can address this in WF code; if the semantics can't match on EAP6/7 it would have to be addressed in the migration tooling.
> EAP 6 HA migrated configs fail to boot server
> ---------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5520) EAP 6 HA migrated configs fail to boot server
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5520?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5520:
---------------------------------
Summary: EAP 6 HA migrated configs fail to boot server (was: EAP 6 HA migrated configs fails to boot server)
> EAP 6 HA migrated configs fail to boot server
> ---------------------------------------------
>
> Key: WFLY-5520
> URL: https://issues.jboss.org/browse/WFLY-5520
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR2
> Reporter: Eduardo Martins
> Assignee: Radoslav Husar
> Priority: Critical
> Attachments: eap-6.1-migrated-configs.zip, eap-6.4-migrated-configs.zip
>
>
> If you try (curated) EAP 6 standalone-ha.xml configuration on WildFly the server will fail to boot due to an EJB3 subsystem attribute.
> Server boot console log:
> mbp:migration-tests emmartins$ ./default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT/bin/standalone.sh -c standalone-ha.xml
> =========================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: /Users/emmartins/wildfly/migration-tests/default-config-manual-copy/wildfly-10.0.0.CR3-SNAPSHOT
> JAVA: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java
> JAVA_OPTS: -server -Xms64m -Xmx512m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 11:37:25,583 INFO [org.jboss.modules] (main) JBoss Modules version 1.4.4.Final
> 11:37:25,896 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> 11:37:25,985 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) starting
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 7) WFLYCTL0028: Attribute 'default-stack' in the resource at address '/subsystem=jgroups' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,307 INFO [org.jboss.as.controller.management-deprecated] (ServerService Thread Pool -- 15) WFLYCTL0028: Attribute 'default-clustered-sfsb-cache' in the resource at address '/subsystem=ejb3' is deprecated, and may be removed in future version. See the attribute description in the output of the read-resource-description operation to learn more about the deprecation.
> 11:37:27,385 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "ejb3")]) - failure description: "WFLYEJB0451: Attribute 'default-clustered-sfsb-cache' is not supported on current version servers; it is only allowed if its value matches 'default-sfsb-cache'"
> 11:37:27,586 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem ejb3 boot operations"
> 11:37:27,588 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem ejb3 boot operations\""
> 11:37:27,591 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> 11:37:27,594 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested.
> 11:37:27,603 INFO [org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Full 10.0.0.CR3-SNAPSHOT (WildFly Core 2.0.0.CR6) stopped in 6ms
> Attached is the standalone-ha.xml config, with just threads subsystem removed, and web subsystem migrated to undertow, that should be able to boot the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1991) TCP_NIO2: copy on demand
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1991?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1991:
---------------------------
Description:
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
[1] https://issues.jboss.org/browse/JGRP-1961
was:
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-xxx.
However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
> TCP_NIO2: copy on demand
> ------------------------
>
> Key: JGRP-1991
> URL: https://issues.jboss.org/browse/JGRP-1991
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.6.7
>
>
> When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961 [1].
> However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
> [1] https://issues.jboss.org/browse/JGRP-1961
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (JGRP-1991) TCP_NIO2: copy on demand
by Bela Ban (JIRA)
Bela Ban created JGRP-1991:
------------------------------
Summary: TCP_NIO2: copy on demand
Key: JGRP-1991
URL: https://issues.jboss.org/browse/JGRP-1991
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.7
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-xxx.
However, if we copied the data only on a *partial write* (full writes don't need a copy), then we could always pass data from reused buffers down to the transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5758) Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
by Montpa Pasteur (JIRA)
[ https://issues.jboss.org/browse/WFLY-5758?page=com.atlassian.jira.plugin.... ]
Montpa Pasteur commented on WFLY-5758:
--------------------------------------
Doesn't fix the problem.
> Getting [Management resource '[(\"subsystem\" => \"undertow\")]' not found] when removing ressources from Undertow
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5758
> URL: https://issues.jboss.org/browse/WFLY-5758
> Project: WildFly
> Issue Type: Bug
> Components: CLI
> Affects Versions: 8.x.x TBD
> Environment: Wildfly 8.2.1 on SUSE Linux 11.1 and Solaris 11
> Reporter: Montpa Pasteur
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> When trying remove more that one resource from Undertow using the CLI, I am getting this message: *[Management resource '[(\"subsystem\" => \"undertow\")]' not found*]
> This doesn't happen all time, it looks like random. Adding a sleep between the CLI command helps some time.
> I get this problem when trying to remove http request header configuration and when trying to remove static ressource serving configuration(location, file handler, filter ..)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-994) Improve extensibility of drools extension in KIE Server
by Maciej Swiderski (JIRA)
Maciej Swiderski created DROOLS-994:
---------------------------------------
Summary: Improve extensibility of drools extension in KIE Server
Key: DROOLS-994
URL: https://issues.jboss.org/browse/DROOLS-994
Project: Drools
Issue Type: Enhancement
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: Maciej Swiderski
Assignee: Edson Tirelli
Currently Drools extension in KIE Server expects data in String format that then are transformed into object representation via marshallers. While this is completely ok for REST and JMS it might be a limitation when other type of transports are required - socket communication with binary data, Apache Mina, Netty, etc
Current solution should be improved to allow direct use of rule service that will be responsible for:
- finding ksession to use
- executing commands
- returning results
such service should be then wrapped with implementation that deal with given transport like REST and JMS based on string payload and marshaller. Custom implementation could then decide how to deal with different types of data handling and directly call the rule execution service to avoid sting based transformation
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-994) Improve extensibility of drools extension in KIE Server
by Maciej Swiderski (JIRA)
[ https://issues.jboss.org/browse/DROOLS-994?page=com.atlassian.jira.plugin... ]
Maciej Swiderski reassigned DROOLS-994:
---------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> Improve extensibility of drools extension in KIE Server
> -------------------------------------------------------
>
> Key: DROOLS-994
> URL: https://issues.jboss.org/browse/DROOLS-994
> Project: Drools
> Issue Type: Enhancement
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: Maciej Swiderski
> Assignee: Maciej Swiderski
>
> Currently Drools extension in KIE Server expects data in String format that then are transformed into object representation via marshallers. While this is completely ok for REST and JMS it might be a limitation when other type of transports are required - socket communication with binary data, Apache Mina, Netty, etc
> Current solution should be improved to allow direct use of rule service that will be responsible for:
> - finding ksession to use
> - executing commands
> - returning results
> such service should be then wrapped with implementation that deal with given transport like REST and JMS based on string payload and marshaller. Custom implementation could then decide how to deal with different types of data handling and directly call the rule execution service to avoid sting based transformation
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5765) Data source connection-properties is defined as an attribute and a sub-resource
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-5765?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen reassigned WFLY-5765:
-------------------------------------
Assignee: Stefano Maestri (was: Jesper Pedersen)
> Data source connection-properties is defined as an attribute and a sub-resource
> -------------------------------------------------------------------------------
>
> Key: WFLY-5765
> URL: https://issues.jboss.org/browse/WFLY-5765
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: James Perkins
> Assignee: Stefano Maestri
> Priority: Critical
>
> The {{subsystem=datasource/data-source=*}} resource has a {{connection-properties}} attribute and a {{connection-properties}} sub-resource. Since DMR is a tree structure each child must have a unique key. Since the parent resource has a {{connection-properties}} attribute and sub-resource with a {{read-resource}} operation you will only get one of the values.
> Also writing to the {{connection-properties}} attribute fails to marshal the XML since marshaller expects the value to look something like
> {code}
> { "key" => { "value" => "real-value" } }
> {code}
> But the resource definition expects
> {code}
> { "key" => "real-value" }
> {code}
> The attribute does not appear to be in EAP 6.4. It is however in WildFly 8.x and 9.x. Some further research should be done, but the attribute could likely be removed. Not having the attribute would also be more consistent with XA data sources.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months