[Aaa-dev] TLS cipher suite names


Ryan Goulding <ryandgoulding@...>
 

Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev



Rashmi Pujar <rpujar@...>
 

Thanks for your reply Ryan. I did not edit the custom.properties to disable BC provider. Should this be commented to ensure Sun provider will be used?
So far I was logging the provider of the SSLContext Object in the openflowjava code to know the provider that was being used and it is "SUN version 1.8 Provider". Looks like openflowjava uses the default Sun provider. And that is how I used the cipher suite name to test.

Here is the provider ordering on my system:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


On Thu, Mar 3, 2016 at 9:36 AM, Ryan Goulding <ryandgoulding@...> wrote:
Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev





--
Rashmi Pujar
Inocybe Technologies


Rashmi Pujar <rpujar@...>
 

Hello Ryan,

I was able to test configuring cipher-suites to use with TLS connection. 

I had to update the JCE policy files to include jars that provide unlimited cryptographic strength: http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Thanks to Mohamed for pointing it out to me.

Thanks,
Rashmi

On Thu, Mar 3, 2016 at 11:28 AM, Rashmi Pujar <rpujar@...> wrote:
Thanks for your reply Ryan. I did not edit the custom.properties to disable BC provider. Should this be commented to ensure Sun provider will be used?
So far I was logging the provider of the SSLContext Object in the openflowjava code to know the provider that was being used and it is "SUN version 1.8 Provider". Looks like openflowjava uses the default Sun provider. And that is how I used the cipher suite name to test.

Here is the provider ordering on my system:
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider


On Thu, Mar 3, 2016 at 9:36 AM, Ryan Goulding <ryandgoulding@...> wrote:
Rashmi,

How did you configure your JCE?  Did you disable bouncy castle in custom.properties (comment it out) and just rely on the default JCE Provider?  If so, then the default SUN Provider doesn't actually provide that cipher;  you need to use SunJSSE (and Java 8 since it isn't a part of Java 7 SunJSSE impl, but from your stack trace it looks like you are using 1.8.0_60 so that is good).  The provider ordering is specified in "/usr/java/jdk1.8.0_65/jre/lib/security/java.security";  can you confirm you are actually using SunJSSE?

Regards,

Ryan Goulding

On Tue, Mar 1, 2016 at 10:03 AM, Rashmi Pujar <rpujar@...> wrote:

Copying AAA mailing list as well for inputs.

Hello openflowjava-devs,

I am working on OFJ to allow users to configure cipher-suites to use with SSLEngine. (https://git.opendaylight.org/gerrit/#/c/34942/).

I am trying to test it by configuring the cipher suites supported by SunProvider 1.8, for e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. (http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html).
However, I see an IllegalArgumentException exception indicating that the cipher suite is not supported.

Do you have any inputs or leads on why I could be seeing this exception (version problem?). Could you please give some advice to be able to test this with supported cipher suite names?
Here is the stacktrace -->


2016-02-23 12:16:34,802 | WARN  | entLoopGroup-9-2 | TcpChannelInitializer            | 262 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.8.0.SNAPSHOT | Failed to initialize channel
java.lang.IllegalArgumentException: Cannot support TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 with currently installed providers
at sun.security.ssl.CipherSuiteList.<init>(CipherSuiteList.java:92)[:1.8.0_60]
at sun.security.ssl.SSLEngineImpl.setEnabledCipherSuites(SSLEngineImpl.java:2038)[:1.8.0_60]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:91)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at org.opendaylight.openflowjava.protocol.impl.core.TcpChannelInitializer.initChannel(TcpChannelInitializer.java:32)[262:org.opendaylight.openflowjava.openflow-protocol-impl:0.8.0.SNAPSHOT]
at io.netty.channel.ChannelInitializer.channelRegistered(ChannelInitializer.java:68)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRegistered(AbstractChannelHandlerContext.java:143)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRegistered(AbstractChannelHandlerContext.java:129)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelRegistered(DefaultChannelPipeline.java:733)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:450)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe.access$100(AbstractChannel.java:378)[125:io.netty.transport:4.0.33.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:424)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:329)[124:io.netty.common:4.0.33.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)[125:io.netty.transport:4.0.33.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)[124:io.netty.common:4.0.33.Final]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:137)[124:io.netty.common:4.0.33.Final]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]

Thanks,
--
Rashmi Pujar
Inocybe Technologies


_______________________________________________
aaa-dev mailing list
aaa-dev@...
https://lists.opendaylight.org/mailman/listinfo/aaa-dev





--
Rashmi Pujar
Inocybe Technologies




--
Rashmi Pujar
Inocybe Technologies