[undertow-dev] Undertow configuration issue - enabled-cipher-suites

[Stuart Douglas]

This looks like a bug. Can you file a JIRA in the Wildfly JIRA?

Thanks,

Stuart

----- Original Message -----
> From: "Andrew Scully" <andrewscully at gmail.com>
> To: undertow-dev at lists.jboss.org
> Sent: Thursday, 16 January, 2014 5:47:19 PM
> Subject: [undertow-dev] Undertow configuration issue - enabled-cipher-suites
> 
> Hello,
> 
> I'm having an issue when configuring a HTTPS listener for Undertow via the
> JBOSS standalone.xml method.
> 
> (Wildfly 8.0.0.CR1).
> 
> I get the following ecception on startup:
> 2014-01-16 16:00:34,521 ERROR [org.jboss.msc.service.fail](MSC service thread
> 1-9) 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:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> Caused by: java.lang.ClassCastException: Not a sequence
> at org.xnio.SequenceOption.cast(SequenceOption.java:57)
> at org.xnio.SequenceOption.cast(SequenceOption.java:31)
> at org.xnio.OptionMap.get(OptionMap.java:64)
> at org.xnio.OptionMap$Builder.copy(OptionMap.java:510)
> at org.xnio.OptionMap$Builder.addAll(OptionMap.java:522)
> at
> org.wildfly.extension.undertow.HttpListenerService.createOpenListener(HttpListenerService.java:91)
> at
> org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:122)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> 
> My JBOSS Undertow configuration looks like this:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <!-- SAA: for reference, there is not currently a default web xml in which we
> can globally disable unwanted HTTP methods.
> We have to expect the reverse proxy web server to restrict them.
> Nevertheless, Any Web Application can specifically disable them until JBoss
> start to provide a mechanism in here
> -->
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024"
> max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <!-- SAA: for reference, in ajp the Servlet/JSP Request URL is formed from
> the host and port of the client; browser or proxy.
> Web applications trying to use these values expecting them to be the local
> server and port would then be mistaken.
> As a workaround, we expect the reverse proxy web server to modify the Host
> Request Header to be equal to ths server's fully qualified host name and
> respective port, this will then mimmick the
> incoming requests to the http and https connectors.
> One example where this is crucial is REIMS Central Authentication Server as
> these details must match up against the domain advertised cas server url
> with highest priority
> -->
> <ajp-listener name="ajp" socket-binding="ajp"/>
> <http-listener name="http" socket-binding="http"/>
> <https-listener name="https" socket-binding="https"
> security-realm="ApplicationRealm"
> enabled-cipher-suites="TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_RC4_128_SHA,TLS_ECDH_ECDSA_WITH_RC4_128_SHA,TLS_ECDH_RSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
> />
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> <access-log directory="${jboss.server.base.dir}/log"
> prefix="localhost_access_log."/>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default"
> stack-trace-on-error="local-only">
> <jsp-config x-powered-by="false"/>
> <persistent-sessions/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content"
> directory-listing="true"/>
> </handlers>
> </subsystem>
> 
> By process of elimination, I've found that removing the
> "enabled-cipher-suites" attribute makes the problem go away, so obviously
> this is the culprit.
> 
> The value I'm using for this attribute has simply been copied from our
> jboss-web configuration, previously "cipher-suite".
> 
> Am I using the attribute wrong, or is this a bug?
> 
> Any help greatly appreciated.
> 
> Cheers, Andy.
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev