[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Steps to Reproduce: {code:java}CipherSuiteSelector.fromString("SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA");{code} (was: # Use standalone.xml from attachment
# update path to keystore (server-cert-key-rsa.jks)
# update path to trust store (ca-cert.jks)
)
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
was:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
was:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The *TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* works ok, but *SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA* doesnt.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina updated ELY-647:
---------------------------
Description:
SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
MechanismDatabase.properties contains for example:
{code:java}
TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
{code}
The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
was:
There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
Interchange TLS prefix to SSL and vice versa is not supported.
Here is list of standard JSSE Cipher Suite Names
http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
In my opinion this file is mapping file for our purpose. It is?
https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
For IBM JDK are different JSSE Cipher Suite Names (different prefix).
Most items from this list are missing in MechanismDatabase.properties mentioned above.
http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
For example:
JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
{code}
16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:785)
Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "undertow"),
("server" => "default-server"),
("https-listener" => "https")
]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
{code}
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> SSL MechanismDatabase should create alias for every TLS_* from SSL_*. It create them only for direct entries, not for other aliases.
> MechanismDatabase.properties contains for example:
> {code:java}
> TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA = alias:TLS_RSA_WITH_3DES_EDE_CBC_SHA
> {code}
> The TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA works ok, but SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesnt.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (ELY-647) MechanismDatabase create SSL_ aliases incompletely
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-647?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved JBEAP-6237 to ELY-647:
---------------------------------------
Project: WildFly Elytron (was: JBoss Enterprise Application Platform)
Key: ELY-647 (was: JBEAP-6237)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: SSL
(was: Security)
Affects Version/s: (was: 7.0.0.ER6)
Affects Testing: (was: Regression)
> MechanismDatabase create SSL_ aliases incompletely
> --------------------------------------------------
>
> Key: ELY-647
> URL: https://issues.jboss.org/browse/ELY-647
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
>
> There is not possibility to use alternative JSSE Cipher Suite Names for IBM JDK8
> Interchange TLS prefix to SSL and vice versa is not supported.
> Here is list of standard JSSE Cipher Suite Names
> http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNa...
> In my opinion this file is mapping file for our purpose. It is?
> https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> For IBM JDK are different JSSE Cipher Suite Names (different prefix).
> Most items from this list are missing in MechanismDatabase.properties mentioned above.
> http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
> For example:
> JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* is only defined for IBM JDK.
> It is *TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA* for Oracle JDK.
> If I try start server with JSSE Cipher Suite Name *SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA* I will get this error:
> {code}
> 16:55:25,594 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.undertow.listener.https: org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA" not allowed at offset 33 of mechanism selection string "SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:399)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:125)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:138)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 16:55:25,598 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("https-listener" => "https")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.https" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.https: Failed to start service
> Caused by: java.lang.IllegalArgumentException: ELY05017: Token \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\" not allowed at offset 33 of mechanism selection string \"SSL_ECDHE_RSA_WITH_AES_128_CBC_SHA\""}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFLY-6700) MBeanServer.isRegistered() fails when the security manager is enabled
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6700?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-6700.
------------------------------------
Resolution: Rejected
RunAsRolePermission does not use *.
If this does not work, please re-open.
{code}
<permission>
<class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name>
<name>SUPERUSER</name>
</permission>
{code}
> MBeanServer.isRegistered() fails when the security manager is enabled
> ---------------------------------------------------------------------
>
> Key: WFLY-6700
> URL: https://issues.jboss.org/browse/WFLY-6700
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.Final
> Reporter: Derek Horton
> Assignee: Brian Stansberry
>
> Calling MBeanServer.isRegistered() in a servlet fails with the following error when the security manager is enabled:
> :WFSM000001: Permission check failed (permission "("org.jboss.as.controller.access.rbac.RunAsRolePermission" "org.jboss.as.controller.access.rbac.RunAsRolePermission.SUPERUSER")" in code source "(vfs:/content/SimpleWar.war/WEB-INF/classes <no signer certificates>)" of "null")
> The code looks like the following:
> final MBeanServer server = ManagementFactory.getPlatformMBeanServer();
> final ObjectName mbeanName = new ObjectName("ima.test:type=imaTest");
> System.out.println("*** calling MBeanServer.isRegistered() - "+server.isRegistered(mbeanName));
> The META-INF/jboss-permissions.xml looks like the following:
> <?xml version="1.0" encoding="UTF-8"?>
> <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="7">
> <permission>
> <class-name>javax.management.MBeanServerPermission</class-name>
> <name>createMBeanServer</name>
> </permission>
> <permission>
> <class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name>
> <name>*</name>
> </permission>
> </permissions>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Kabir Khan commented on WFCORE-1836:
------------------------------------
[~pferraro] Does FailedOperationTransformationConfig.ChainedConfig help at all? There should be a few usages of that scattered around the subsystem tests. I'm afraid I don't remember off the top of my head if it will work for exactly this situation since it has been a while, but it was done to work around situations like this (at least vaguely similar situations!).
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on WFCORE-1836:
--------------------------------------
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressRegistryConfig.
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ]
Paul Ferraro edited comment on WFCORE-1836 at 9/28/16 12:25 PM:
----------------------------------------------------------------
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressConfigRegistry.
was (Author: pferraro):
[~kabirkhan] I'm talking about the FailedOperationTransformationConfig.PathAddressRegistryConfig.
> Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1836
> URL: https://issues.jboss.org/browse/WFCORE-1836
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Paul Ferraro
> Assignee: Brian Stansberry
>
> For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails.
> This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months