[JBoss JIRA] (WFCORE-583) Think about interactive slave domain controller registration.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-583?page=com.atlassian.jira.plugin... ]
Darran Lofthouse reassigned WFCORE-583:
---------------------------------------
Assignee: (was: Darran Lofthouse)
> Think about interactive slave domain controller registration.
> -------------------------------------------------------------
>
> Key: WFCORE-583
> URL: https://issues.jboss.org/browse/WFCORE-583
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Darran Lofthouse
> Labels: domain-mode
>
> We can never eliminate pre-defined installations but we could potentially offer a capability to make it easier to register a slave with it's master and enable TLS with client-cert based authentication for the slave.
> As an example if you have a master running with TLS enabled and it's own CA certificate the following flow could be possible.
> - Start slave domain controller disconnected.
> - Start CLI and connect to slave using local auth.
> - Execute join-domain(hostname, port)
> At this point a message is displayed asking if the masters cert is trusted, an opportunity to check the fingerprints - if accepted the master's cert goes into the slave's trust store.
> Next we use a proxied authentication so the administrator sitting in front of slave can enter their credentials to authenticate against master.
> The slave process generates a public and private key and with interaction with the administrator a certificate signing request.
> The certificate signing request is passed to master over the previously established TLS connection, master signs it and passes it back to the slave.
> The slave populates it's local KeyStore with the two keys and the master signed certificate. Master may store something or it may rely on the fact it signed the cert and use CRLs instead.
> Slave can now disconnect, then reconnect using the key and trust stores populated in the above flow. Master will then verify it using whatever policy it is using, this could be trust all signed certs except the ones in the CRL or it could have also stored currently trusted certs.
> This may even be possible in a provisioned environment where the base config contains enough information to establish that first connection - in that case you may want to bundle master's cert to eliminate it's validation.
> Overall not planning this as a short term implementation but tracking here as the kind of advanced capability we could add with all of the building blocks from Elytron.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-466) Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-466?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned WFLY-466:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> Detect JBossWS Configuration for @PermitAll endpoints within Undertow subsystem.
> --------------------------------------------------------------------------------
>
> Key: WFLY-466
> URL: https://issues.jboss.org/browse/WFLY-466
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Reporter: Darran Lofthouse
>
> UNDERTOW-38 has added the possibility of deploying web applications where authentication is mandated but no authorization checks are performed - this is required for integration use cases such as EJB endpoints where authorization checks are being left to the EJB container.
> This task is to update the Undertow susbsystem to detect this scenario and enable the new mode for UNDERTOW-38.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1535) CipherSuiteSelector does not know about CHACHA20_POLY1305
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1535?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1535:
----------------------------------
Component/s: SSL
> CipherSuiteSelector does not know about CHACHA20_POLY1305
> ---------------------------------------------------------
>
> Key: ELY-1535
> URL: https://issues.jboss.org/browse/ELY-1535
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Mike Yoder
> Assignee: Darran Lofthouse
>
> I was trying to be a good person and implement the Mozilla "Modern" cipher suite described here:
> https://wiki.mozilla.org/Security/Server_Side_TLS
> I'm doing this in a keycloak server. The config line there looks like
> {noformat}
> <https-listener security-realm="ApplicationRealm"
> enabled-protocols="SSLv2Hello,TLSv1.2"
> enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> name="default"
> socket-binding="httpish"
> enable-http2="true"
> proxy-address-forwarding="true"
> />
> {noformat}
> But I got this:
> {noformat}
> 13:20:46,574 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in serv
> ice org.wildfly.undertow.listener.default: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: ELY05016: Unrecognized token "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256" in mechanism selection string "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:423)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> {noformat}
> With a little digging it appears that CipherSuiteSelector doesn't know what CHACHA20 or POLY1305 are. See:
> https://github.com/wildfly-security/wildfly-elytron/blame/master/src/main...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1535) CipherSuiteSelector does not know about CHACHA20_POLY1305
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1535?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1535:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> CipherSuiteSelector does not know about CHACHA20_POLY1305
> ---------------------------------------------------------
>
> Key: ELY-1535
> URL: https://issues.jboss.org/browse/ELY-1535
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Mike Yoder
>
> I was trying to be a good person and implement the Mozilla "Modern" cipher suite described here:
> https://wiki.mozilla.org/Security/Server_Side_TLS
> I'm doing this in a keycloak server. The config line there looks like
> {noformat}
> <https-listener security-realm="ApplicationRealm"
> enabled-protocols="SSLv2Hello,TLSv1.2"
> enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> name="default"
> socket-binding="httpish"
> enable-http2="true"
> proxy-address-forwarding="true"
> />
> {noformat}
> But I got this:
> {noformat}
> 13:20:46,574 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.undertow.listener.default: org.jboss.msc.service.StartException in serv
> ice org.wildfly.undertow.listener.default: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: ELY05016: Unrecognized token "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256" in mechanism selection string "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
> at org.wildfly.security.ssl.CipherSuiteSelector.fromString(CipherSuiteSelector.java:423)
> at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:120)
> at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:169)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> {noformat}
> With a little digging it appears that CipherSuiteSelector doesn't know what CHACHA20 or POLY1305 are. See:
> https://github.com/wildfly-security/wildfly-elytron/blame/master/src/main...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10890) CLI client in jconsole doesn't work with JDK11
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFLY-10890?page=com.atlassian.jira.plugin... ]
Jean-Francois Denise reassigned WFLY-10890:
-------------------------------------------
Assignee: Jean-Francois Denise (was: Kabir Khan)
> CLI client in jconsole doesn't work with JDK11
> ----------------------------------------------
>
> Key: WFLY-10890
> URL: https://issues.jboss.org/browse/WFLY-10890
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
> Assignee: Jean-Francois Denise
> Priority: Blocker
> Labels: Java11, blocker-WF14
>
> CLI client in jconsole doesn't work with JDK11.
> JConsole uses CLI. CLI uses WildFlySecurityManager (Elytron 1.5.4.Final). WildFlySecurityManager uses sun.misc.Unsafe. Unsafe works just with adding of {{--add-modules=jdk.unsupported}} to JConsole:
> {code:diff}
> --- a/jconsole.sh
> +++ b/jconsole.sh
> @@ -79,4 +79,4 @@ CLASSPATH=$CLASSPATH:./bin/client/jboss-cli-client.jar
> echo CLASSPATH $CLASSPATH
>
> cd "$JBOSS_HOME"
> -$JAVA_HOME/bin/jconsole -J-Djava.class.path="$CLASSPATH" "$@"
> +$JAVA_HOME/bin/jconsole -J--add-modules=jdk.unsupported -J-Djava.class.path="$CLASSPATH" "$@"
> \ No newline at end of file
> {code}
> But "jdk.unsupported" module is not a correct fix.
> *Logs:*
> {noformat}
> Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: sun/misc/Unsafe
> at org.wildfly.security.manager.WildFlySecurityManager.<clinit>(WildFlySecurityManager.java:122)
> at org.jboss.as.cli.CommandContextFactory.getInstance(CommandContextFactory.java:41)
> at org.jboss.as.cli.gui.ConnectDialog$2.actionPerformed(ConnectDialog.java:182)
> at java.desktop/javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1967)
> at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2308)
> at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:405)
> at java.desktop/javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:262)
> at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:279)
> at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:297)
> at java.desktop/java.awt.Component.processMouseEvent(Component.java:6631)
> at java.desktop/javax.swing.JComponent.processMouseEvent(JComponent.java:3342)
> at java.desktop/java.awt.Component.processEvent(Component.java:6396)
> at java.desktop/java.awt.Container.processEvent(Container.java:2263)
> at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4918)
> at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Container.java:4547)
> at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Container.java:4488)
> at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2307)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2772)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
> at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)
> Caused by: java.lang.ClassNotFoundException: sun.misc.Unsafe
> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> ... 39 more
> {noformat}
> *cc:* [~kabirkhan], [~jamezp], [~darranl], [~mchoma], [~msvehla], [~okotek], [~rsvoboda]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10873) Duplicated httpcomponent jars in WF 14.0.0.Beta2
by Rostislav Svoboda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10873?page=com.atlassian.jira.plugin... ]
Rostislav Svoboda commented on WFLY-10873:
------------------------------------------
[~ehugonnet] are you working on fix for this so it makes it to WF14 ?
> Duplicated httpcomponent jars in WF 14.0.0.Beta2
> ------------------------------------------------
>
> Key: WFLY-10873
> URL: https://issues.jboss.org/browse/WFLY-10873
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 14.0.0.Beta2
> Reporter: Martin Švehla
> Assignee: ehsavoie Hugonnet
>
> In current Beta2 build, I see duplicated httpclient and httpcore jars. The new org.apache.httpcomponents.core module was added that introduced this duplication.
> in 14.0.0.Beta2:
> {code}
> $ tree modules/system/layers/base/org/apache/httpcomponents/
> modules/system/layers/base/org/apache/httpcomponents/
> ├── core
> │ └── main
> │ ├── httpclient-4.5.2.jar
> │ ├── httpcore-4.4.4.jar
> │ └── module.xml
> └── main
> ├── httpasyncclient-4.1.3.jar
> ├── httpclient-4.5.2.jar
> ├── httpcore-4.4.4.jar
> ├── httpcore-nio-4.4.4.jar
> ├── httpmime-4.5.2.jar
> └── module.xml
> {code}
> In WF 13.0.0.Final
> {code}
> $ tree modules/system/layers/base/org/apache/httpcomponents/
> modules/system/layers/base/org/apache/httpcomponents/
> └── main
> ├── httpasyncclient-4.1.3.jar
> ├── httpclient-4.5.2.jar
> ├── httpcore-4.4.4.jar
> ├── httpcore-nio-4.4.4.jar
> ├── httpmime-4.5.2.jar
> └── module.xml
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months