We actually have more alternatives - e.g. we could use OpenSSL via Boring SSL library [1]. The root problem remains the same - we can use only what we obtain from the WF server. And currently we obtain only JSSE SSLContext...

[1] http://netty.io/wiki/forked-tomcat-native.html

On Mon, Jun 5, 2017 at 10:34 AM Tristan Tarrant <ttarrant@redhat.com> wrote:

We should use this:

https://github.com/wildfly/wildfly-openssl

Tristan

On 6/1/17 1:17 PM, Gustavo Fernandes wrote:
> On Thu, Jun 1, 2017 at 10:51 AM, Sebastian Laskawiec
> <slaskawi@redhat.com <mailto:slaskawi@redhat.com>> wrote:
>
> I think I've just found the reason why we can not migrate in OpenSSL
> by default :(
>
> In server scenario we obtain S*SL*Context (the one from JDK; Netty
> has similar S*sl*Context) from WildFly. It is already configured
> along with sercurity realms, domains etc. We then get into this
> branch of code [1].
>
> In order to do fancy things like SNI we need to remap JDK's
> SSLContext into Netty's SslContext and the only implementation that
> can consume SSLContext we have at hand is JdkSslContext.
>
> I honestly have no idea how we could refactor this... And that's a
> shame because OpenSSL is way faster...
>
>
>
> I tried migrating the SSL engine to Netty's in [1] and hit the same
> wall. What I was told is that the SSLContext in Wildfly is now (version
> 11?) a capability under 'org.wildfly.security.ssl-context' and
> can be replaced, but I did not try doing that.
>
>
> [1] https://issues.jboss.org/browse/ISPN-6990
> <https://issues.jboss.org/browse/ISPN-6990>
>
> Gustavo
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev