From jtrotter at onetest.com.au  Wed Jan 15 21:25:22 2014
From: jtrotter at onetest.com.au (Joshua Trotter - Onetest)
Date: Thu, 16 Jan 2014 02:25:22 +0000
Subject: [undertow-dev] SSLContext with Undertow
Message-ID: <CEFD8032.65E%jtrotter@onetest.com.au>

Hi,

We are looking at options to customise the SSLContext (to set the Keystore) whilst still making use of the convenience io.undertow.Undertow class to build the server.

It seems that the following line in the Undertow start method will ultimately result in JsseSslUtils producing a non-configurable default SSLContext every time.

XnioSsl xnioSsl = xnio.getSslProvider(OptionMap.create(Options.USE_DIRECT_BUFFERS, true));

Is creating a configurable SSL channel via the Undertow class supported?

Thanks,
Josh

________________________________

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. Onetest does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. Onetest is not responsible for any changes made to a document other than those made by Onetest, or for the effect of any changes not made by Onetest on a document's meaning. The content and opinions in non-business e-mail are not necessarily those of Onetest. If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from Onetest by sending an e-mail to antispam at onetest.com.au.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140116/7a97568a/attachment.html 

From andrewscully at gmail.com  Thu Jan 16 11:47:19 2014
From: andrewscully at gmail.com (Andrew Scully)
Date: Thu, 16 Jan 2014 16:47:19 +0000
Subject: [undertow-dev] Undertow configuration issue - enabled-cipher-suites
Message-ID: <CAOpEOPrZ_bki5u0kvcVoVTpifzjJa2Q2=f1Qijn8F4nUqedkWg@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140116/e9513c5c/attachment.html 

From sdouglas at redhat.com  Mon Jan 20 03:43:20 2014
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 20 Jan 2014 03:43:20 -0500 (EST)
Subject: [undertow-dev] Undertow configuration issue -
 enabled-cipher-suites
In-Reply-To: <CAOpEOPrZ_bki5u0kvcVoVTpifzjJa2Q2=f1Qijn8F4nUqedkWg@mail.gmail.com>
References: <CAOpEOPrZ_bki5u0kvcVoVTpifzjJa2Q2=f1Qijn8F4nUqedkWg@mail.gmail.com>
Message-ID: <1434114472.2742318.1390207400671.JavaMail.root@redhat.com>

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

From tomaz.cerar at gmail.com  Tue Jan 21 05:38:30 2014
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 21 Jan 2014 11:38:30 +0100
Subject: [undertow-dev] SSLContext with Undertow
In-Reply-To: <CEFD8032.65E%jtrotter@onetest.com.au>
References: <CEFD8032.65E%jtrotter@onetest.com.au>
Message-ID: <CAMquZP6pbPiz-QmG2eV5bjiQf1m=Hic27Diit4cfM_V+UMt7xA@mail.gmail.com>

Hey,

This was fixed in beta32 which was released yesterday, can you try new API
and confirm that it works for you.

--
tomaz


On Thu, Jan 16, 2014 at 3:25 AM, Joshua Trotter - Onetest <
jtrotter at onetest.com.au> wrote:

>  Hi,
>
>  We are looking at options to customise the SSLContext (to set the
> Keystore) whilst still making use of the convenience io.undertow.Undertow
> class to build the server.
>
>  It seems that the following line in the Undertow start method will
> ultimately result in JsseSslUtils producing a non-configurable default
> SSLContext every time.
>
>  XnioSsl xnioSsl =
> xnio.getSslProvider(OptionMap.create(Options.USE_DIRECT_BUFFERS, true));
>
>  Is creating a configurable SSL channel via the Undertow class supported?
>
>  Thanks,
> Josh
>
> ------------------------------
>
> This e-mail and any attachments may be confidential. You must not disclose
> or use the information contained in this e-mail if you are not the intended
> recipient. If you have received this e-mail in error, please notify us
> immediately and delete the e-mail and all copies. Onetest does not
> guarantee that this e-mail is virus or error free. The attached files are
> provided and may only be used on the basis that the user assumes all
> responsibility for any loss, damage or consequence resulting directly or
> indirectly from the use of the attached files, whether caused by the
> negligence of the sender or not. Onetest is not responsible for any changes
> made to a document other than those made by Onetest, or for the effect of
> any changes not made by Onetest on a document's meaning. The content and
> opinions in non-business e-mail are not necessarily those of Onetest. If
> this is a commercial electronic message within the meaning of the Spam Act,
> you may indicate that you do not wish to receive any further commercial
> electronic messages from Onetest by sending an e-mail to
> antispam at onetest.com.au.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140121/2f5e21a6/attachment.html 

From jtrotter at onetest.com.au  Tue Jan 21 21:58:13 2014
From: jtrotter at onetest.com.au (Joshua Trotter - Onetest)
Date: Wed, 22 Jan 2014 02:58:13 +0000
Subject: [undertow-dev] SSLContext with Undertow
In-Reply-To: <CAMquZP6pbPiz-QmG2eV5bjiQf1m=Hic27Diit4cfM_V+UMt7xA@mail.gmail.com>
Message-ID: <CF0570B8.70A%jtrotter@onetest.com.au>

Hey Tomaz,

Thanks for the reply, can confirm that this worked for me.

Cheers,
Josh

From: Toma? Cerar <tomaz.cerar at gmail.com<mailto:tomaz.cerar at gmail.com>>
Date: Tuesday, 21 January 2014 8:38 PM
To: Josh Trotter <jtrotter at onetest.com.au<mailto:jtrotter at onetest.com.au>>
Cc: "undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>" <undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>>
Subject: Re: [undertow-dev] SSLContext with Undertow

Hey,

This was fixed in beta32 which was released yesterday, can you try new API and confirm that it works for you.

--
tomaz


On Thu, Jan 16, 2014 at 3:25 AM, Joshua Trotter - Onetest <jtrotter at onetest.com.au<mailto:jtrotter at onetest.com.au>> wrote:
Hi,

We are looking at options to customise the SSLContext (to set the Keystore) whilst still making use of the convenience io.undertow.Undertow class to build the server.

It seems that the following line in the Undertow start method will ultimately result in JsseSslUtils producing a non-configurable default SSLContext every time.

XnioSsl xnioSsl = xnio.getSslProvider(OptionMap.create(Options.USE_DIRECT_BUFFERS, true));

Is creating a configurable SSL channel via the Undertow class supported?

Thanks,
Josh

________________________________

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. Onetest does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. Onetest is not responsible for any changes made to a document other than those made by Onetest, or for the effect of any changes not made by Onetest on a document's meaning. The content and opinions in non-business e-mail are not necessarily those of Onetest. If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from Onetest by sending an e-mail to antispam at onetest.com.au<mailto:antispam at onetest.com.au>.

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev


________________________________

This e-mail and any attachments may be confidential. You must not disclose or use the information contained in this e-mail if you are not the intended recipient. If you have received this e-mail in error, please notify us immediately and delete the e-mail and all copies. Onetest does not guarantee that this e-mail is virus or error free. The attached files are provided and may only be used on the basis that the user assumes all responsibility for any loss, damage or consequence resulting directly or indirectly from the use of the attached files, whether caused by the negligence of the sender or not. Onetest is not responsible for any changes made to a document other than those made by Onetest, or for the effect of any changes not made by Onetest on a document's meaning. The content and opinions in non-business e-mail are not necessarily those of Onetest. If this is a commercial electronic message within the meaning of the Spam Act, you may indicate that you do not wish to receive any further commercial electronic messages from Onetest by sending an e-mail to antispam at onetest.com.au.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140122/edca1e58/attachment.html