wildfly-security / wildfly-openssl Goto Github PK

View Code? Open in Web Editor NEW

81.0 81.0 71.0 1002 KB

Generic OpenSSL bindings for Java

License: Apache License 2.0

Java 100.00%

hacktoberfest

wildfly-openssl's People

Contributors

Stargazers

Watchers

wildfly-openssl's Issues

How do I set GOST ciphersuites enabled via wildfly?

I need to connect a server supporting Russian GOST ciphersuites. Russian GOST cryptoalgorithms are supported via engine mechanism.

I need either call OPENSSL_config or set the OPENSSL_CONF variable pointing on the config file providing engine loading, but then I do not get the connection.

The stack trace I get is

java.lang.IllegalStateException: WFOPENSSL0012 Failed cipher suite GOST2001-GOST89-GOST89
at org.wildfly.openssl.OpenSSLEngine.lambda$setEnabledCipherSuites$0(OpenSSLEngine.java:757)
at org.wildfly.openssl.OpenSSLEngine.initSsl(OpenSSLEngine.java:171)
at org.wildfly.openssl.OpenSSLEngine.handshake(OpenSSLEngine.java:926)
at org.wildfly.openssl.OpenSSLEngine.beginHandshakeImplicitly(OpenSSLEngine.java:920)
at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:395)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:291)
at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:486)
at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:532)
at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:51)
at IdxLib.IdxLib.windlyHttpsClient.writeOutput(windlyHttpsClient.java:154)
at IdxLib.IdxLib.windlyHttpsClient.connectIDX(windlyHttpsClient.java:99)
at IdxLib.IdxLib.windlyHttpsClient.testIt(windlyHttpsClient.java:67)
at IdxLib.IdxLib.windlyHttpsClient.testIt(windlyHttpsClient.java:52)
at IdxLib.IdxLib.App.main(App.java:31)
Caused by: java.lang.IllegalStateException: error:1410F0B9:SSL routines:SSL_set_cipher_list:no cipher match
at org.wildfly.openssl.SSLImpl.setCipherSuites0(Native Method)
at org.wildfly.openssl.SSLImpl.setCipherSuites(SSLImpl.java:428)
at org.wildfly.openssl.OpenSSLEngine.lambda$setEnabledCipherSuites$0(OpenSSLEngine.java:755)
... 14 more

openssl s_client -cipher works perfectly.

memory leak: sessions in OpenSSL are not free

When using wildfly-openssl, we met a memory leak.

The reproduce method is quite simple, start a jetty demo server(make sure jetty is using wildfy-openssl), then use curl to acquire index.html again and again, for example, 10000 times, then you will find memory always increase and never decrease. If adding some prints in SSL_Session_new and SSL_Session_free, it's easy to find out that SSL_Session is malloc 10000 times, and never got free.

The memory leak only happens when SSL_CTX_set_cache_mode is server mode.

The reason why SSL_Session is malloc but not got free is: the reference of the session is not 0. when session is new(SSL_Session_new), it's reference is set to 1. when updating cache(ssl_update_cache), if new_session_cb is set, it's reference will increase by 1. so when connection is closed(SSL_Session_free), it's reference decrease by 1, and will not be processed again.

It looks like that if the return value of new_session_cb is 1, then users need to maintain the cached ssl session by themselves. Otherwise, if the return value of new_session_cb is 0, it means users won't need to maintain the ssl session, openSSL will take care of it.

And the solution might be:
1. change the return value of new_session_cb to 0 or
2. invalidate the session in remove_session_cb.

Thanks.

setSessionIdContext cause probably a memory leak

Line 270 in OpenSSLContextSPI.java cause a memory leak problem.
"serverSessionContext.setSessionIdContext("test".getBytes(StandardCharsets.US_ASCII));"
Reason:
in the jni interface, it create a pointer, "sidCtx", points to the id context of created session, which is not free in freeSSLContext.

can we just remove this line?

Add TLS 1.3 support

There are no open-source Java library that supports TLS-1.3 at the moment. It would a cool thing if you could update this wrapper to back tls-1.3 version as it is supported by openssl now.

Impact of openSSL security issues / vulnerabilites for wildfly

In the light of recent security vulnerabilities of openSSL I would like to know the impact on wildfly's openSSL usage.

Disclaimer: I apologize if there is a clear answer to the question but I'm not too deep into the subject - hence this issue. The question whether these vulnerabilities can be exploited through wildfly is a totally different question but not part of this issue.

From what I read the wildfly-openssl-java artifact does not contain any native code. Okay so far.
However the wildfly-openssl artifact contains binaries for Mac, Linux and Windows.

If you are running on x86_64 Mac, Windows or Linux then you can use the out of the box support provided by the wildfly-openssl artifact. (called libwfssl ...)

But on the other side I read that it is necessary to register the provider. (org.wildfly.openssl.path system property). However

If this property is not present the standard system library search path with be used instead

So my question is:

If wildfly is running in an environment which contains (vulnerable) openSSL libraries (e.g. CentOS7 which contains openSSL 1.0.2)

the openssl.path system property has not been set (but maybe openSSL is in the standard system search path)
there is no explicit switch of the SSLContext from JSSE to openSSL

For that case: Is there any chance that openSSL is used in wildfly (in any form)?

Unable to create unbound SSL server sockets

In the ServerSocketFactory it seems like there is a missing override for an unbound/plain #createServerSocket(). There is a matching implementation in OpenSSLServerSocket but it's not possible to reach it through the ServerSocketFactory implemented.

This caused us to get an exception for "Unbound server sockets not implemented" (JDK default impl). Since there is an implementation in OpenSSLServerSocket I guess it could be as simple as adding an override like:

@Override
public ServerSocket createServerSocket() throws IOException {
 return new OpenSSLServerSocket(OpenSSLContextSPI.this);
}

to the ServerSocketFactory. I can add that I don't have the possibility to change the code that is creating the socket as it is external software. But adding the above override made it work for me.

Wildfly OpenSSL causes a JVM crash under concurrent load

We've been experiencing periodic crashes in our software that we believe to be caused by the Wildfly OpenSSL library.

We've isolated this down to a simple test case that doesn't rely on any of our app-specific code. It starts up a separate JVM that runs the server, and then spins up N concurrent client threads that each attempt to open a connection to the server and send a couple integers back and forth.

Test app that demonstrates the problem: https://github.com/marpidone-mim/wildfly-ssl-crash

The test often causes a JVM crash in the server very quickly, and the stack always looks like this:

Current thread (0x00000170a797f800):  JavaThread "pool-1-thread-9" [_thread_in_native, id=21052, stack(0x0000001a33100000,0x0000001a33200000)]

Stack: [0x0000001a33100000,0x0000001a33200000],  sp=0x0000001a331fe5d0,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libcrypto-3-x64.dll+0x2cc85f]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.wildfly.openssl.SSLImpl.setSSLVerify0(JII)V+0
j  org.wildfly.openssl.SSLImpl.setSSLVerify(JII)V+4
j  org.wildfly.openssl.OpenSSLEngine.lambda$setSSLParameters$4(Ljavax/net/ssl/SSLParameters;)V+65
j  org.wildfly.openssl.OpenSSLEngine$$Lambda$51.run()V+8
j  org.wildfly.openssl.OpenSSLEngine.initSsl()V+118
j  org.wildfly.openssl.OpenSSLEngine.unwrap(Ljava/nio/ByteBuffer;[Ljava/nio/ByteBuffer;II)Ljavax/net/ssl/SSLEngineResult;+167
j  javax.net.ssl.SSLEngine.unwrap(Ljava/nio/ByteBuffer;Ljava/nio/ByteBuffer;)Ljavax/net/ssl/SSLEngineResult;+12 [email protected]
j  org.wildfly.openssl.OpenSSLSocket.runHandshake()V+354
j  org.wildfly.openssl.OpenSSLSocket.read([BII)I+73
j  org.wildfly.openssl.OpenSSLSocket.read([B)I+5
j  org.wildfly.openssl.OpenSSLSocket.read()I+6
j  org.wildfly.openssl.OpenSSLInputStream.read()I+4
j  ssl.test.Server.lambda$handleNextConnection$1(Ljava/net/Socket;)V+11
j  ssl.test.Server$$Lambda$52.run()V+4
j  java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/Object;+4 [email protected]
j  java.util.concurrent.FutureTask.run()V+39 [email protected]
j  java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V+92 [email protected]
j  java.util.concurrent.ThreadPoolExecutor$Worker.run()V+5 [email protected]
j  java.lang.Thread.run()V+11 [email protected]
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000008

Workaround that seems to prevent the crash
We discovered with some investigation that adding a call to SSLSocket.getHandshakeSession() in the server-side code immediately after accepting the socket connection prevents the crash from happening. Check Server.handleNextConnection for a spot where I added this line and commented it out. Uncommenting it seems to prevent the crash.

WFSSL-117 google.com certificate is incorrectly identified as RSA giving error "KeyUsage does not allow key encipherment"

The following code (get google.com) fails:

        var context = SSLContext.getInstance("TLSv1.3", OpenSSLProvider.INSTANCE);
        context.init(null, null, null);

        var httpClient = HttpClient.newBuilder()
                .sslContext(context)
                .build();

        httpClient.send(HttpRequest.newBuilder(URI.create("https://www.google.com"))
                .GET()
                .build(), BodyHandlers.ofString());

Error is thrown:

Caused by: javax.net.ssl.SSLException: error:0A000086:SSL routines::certificate verify failed
        at org.wildfly.openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:626)
        at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)

Trace log shows:

sun.security.validator.ValidatorException: KeyUsage does not allow key encipherment
        at java.base/sun.security.validator.EndEntityChecker.checkTLSServer(EndEntityChecker.java:273)
        at java.base/sun.security.validator.EndEntityChecker.check(EndEntityChecker.java:149)
        at java.base/sun.security.validator.Validator.validate(Validator.java:269)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:241)
        at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:113)
        at org.wildfly.openssl.OpenSSLContextSPI.lambda$init$0(OpenSSLContextSPI.java:241)
        at org.wildfly.openssl.SSLImpl.readFromSSL0(Native Method)
        at org.wildfly.openssl.SSLImpl.readFromSSL(SSLImpl.java:153)
        at org.wildfly.openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:613)
        at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)

Error seems to be in OpenSSLContextSPI which incorrectly determines google.com certificate to be RSA but it's in fact EC and EC certificates does not require key encipherment for TLS.

OPENSSL_config support

Does wildfly-openssl support explicit specification of the openssl configuration file?

using openssl 1.0.2o failed with wildfly-opemssl 1.0.6.Final

Hello, I'm trying use openssl 1.0.2o (minimum is 1.0.1 if i right understand), but it fails to load it. With 1.1.0h it load fine. Any clue?

Jul 27, 2018 12:14:54 PM com.stimulus.archiva.domain.Applications registerOpenSSL
INFO: failed register OpenSSL provider
java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
	at java.security.Provider$Service.newInstance(Provider.java:1617)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
	at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
	at com.stimulus.archiva.domain.Applications.registerOpenSSL(Applications.java:820)
	at com.stimulus.archiva.domain.Applications.initCrypto(Applications.java:801)
	at com.stimulus.archiva.domain.Applications.<clinit>(Applications.java:138)
	at com.stimulus.archiva.domain.ApplicationsTest.initCrypto(ApplicationsTest.java:15)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.IllegalStateException: Could not load libssl
	at org.wildfly.openssl.SSLImpl.initialize0(Native Method)
	at org.wildfly.openssl.SSLImpl.initialize(SSLImpl.java:33)
	at org.wildfly.openssl.SSL.init(SSL.java:194)
	at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
	at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.security.Provider$Service.newInstance(Provider.java:1595)
	... 29 more

Jul 27, 2018 12:14:55 PM com.stimulus.archiva.domain.Applications registerOpenSSL
INFO: failed register OpenSSL provider
java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
	at java.security.Provider$Service.newInstance(Provider.java:1617)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
	at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
	at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
	at com.stimulus.archiva.domain.Applications.registerOpenSSL(Applications.java:820)
	at com.stimulus.archiva.domain.Applications.initCrypto(Applications.java:801)
	at com.stimulus.archiva.domain.ApplicationsTest.initCrypto(ApplicationsTest.java:15)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
	at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
	at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
	at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
Caused by: java.lang.IllegalStateException: Could not load libssl
	at org.wildfly.openssl.SSLImpl.initialize0(Native Method)
	at org.wildfly.openssl.SSLImpl.initialize(SSLImpl.java:33)
	at org.wildfly.openssl.SSL.init(SSL.java:194)
	at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
	at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at java.security.Provider$Service.newInstance(Provider.java:1595)
	... 28 more

dlopen(/Users/valenpo/Developer/openssl/openssl-1.0.2o/libssl.dylib, 1): Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib
  Referenced from: /Users/valenpo/Developer/openssl/openssl-1.0.2o/libssl.dylib
  Reason: image not founddlopen(/Users/valenpo/Developer/openssl/openssl-1.0.2o/libssl.dylib, 1): Library not loaded: /usr/local/ssl/lib/libcrypto.1.0.0.dylib
  Referenced from: /Users/valenpo/Developer/openssl/openssl-1.0.2o/libssl.dylib

Process finished with exit code 0
  Reason: image not found

ByteBuffer allocation and de-allocation is expensive and becomes the performance bottleneck

During the performance benchmarking of the integration wildfly-openssl with Airlift, we found the performance bottleneck is ByteBuffer allocation and de-allocation.

Please refer to this project: https://github.com/heyuanliu-intel/AirliftPerformance

The system CPU utilization is about 20%. Most of the threads are blocked. Please refer to the thread dump file: https://raw.githubusercontent.com/heyuanliu-intel/AirliftPerformance/main/threaddump/thread1.txt

From this thread dump file, we can see that most of the threads are blocked by the ByteBuffer allocation and de-allocation.

After the investigation, we suggest to use pool based method to do ByteBuffer allocation and de-allocation.
The performance benchmarking is done.
Please refer to this project: https://github.com/heyuanliu-intel/ByteBufferPerformance

Based on the pool based allocation/de-allocation, we can get 4X performance improvement for the Airlift benchmarking.

I will submit the code and make the pull request.

wildfly-openssl not up to date; doesn’t send full chain with handshake

I got burned recently because of a bug in older implementation that didn’t sent all the certs with the handshake (since the intermediate C.A. wasn’t in the trust anchor on some systems).

Looking at the code, I couldn’t figure it out but when I stepped through I realized it wasn’t the same code as on master. Looking further on search.maven.org, I found that the wildfly-openssl was 1.0.4Final vs 1.0.6Final for everything else like wildfly-openssl-java and all the os-specific artifacts.

If the all-in-one solution has been abandoned, please remove it from the documentation; if not then please push it to maven and fix the release process to include it.

How to add the wfssl into the library?

I don't how to add the wfssl into the java library. I tried many ways but it always show me no wfssl in java.library.path. :(

OCSP Stapling Support

Hi, JSSE (since 9) has OCSP Stapling. Is it supported with wildfly-openssl? If so, how to enable it?

Thanks.

Propose to publish aarch64 supported artifacts in Maven central

Recently we are trying to build Hadoop on ARM/aarch64 server, wildfly-openssl:1.0.7.Final is a required dependency, but there isn't aarch64 support wildfly-openssl in Maven central. For the 1.0.8.Final version, there are multiple OS/platforms supported: e.g. windows x86_64, linux x86_64, linux i386. but no aarch64 artifact, even we have supported in wildfly-openssl code. I would propose to publish aarch64 supported artifacts of 1.0.8.Final or newer version to maven central.

OpenSSLEngine shuts down too early

Using wildfly-openssl 1.0.12.Final with with Netty 4.1.51.Final.

OpenSSLEngine shuts itself down in unwrap() after receiving a close_notify message from the client here:

	at org.wildfly.openssl.OpenSSLEngine.shutdown(OpenSSLEngine.java:205)
	at org.wildfly.openssl.OpenSSLEngine.closeInbound(OpenSSLEngine.java:692)
	at org.wildfly.openssl.OpenSSLEngine.unwrap(OpenSSLEngine.java:657)
	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:637)
	at io.netty.handler.ssl.JdkSslEngine.unwrap(JdkSslEngine.java:92)
	at io.netty.handler.ssl.JdkAlpnSslEngine.unwrap(JdkAlpnSslEngine.java:143)
	at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:282)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1380)
	at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1275)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1322)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:93)
	at org.infinispan.server.core.transport.StatsChannelHandler.channelRead(StatsChannelHandler.java:26)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:792)
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:475)

RFC 2246 section 7.2.1 says both sides need to send a close_notify message for the connection to be closed, so I believe the server could send more data, and OpenSSLEngine should stay available.

In our case, Netty's output buffer is empty, but it still goes through the motions of flushing the connection before closing it, and it fails because the engine is shut down:

java.lang.IllegalStateException: ssl is null
	at org.wildfly.openssl.SSLImpl.getSessionId0(Native Method)
	at org.wildfly.openssl.SSLImpl.getSessionId(SSLImpl.java:494)
	at org.wildfly.openssl.OpenSSLEngine.getSession(OpenSSLEngine.java:977)
	at io.netty.handler.ssl.JdkSslEngine.getSession(JdkSslEngine.java:48)
	at io.netty.handler.ssl.SslHandler$SslEngineType$3.allocateWrapBuffer(SslHandler.java:312)
	at io.netty.handler.ssl.SslHandler.allocateOutNetBuf(SslHandler.java:2207)
	at io.netty.handler.ssl.SslHandler.wrap(SslHandler.java:840)
	at io.netty.handler.ssl.SslHandler.wrapAndFlush(SslHandler.java:811)
	at io.netty.handler.ssl.SslHandler.flush(SslHandler.java:792)
	at io.netty.channel.AbstractChannelHandlerContext.invokeFlush0(AbstractChannelHandlerContext.java:750)
	at io.netty.channel.AbstractChannelHandlerContext.invokeFlush(AbstractChannelHandlerContext.java:742)
	at io.netty.channel.AbstractChannelHandlerContext.flush(AbstractChannelHandlerContext.java:728)
	at io.netty.handler.codec.http2.Http2ConnectionHandler.flush(Http2ConnectionHandler.java:189)
	at io.netty.handler.codec.http2.Http2MultiplexCodec.flush0(Http2MultiplexCodec.java:282)
	at io.netty.handler.codec.http2.Http2MultiplexCodec.processPendingReadCompleteQueue(Http2MultiplexCodec.java:261)
	at io.netty.handler.codec.http2.Http2MultiplexCodec.channelReadComplete(Http2MultiplexCodec.java:240)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:397)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelReadComplete(AbstractChannelHandlerContext.java:390)
	at io.netty.handler.ssl.SslHandler.channelReadComplete0(SslHandler.java:1341)
	at io.netty.handler.ssl.SslHandler.channelReadComplete(SslHandler.java:1330)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:397)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelReadComplete(AbstractChannelHandlerContext.java:390)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelReadComplete(DefaultChannelPipeline.java:1415)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelReadComplete(AbstractChannelHandlerContext.java:397)
	at io.netty.channel.DefaultChannelPipeline.fireChannelReadComplete(DefaultChannelPipeline.java:925)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:812)

The comment in Http2MultiplexCodec is not very reassuring, but from what I can tell the code is correct.

We have a Netty handler that automatically closes the connection on errors, which triggers another flush, and another IllegalStateException, and so on until the thread runs out of stack. We have added a crude workaround in our code to ignore IllegalStateExceptions with message ssl is null (ISPN-12558).

Is there any plan to support Android ?

WildFly Openssh Hang while handshake with openjdk 1.8 302 release

I am using wildfly openssh as replacement for java ssh to enhance the performance, and it looks in most of the cases it working fine. but after we upgrade to open jdk 1.8 302, it hang for no reason, and no time out.

wildfly openssh version : 2.1.4.Final

the java version is :

openjdk version "1.8.0_302"

OpenJDK Runtime Environment (build 1.8.0_302-b08)

OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mode)

OS Version:

NAME="CentOS Linux"

VERSION="7 (Core)"

ID="centos"

ID_LIKE="rhel fedora"

VERSION_ID="7"

PRETTY_NAME="CentOS Linux 7 (Core)"

ANSI_COLOR="0;31"

CPE_NAME="cpe:/o:centos:centos:7"

and openssh version

OpenSSL> version

OpenSSL 1.0.2k-fips 26 Jan 2017

stack trace for program :

java.lang.Thread.State: RUNNABLE

at org.wildfly.openssl.SSLImpl.pendingWrittenBytesInBIO0(Native Method)

at org.wildfly.openssl.SSLImpl.pendingWrittenBytesInBIO(SSLImpl.java:90)

at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:452)

locked <0x00000000d3cc12f8> (a org.wildfly.openssl.OpenSSLEngine)

at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)

at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:305)

at org.wildfly.openssl.OpenSSLSocket.startHandshake(OpenSSLSocket.java:224)

JVM Crash with wildfly-openssl-1.0.4.Final

java_error.log

Stack: [0x00007f1df0721000,0x00007f1df0822000],  sp=0x00007f1df081fb58,  free space=1018k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x85ecc]  cfree+0x1c
J 30234  org.wildfly.openssl.SSLImpl.freeSSL0(J)V (0 bytes) @ 0x00007f56d2ef6439 [0x00007f56d2ef6380+0xb9]
J 45100 C2 org.wildfly.openssl.OpenSSLEngine.shutdown()V (78 bytes) @ 0x00007f56d156db10 [0x00007f56d156da00+0x110]
j  org.wildfly.openssl.OpenSSLEngine.unwrap(Ljava/nio/ByteBuffer;[Ljava/nio/ByteBuffer;II)Ljavax/net/ssl/SSLEngineResult;+548
J 23960 C2 org.wildfly.openssl.OpenSSLSocket.runHandshake()V (761 bytes) @ 0x00007f56d27c2670 [0x00007f56d27c15e0+0x1090]
J 36830 C2 sun.net.www.protocol.https.HttpsClient.afterConnect()V (362 bytes) @ 0x00007f56d33c16a0 [0x00007f56d33bfc20+0x1a80]
J 32393 C2 sun.net.www.protocol.http.HttpURLConnection.getInputStream0()Ljava/io/InputStream; (2023 bytes) @ 0x00007f56d32a814c [0x00007f56d32a7c80+0x4cc]
J 60786 C2 org.apache.hadoop.fs.azurebfs.services.AbfsHttpOperation.processResponse([BII)V (545 bytes) @ 0x00007f56d4ebd32c [0x00007f56d4ebbca0+0x168c]
J 37025 C2 org.apache.hadoop.fs.azurebfs.services.AbfsRestOperation.executeHttpOperation(I)Z (392 bytes) @ 0x00007f56cfe01a24 [0x00007f56cfe01880+0x1a4]
J 52329 C2 org.apache.hadoop.fs.PrestoFileSystemCache$FileSystemWrapper.open(Lorg/apache/hadoop/fs/Path;I)Lorg/apache/hadoop/fs/FSDataInputStream; (18 bytes) @ 0x00007f56d47deaa8 [0x00007f56d47dd000+0x1aa8]

Above issue is observed in wildfly-openssl-1.0.4.Final , Is similar issue fixed in later version?
JVM error also shows unable to find method but i checked method is present

165764.953: G1IncCollectionPause             [     457          0             10    ]      [     0     0     0     1    83    ]  0
org.wildfly.openssl [ERROR] error:140C30F0:SSL routines:SSL_set_session:unable to find ssl method         vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count

java -version
java version "1.7.0_241"
OpenJDK Runtime Environment (rhel-2.6.20.0.el7_7-x86_64 u241-b01)
OpenJDK 64-Bit Server VM (build 24.241-b01, mixed mode)

@jaikiran @stuartwdouglas

GC pause gradually increase on using wildfly openssl

Hi,

I noticed that the GC pause gradually keeps increasing when I use wildfly OpenSSL. I am using openssl openssl-1.1.1d

$] /usr/java/jdk-11.0.9+11/bin/java -version
openjdk version "11.0.9" 2020-10-20
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.9+11)
Eclipse OpenJ9 VM AdoptOpenJDK (build openj9-0.23.0, JRE 11 Linux amd64-64-Bit Compressed References 20201022_810 (JIT enabled, AOT enabled)
OpenJ9   - 0394ef754
OMR      - 582366ae5
JCL      - 3b09cfd7e9 based on jdk-11.0.9+11)

$] ls /usr/local/ssl/lib
engines-1.1  libcrypto.a  libcrypto.so  libcrypto.so.1.1  libssl.a  libssl.so  libssl.so.1.1  pkgconfig

$] grep -i openssl logs/supervisord.log
Nov 30, 2021 7:16:50 AM org.wildfly.openssl.SSL init
INFO: WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.1d  10 Sep 2019

Java code:

org.wildfly.openssl.OpenSSLProvider.registerFirst();

JVM arg:
-Dorg.wildfly.openssl.path=/usr/local/ssl/lib

Maven:

 <dependency>
      <groupId>org.wildfly.openssl</groupId>
      <artifactId>wildfly-openssl-java</artifactId>
      <version>2.1.4.Final</version>
    </dependency>
    <dependency>
      <groupId>org.wildfly.openssl</groupId>
      <artifactId>wildfly-openssl</artifactId>
      <version>2.1.4.Final</version>
    </dependency>

Without wildfly OpenSSL

With wildfly OpenSSL

llegal reflective access on JDK > 9

With the new module system in Java, this artifact accesses illegal classes.

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.wildfly.openssl.ByteBufferUtils (file:/home/xx/.m2/repository/com/microsoft/azure/azure-data-lake-store-sdk/2.3.3/azure-data-lake-store-sdk-2.3.3.jar) to method java.nio.DirectByteBuffer.cleaner()
WARNING: Please consider reporting this to the maintainers of org.wildfly.openssl.ByteBufferUtils

This specific error is from the Azure Data Lake SDK, which uses:

<dependency>
	<groupId>org.wildfly.openssl</groupId>
	<artifactId>wildfly-openssl</artifactId>
	<version>1.0.0.CR5</version>
</dependency>

Here's the stacktrace from my use case:

[ERROR] TaskUtils$LoggingErrorHandler - Unexpected error occurred in scheduled task. <java.util.concurrent.CompletionException: java.lang.ExceptionInInitializerError>java.util.concurrent.CompletionException: java.lang.ExceptionInInitializerError
	at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
	at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1739)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.ExceptionInInitializerError
	at org.wildfly.openssl.ByteBufferUtils.<clinit>(ByteBufferUtils.java:39)
	at org.wildfly.openssl.OpenSSLEngine.readEncryptedData(OpenSSLEngine.java:338)
	at org.wildfly.openssl.OpenSSLEngine.wrap(OpenSSLEngine.java:444)
	at java.base/javax.net.ssl.SSLEngine.wrap(SSLEngine.java:479)
	at org.wildfly.openssl.OpenSSLSocket.write(OpenSSLSocket.java:501)
	at org.wildfly.openssl.OpenSSLOutputStream.write(OpenSSLOutputStream.java:46)
	at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
	at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
	at java.base/java.io.PrintStream.flush(PrintStream.java:417)
	at java.base/sun.net.www.MessageHeader.print(MessageHeader.java:301)
	at java.base/sun.net.www.http.HttpClient.writeRequests(HttpClient.java:655)
	at java.base/sun.net.www.http.HttpClient.writeRequests(HttpClient.java:666)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:711)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1602)
	at java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1509)
	at java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
	at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:329)
	at com.microsoft.azure.datalake.store.HttpTransport.makeSingleCall(HttpTransport.java:307)
	at com.microsoft.azure.datalake.store.HttpTransport.makeCall(HttpTransport.java:90)
	at com.microsoft.azure.datalake.store.Core.mkdirs(Core.java:429)
	at com.microsoft.azure.datalake.store.ADLStoreClient.createDirectory(ADLStoreClient.java:591)
	at storemanager.azure.DataLakeController.createFolder(DataLakeController.java:50)
	at storemanager.azure.DataLakeController.createAndWriteToFile(DataLakeController.java:92)
	at storemanager.socket.GateMasterConnection.uploadLogs(GateMasterConnection.java:154)
	at storemanager.azure.gatemaster.ManagedGateMaster.uploadLogs(ManagedGateMaster.java:129)
	at storemanager.azure.gatemaster.ManagedGateMaster.lambda$1(ManagedGateMaster.java:98)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
	... 3 more
Caused by: java.lang.IllegalAccessException: class org.wildfly.openssl.ByteBufferUtils cannot access class jdk.internal.ref.Cleaner (in module java.base) because module java.base does not export jdk.internal.ref to unnamed module @19e7a160
	at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361)
	at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591)
	at java.base/java.lang.reflect.Method.invoke(Method.java:558)
	at org.wildfly.openssl.ByteBufferUtils.<clinit>(ByteBufferUtils.java:36)
	... 29 more

It is manageable right now by appending --add-exports java.base/jdk.internal.ref=ALL-UNNAMED to your JVM launch arguments, that way you only get warned and the execution works as before the module system.

failed tests on clientsessiontest

LURE! - in org.wildfly.openssl.ClientSessionTest
testJsse(org.wildfly.openssl.ClientSessionTest) Time elapsed: 0.029 sec <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: arrays first differed at element [4]; expected:<-40> but was:<16>
at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:52)
at org.junit.Assert.internalArrayEquals(Assert.java:414)
at org.junit.Assert.assertArrayEquals(Assert.java:200)
at org.junit.Assert.assertArrayEquals(Assert.java:213)
at org.wildfly.openssl.ClientSessionTest$AssertingHandshakeCompletedListener.handshakeCompleted(ClientSessionTest.java:275)
at org.wildfly.openssl.OpenSSLSocket.invokeHandshakeListeners(OpenSSLSocket.java:256)
at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:360)
at org.wildfly.openssl.OpenSSLSocket.startHandshake(OpenSSLSocket.java:210)
at org.wildfly.openssl.ClientSessionTest.testSessionId(ClientSessionTest.java:233)
at org.wildfly.openssl.ClientSessionTest.testJsse(ClientSessionTest.java:58)

testSessionTimeout(org.wildfly.openssl.ClientSessionTest) Time elapsed: 0.034 sec <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: arrays first differed at element [4]; expected:<-36> but was:<-118>
at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:52)
at org.junit.Assert.internalArrayEquals(Assert.java:414)
at org.junit.Assert.assertArrayEquals(Assert.java:200)
at org.junit.Assert.assertArrayEquals(Assert.java:213)
at org.wildfly.openssl.ClientSessionTest.testSessionTimeout(ClientSessionTest.java:85)

testSessionSize(org.wildfly.openssl.ClientSessionTest) Time elapsed: 0.034 sec <<< FAILURE!
org.junit.internal.ArrayComparisonFailure: arrays first differed at element [4]; expected:<-53> but was:<-39>
at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:52)
at org.junit.Assert.internalArrayEquals(Assert.java:414)
at org.junit.Assert.assertArrayEquals(Assert.java:200)
at org.junit.Assert.assertArrayEquals(Assert.java:213)
at org.wildfly.openssl.ClientSessionTest.testSessionSize(ClientSessionTest.java:147)

Running org.wildfly.openssl.SslCiphersTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec - in org.wildfly.openssl.SslCiphersTest

Results :

Failed tests:
ClientSessionTest.testJsse:58->testSessionId:233 arrays first differed at element [4]; expected:<-40> but was:<16>
ClientSessionTest.testSessionTimeout:85 arrays first differed at element [4]; expected:<-36> but was:<-118>
ClientSessionTest.testSessionSize:147 arrays first differed at element [4]; expected:<-53> but was:<-39>

How to set up PSK ciphers

Apparently this can support all the ciphers that OpenSSL can, including the PSK ones that I need. However, I have no idea how to set up a connection using them. From C I use SSL_set_psk_client_callback which works just fine, but nothing of that sort is even called in the Java version. Is there any way to use PSK modes at all?

add ECC support

https://github.com/wuhongzhi/wildfly-openssl/blob/master/java/src/main/java/org/wildfly/openssl/OpenSSLContextSPI.java

/**
 * Setup the SSL_CTX
 *
 * @param kms Must contain a KeyManager of the type
 *            {@code OpenSSLKeyManager}
 * @param tms
 */
private synchronized void init(KeyManager[] kms, TrustManager[] tms) throws KeyManagementException {
    if (initialized) {
        LOG.warning(Messages.MESSAGES.ignoringSecondInit());
        return;
    }
    SSL_INSTANCE = SSL.getInstance();
    try {
        // Load Server key and certificate
        X509KeyManager keyManager = chooseKeyManager(kms);
        if (keyManager != null) {
            for (String algorithm : ALGORITHMS) {
                final String[] aliases = keyManager.getServerAliases(algorithm, null);
                if (aliases != null && aliases.length != 0) {
                    for(String alias: aliases) {
                        X509Certificate[] certificates = keyManager.getCertificateChain(alias);
                        if (certificates == null || certificates.length == 0) continue;
                        byte[][] certs = new byte[certificates.length][];
                        int idx = 0;
                        for (X509Certificate c: certificates) {
                        	certs[idx++] = c.getEncoded();
                        }
                        PrivateKey key = keyManager.getPrivateKey(alias);
                        if(key == null || key.getEncoded() == null) {
                            continue;
                        }
                        if (LOG.isLoggable(Level.FINE)) {
                            LOG.fine("Using alias " + alias + " for " + algorithm);
                        }
                        StringBuilder sb = new StringBuilder(String.format(BEGIN_CERT, algorithm));
                        sb.append(Base64.getMimeEncoder(64, new byte[]{'\n'}).encodeToString(key.getEncoded()));
                        sb.append(String.format(END_CERT, algorithm));
                        switch (algorithm) {
						case "RSA":
							idx = SSL.SSL_AIDX_RSA;
							break;
						case "DSA":
							idx = SSL.SSL_AIDX_DSA;
							break;
						case "EC":
							idx = SSL.SSL_AIDX_ECC;
							break;
						}
                        SSL_INSTANCE.setCertificate(ctx, certs[0], 
                        		Arrays.copyOfRange(certs, 1, certs.length), 
                        		sb.toString().getBytes(StandardCharsets.US_ASCII), idx);
                        break;
                    }
                }
            }
        }

https://github.com/wuhongzhi/wildfly-openssl/blob/master/java/src/main/java/org/wildfly/openssl/SSL.java

static final int SSL_AIDX_ECC = 3;

double free crash for client mode in high concurrency mode

Hi,
Last year we met a crash when running in client mode under high concurrnecy scenario, reported a double free error. It's been a long time so I can't remember the very details, but I'll try to describe it as clear as I can:

Suppose there is a session created in thread A, and A is using the session, and the session is stored in clientSessionContext, and then another thread B is creating a client mode sslEngine, then thread B may be assigned the session(by tryAttachClientsideSession), then do tls_process_client_hello, then it found the session is not valid, so thread B will create a new session and free this stored session, At the same time, thread C may creating another clientmode engine, and thread C may trying to call removeCacheEntry(xxx, true) and will free the session too.
This will cause a double free.

Besides, there is a potenial memory leak if store many session in sessions without removing them.

1.0.2.Final Release - error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

Getting error with 1.0.2.Final version when HTTPS request is initiated

error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed

However no issues when 1.0.0.CR5 is used.

Use custom OpenSSL engine - GOST TLS

How can I use the GOST engine from the custom assembly OpenSSL

OpenSSL works great with this engine, as does curl. But when you try to use in Java - nothing comes out

For example, I declare
System.setProperty ("org.wildfly.openssl.path", "/usr/local/ssl/lib/");
In log:
2020-02-19 14: 19: 52.581 INFO 28673 --- [restartedMain] org.wildfly.openssl.SSL: WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.1d 10 Sep 2019

It's fine, but not work.
when trying to connect to the host, I get an error:

org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://{host}/api/v1/account/login": 
error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure; nested exception is javax.net.ssl.SSLException: 
error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Block of code with details SSLContext


KeyStore trustedKeyStore = KeyStore.getInstance ("JKS");
trustedKeyStore.load (new FileInputStream ("/home/ubuntu/demo/trustStore"), "truststore" .toCharArray ());

TrustManagerFactory tmf = TrustManagerFactory.getInstance (TrustManagerFactory.getDefaultAlgorithm ());
tmf.init (trustedKeyStore);

SSLContext sslContext = SSLContext.getInstance ("openssl.TLS");
sslContext.init(null, tmf.getTrustManagers(), null);

Is there a way to set specific curves to use on the SSL channel?

I want to be able to set elliptical curves (P-256 and P-384) that will be advertised on the SSL handshake in the ClientHello message to the server. With wildfly-openssl v1.0.4.Final, tcpdump shows it's selecting weaker curves as well.

Is there an API or a suggestion on code change that we'll have to do to achieve this? There is support to set specific ciphers, but not curves.

java.lang.UnsatisfiedLinkError: no wfssl in java.library.path

the error stack:

Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1867)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
... 33 common frames omitted

what should I config my project on linux os?
thanks very much.

20% higher CPU with Wildfly-OpenSSL

Our app receives and establishes a large amount of TLS connections per minute. I noticed that CPU utilization is about 20% higher with Wildfly-OpenSSL enabled as compared to standard JSSE activated (incidentally, in this environment, our app is running inside a virtual machine with 16 CPU cores assigned). I'm not entirely clear on why there would be such a huge difference. Tomorrow, I'll run in a profiler and see what's up.

Interestingly, no. packets and bytes transferred is significantly lower with Wildfly-OpenSSL enabled. At first I thought, that after installing Wildfly that some TLS connections where somehow being rejected, but alas I cannot not confirm this. Its baffling because I remain unconvinced that differences of this magnitude could be attributed to differences in implementation between OpenSSL and JSSE. Could it be difference in session handling option?

Comment?

how to add new cipher into wildfly

Hello,
i had modify openssl and built it ,add some ciphers into openssl 1.0.2.
how do i add the ciphers into wildfly project?
could you give me some code example or doc ?

Optimization : Payload > 16KB, gets broken into 16KB + 1KB packets over TCP

I did a benchmark for payload 4MB over SSL and observed over wireshark. Payload is broken into 16KB + 1KB.

Benchmark Result - With/Without the optimization

Change	Iteration	Size	50th	Avg	75th	90th	95th	99th	Max	Min
17KB Buffer	10000	4MB	59.0 ms	69.71 ms	64.75 ms	68.0 ms	70.0 ms	85.5 ms	2582.0 ms	45.0 ms
16KB Buffer	10000	4MB	41.0 ms	60.01 ms	45.0 ms	49.0 ms	51.0 ms	55.2 ms	4738.0 ms	34.0 ms

Cipher suite used is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, Orthogonal to this change.

Reduced DIRECT_POOL for write to 16KB.

Support of FIPS mode and PKCS11

Hello,

I read about this JIRA https://jira.jboss.com/browse/JBEAP-10396 and I was wondering if wildfly-openssl support PKCS11 and FIPS mode (with an openssl in FIPS mode) ?
To be used with a USB token compliant with FIPS 140-2, in my case.

Thanks for your clarification.

Update Readme file reflecting changes after the repository has been split up

Some Readme file update would be beneficial to reflect changes and add references after this repository has been split up into two separate repositories. Having reference there would be nice https://github.com/wildfly-security/wildfly-openssl-natives.

There is a miss in OpenSSLSocket

the code in OpenSSLSocket

public int read() throws IOException {
    byte[] b = new byte[1];
    read(b);
    return b[0] & 0xFF;
}

==================================
it should be accoding to api of java
public int read() throws IOException {
byte[] b = new byte[1];
int r = read(b);
if (r == -1) return r;
return b[0] & 0xFF;
}

SSLEngine.unwrap seems to lose data if the source network data being unwrapped spans two/multiple TCP packets

I have started experimenting the usage of WildFly OpenSSL library as a SSL provider in context of a runtime server/project (not related to WildFly server). I have stumbled upon, what appears to be some kind of issue, in WildFly OpenSSL or OpenSSL. Given my lack of knowledge in either of these projects or the underlying code, I haven't been able to fully narrow this issue down in terms of what pieces of code contributes to it. However, here's what I think is happening based on analyzing logs and wireshark captures from different completes across multiple runs:

The server in question uses WildFly OpenSSL provider and internally uses SSLEngine API to wrap/unwrap data on an underlying SocketChannel using Java NIO selectors.
A typical "write" looks something like this which uses the SSLEngine:


	final ByteBuffer networkWriteBuffer = ...
	final ByteBuffer[] srcs = ...
    for (i = 0;  i < length; i++) {
        if (srcs[i].hasRemaining()) {
			SSLEngineResult wrapResult = sslEngine.wrap(src[i], networkWriteBuffer);
    		// deal with the result...
    		// write out to the underlying socketchannel, the "wrapped" data
    		socketChannel.write(networkWriteBuffer);
    		...
        }
        ....
    }

Please consider this a pseudo-code and assume that the necessary NIO selector semantics and the ByteBuffer usage semantics are being propely handled in the real code.

So what's essentially going on in the send side is that for each source data, the SSLEngine is used to wrap the data and write it over the socket channel.

A typical "read" on the other side of the SocketChannel uses the SSLEngine to unwrap the data and looks like:

        final ByteBuffer networkReadBuffer = ...
	final ByteBuffer appData = ....
	// read the data from the socket channel
	socketChannel.read(networkReadBuffer);
	// now use the SSLEngine to unwrap the data
        SSLEngineResult unwrapResult = sslEngine.unwrap(networkReadBuffer, appData);
        // deal with the result....

So the read side just keeps reading of the socket channel (whenever the relevant Selector is notified about data being available) and then unwrapping that data into a internal application specific buffer.

The issue I keep running into seems to be on the unwrapping part (or at least that's where I can "notice" it). Based on my wireshark captures and log analysis what I see is happening is that if the write side happens to (wrap and) send more than one packet of TCP data on the socket channel (I have tested consistently with two packets) and if the read side happens to read both those TCP packets in one go and pass it to sslEngine for unwrapping, the engine seems to unwrap just one packet and return back a OK result and the second packet is never returned back into the target buffer that's sent to the unwrap call. To explain a bit more concisely, consider the following sequence of events:

- Sender:
	T1: SSLEngine.wrap(dataOne) generates 33 bytes of data
	T2: write dataOne (==33 bytes) on to the socket channel
	T3: SSLEngine.wrap(dataTwo) generates 65 bytes of data
	T4: write dataTwo (==65 bytes) on to the socket channel

- Receiver:
	T5: read into incomingData from socket channel. Reads 98 bytes of data into the incomingData
	T6: SSLEngine.unwrap(incomingData of 98 bytes, dest). This ends up with the `dest` buffer being updated with 4 bytes of data and a SSLEngineResult which looks like:
		
		Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 98 bytesProduced = 4

The unwrap ends up producing wrong (lesser amount) of data in the above case. The important piece here is that this seems to happen only when the unwrap is fed with incoming data that belonged to 2 separate TCP packets that were read off the socket channel (since it was available on the socket). If it so happens that the socket read returns just one packet and that then is passed on to the unwrap API, one each at a time, then it ends up processing it correctly. In other words, the following sequence works:

- Sender:
	T1: SSLEngine.wrap(dataOne) generates 33 bytes of data
	T2: write dataOne (==33 bytes) on to the socket channel
	T3: SSLEngine.wrap(dataTwo) generates 65 bytes of data
	T4: write dataTwo (==65 bytes) on to the socket channel

- Receiver:
	T5: read into incomingData from socket channel. Reads 33 bytes of data into the incomingData
	T6: SSLEngine.unwrap(incomingData of 33 bytes, dest). This ends up with the `dest` buffer being updated with (correct) 4 bytes of data and a (correct) SSLEngineResult which looks like:
		
		Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 33 bytesProduced = 4

	T7: go back to reading off the socket channel. Reads 65 bytes of data into the incomingData
	T8: SSLEngine.unwrap(incomingData of 65 bytes, dest). This ends up with the `dest` buffer being updated with (correct) 36 bytes of data and a (correct) SSLEngineResult which looks like:

		Status = OK HandshakeStatus = NOT_HANDSHAKING bytesConsumed = 65 bytesProduced = 36

I hope this information is good enough to probably understand where the issue might be. So far, based on what I see in the server's usage of SSLEngine APIs and its usage of Java NIO selector APIs, I don't see anything obviously incorrect that it's doing. In fact, it's currently fully functional with the regular SSLEngine that's shipped in Java runtime (currently using Java 8). Having said that, if this appears to be some kind of an issue with the API usage, do let me know, I'll try and dig deeper in that part of their code. Unfortunately, I don't have an easy way to reproduce this outside of that library to narrow it down to this implementation of the SSL engine.

Environment details:

Operating system: Mac OS
Java version:

java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

OpenSSL version (both 1.0.2 and 1.1.0): OpenSSL 1.0.2l 25 May 2017 and OpenSSL 1.1.0f 25 May 2017
WildFly OpenSSL version: Latest upstream (1.0.3.Final-SNAPSHOT)

Created by mistake

choosing wrong server certificate

I managed to get Wildfly-openssl working, but there were a couple of issues along the way. One such issue is that it chose the wrong server certificate for submission to client. It doesn't appear to call chooseServerAlias(..) method to match the selected alias in the KeyManager. Rather, it just calls keyManager.getServerAliases()..and takes the first alias on the list. This could very well create incompatibilities, esp. in scenarios where multiple certs are installed, some of which are not intended for presentation to the client.

Issue when using WildFly OpenSSL 1.1.3.Final with Jetty Server 9.4.34

I'm trying to use WildFly OpenSSL with Jetty Server, but I'm observing an odd behavior.
Attached are 2 classes, the server and the client.

WildFly OpenSSL: 1.1.3.Final
Jetty Server: 9.4.34.v20201102

The server is configured to use OpenSSL.
In the client, when using the default JSSE provider, everything works as expected, and the certificates are available in the request in the server when reading the attribute javax.servlet.request.X509Certificate.

The issue is present when I set the client to use OpenSSL. When using OpenSSL, the request is completed and the response is received by the client, but the server shows two strange outcomes:

the certificates are not available in the request object; AND
an NPE results from an invalid session:

2020-11-05 16:55:44.993:WARN:oejs.SecureRequestCustomizer:qtp1440047379-21: Unable to get secure details 
java.lang.NullPointerException: while trying to get the length of a null array loaded from local variable 'b'
	at org.eclipse.jetty.util.TypeUtil.toHexString(TypeUtil.java:524)
	at org.eclipse.jetty.server.SecureRequestCustomizer$SslAttributes.getSslSessionData(SecureRequestCustomizer.java:386)
	at org.eclipse.jetty.server.SecureRequestCustomizer$SslAttributes.<init>(SecureRequestCustomizer.java:336)
	at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:283)
	at org.eclipse.jetty.server.SecureRequestCustomizer.customize(SecureRequestCustomizer.java:210)
	at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:379)
	at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:556)
	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:375)
	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
	at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
	at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:540)
	at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:395)
	at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:161)
	at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
	at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773)
	at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:905)
	at java.lang.Thread.run(Thread.java:836)

====== CERTIFICATES: null

When looking further into the NPE, I verified that:

when the handshake is finished, the session id cannot be found (call to https://github.com/wildfly-security/wildfly-openssl/blob/1.x/java/src/main/java/org/wildfly/openssl/OpenSSLEngine.java#L1099 returns null);
as a consequence, any calls to sslEngine.getSession(); (https://github.com/wildfly-security/wildfly-openssl/blob/1.x/java/src/main/java/org/wildfly/openssl/OpenSSLEngine.java#L977) return the handshake session as opposed to an actual session;
the Java context is never called to add the new session here: https://github.com/wildfly-security/wildfly-openssl/blob/1.x/java/src/main/java/org/wildfly/openssl/OpenSSLSessionContext.java#L104;
given that, Jetty gets the handshake session here: https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/SecureRequestCustomizer.java#L264;
the handshake session doesn't have an ID, causing an NPE here: https://github.com/eclipse/jetty.project/blob/jetty-9.4.x/jetty-server/src/main/java/org/eclipse/jetty/server/SecureRequestCustomizer.java#L386;
also, as mentioned before, the incoming request doesn't have the attribute javax.servlet.request.X509Certificate filled.

Is there something missing in my configuration?

Archive.zip

Fails on Windows 10 - Caused by: java.lang.IllegalStateException: Could not load libeay32.dll

tried
Caused by: java.lang.IllegalStateException: Could not load libeay32.dll at org.wildfly.openssl.SSLImpl.initialize0(Native Method) at org.wildfly.openssl.SSLImpl.initialize(SSLImpl.java:33) at org.wildfly.openssl.SSL.init(SSL.java:185) at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:123) at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLS_1_0_ContextSpi.<init>(OpenSSLContextSPI.java:441) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.security.Provider$Service.newInstance(Provider.java:1595)
Maven Depedency
<dependency> <groupId>org.wildfly.openssl</groupId> <artifactId>wildfly-openssl</artifactId> <version>1.0.0.CR5</version> </dependency>

Usage in Java Code
`
static {
OpenSSLProvider.register();
}

...

SSLContext sslContext = SSLContext.getInstance("openssl.TLSv1");
`

Shouldn't wildfly-openssl dependency does not require to put libeay32 and should be packaged part of the library dependency only ? Any idea why i am getting this error ?

Unable to add Server Name Indication

Hi,
I'm trying to set Server Name Indication (SNI) using SSLParameters, but in "org/wildfly/openssl/wildfly-openssl/1.0.4.Final/wildfly-openssl-1.0.4.Final.jar!/org/wildfly/openssl/OpenSSLEngine.class", "OpenSSLEngine.setSSLParameters(SSLParameters sslParameters)" doesn't apply "SNIServerName", it looks like a bug to me, can anyone confirm or suggest an alternative way to set SNI? Thanks.

sslshutdown while in init and memory leak after fix it

https://github.com/wildfly/wildfly-openssl/blob/9e9f88a58e95052abee01576f019fcc09ed9e965/java/src/main/java/org/wildfly/openssl/OpenSSLEngine.java#L696

we used to have an SSL error: SSL_shutdown() failed (SSL: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init).

so, I add a condition here:
if (SSL.getInstance().isInInit(ssl) == 0) {
SSL.getInstance().shutdownSSL(ssl);
}
(both nginx and netty have a similiar patch here)

But it seems after the fix, there is a memory leak, those in-hand-shake SSLEngine will never got shutdown, and they will never be freed, and takes a lot of out-of-heap memory and crashes JVM.

In fact, there is no strong reference to those SSLEngine instances, only some weak references, so it will not be finalized by GC (finalizer thread), even after a system.gc(), because heap is big enough.
I did another test, by using an extremely small heap size, and it works fine, which means, those SSLEngine instances can be correctly freed only when there is a big pressure to heap, and if heap is big, those SSLEngine instances will not be finalized, and take lots of out-of-heap memory.

and finally I have to change application code to workaround this problem. But I think maybe it's better to fix it in wildfly-openssl.

This server's certificate chain is incomplete. Grade capped to B

Hi, I got "This server's certificate chain is incomplete. Grade capped to B" tip on ssl test when I use openssl,
but I get full cert chain when I use jdkssl, is the feature of openssl or my configuration incorrect?

Failing while building wildfly-openssl:1.0.4.Final using mvn clean install (wildfly-openssl:1.0.4.Final)

Package artifact id: wildfly-openssl

source code url: https://github.com/wildfly-security/wildfly-openssl/tree/1.0.4.Final

Issue Description: Failing while building wildfly-openssl:1.0.4.Final using mvn clean install (wildfly-openssl:1.0.4.Final)

JDK Version: 1.8

Build CMD: mvn clean install

MVN Version: 3.9.6

Error Log:

[ERROR] Command execution failed.
java.io.IOException: Cannot run program "nmake" (in directory "C:\code\Code-Latest\wildfly-openssl1.0.4.Final\code\wildfly-openssl\windows-x86_64"): CreateProcess error=2, The system cannot find the file specified
at java.lang.ProcessBuilder.start (ProcessBuilder.java:1048)
at java.lang.Runtime.exec (Runtime.java:621)
at org.apache.commons.exec.launcher.Java13CommandLauncher.exec (Java13CommandLauncher.java:61)
at org.apache.commons.exec.DefaultExecutor.launch (DefaultExecutor.java:279)
at org.apache.commons.exec.DefaultExecutor.executeInternal (DefaultExecutor.java:336)
at org.apache.commons.exec.DefaultExecutor.execute (DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:764)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine (ExecMojo.java:711)

attach
Failed_java_8.txt
ment: build log attached (jdk 1.8)

OS: windows 10

WFOPENSSL0030 Running handshake with buffered unwrapped data

Not sure what the implications of error is? It occurs in the latest version of Wildfly.

2018-08-02 21:14:49.414 ERROR - Exception in thread "pool-25-thread-97"
2018-08-02 21:14:49.414 ERROR - java.lang.IllegalStateException: WFOPENSSL0030 Running handshake with buffered unwrapped data
2018-08-02 21:14:49.414 ERROR - at org.wildfly.openssl.OpenSSLSocket.runHandshake(OpenSSLSocket.java:318)
2018-08-02 21:14:49.414 ERROR - at org.wildfly.openssl.OpenSSLSocket.startHandshake(OpenSSLSocket.java:210)
2018-08-02 21:14:49.414 ERROR - at org.subethamail.smtp.command.StartTLSCommand.execute(MailArchiva:59)
2018-08-02 21:14:49.414 ERROR - at org.subethamail.smtp.server.CommandHandler.handleCommand(MailArchiva:99)
2018-08-02 21:14:49.414 ERROR - at org.subethamail.smtp.server.Session.runCommandLoop(MailArchiva:244)
2018-08-02 21:14:49.414 ERROR - at org.subethamail.smtp.server.Session.run(MailArchiva:145)
2018-08-02 21:14:49.414 ERROR - at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
2018-08-02 21:14:49.414 ERROR - at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
2018-08-02 21:14:49.414 ERROR - at java.lang.Thread.run(Thread.java:748)

Failed to build 2.x version due to lack of wildfly-openssl-linux-aarch64 souce code

Enviroment: Linux aarch64
It seems that wildfly-openssl-linux source code has been removed since 2.x version by providing central maven jar directly. And there is no aarch64 version in central maven. How can we build for aarch64? Or how can we get the corresponding wildfly-openssl-linux source code? So we can build those tar by ourselves.

wildfly-security / wildfly-openssl Goto Github PK

wildfly-openssl's People

Contributors

Stargazers

Watchers

Forkers

wildfly-openssl's Issues

the code in OpenSSLSocket

Recommend Projects

Recommend Topics

Recommend Org