wolfssljni
wolfssljni copied to clipboard
wolfSSL
no getApplicationProtocol() method in WolfSSLEngine
Hi, I am trying to use wolfssljni with our undertow server with HTTP2 on TLSv1.2 on my MAC (dev env) Java 11. I am getting the below exception:
2021-12-23 22:44:51.043 [ERROR] [XNIO-1 I/O-2] io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener:handleEvent(407): UT005090: Unexpected failure
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:124) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener.handleEvent(AlpnOpenListener.java:365) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:313) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.AlpnOpenListener.handleEvent(AlpnOpenListener.java:67) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.nio.QueuedNioTcpServer2$$Lambda$131/0x0000000000000000.run(Unknown Source) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:479) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
Caused by: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
... 13 more
Caused by: java.lang.UnsupportedOperationException
at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1328) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
... 13 more
While I debugged the code, the ALPN listener of undertow is calling getApplicationProtocol() method of SSLEngine which in this case is WolfSSLEngine and it doesn't implement it. I tried to implement the method with return values as null but the h2 upgrade is not working properly.
@Override
public String getApplicationProtocol() {
return null;
}
I found a similar Implementation here: https://github.com/wildfly-security/wildfly-openssl/blob/master/java/src/main/java/org/wildfly/openssl/OpenSSLEngine.java#L1566 but couldn't port it in WolfSSLEngine properly.
I would appreciate it if someone here can help me.
Before implementing getApplicationProtocol()
curl -vk https://localhost:8081/?exchange=test --data 'msg'
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8081
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to localhost:8081
After
curl -vk https://localhost:8081/?exchange=test --data 'msg'
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: OU=Domain Control Validated; CN=*.server.test.io
* start date: Jun 1 03:49:53 2021 GMT
* expire date: Jul 3 03:49:53 2022 GMT
* issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
* SSL certificate verify ok.
> POST /?exchange=mopub HTTP/1.1
> Host:bids-ams.server.test.io
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 1535
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server
* Closing connection 0
Hi @onlynishant, thanks for letting us know about this gap in our SSLEngine implementation! Let me look into this and get back to you. For reproduction locally on our end, would we be able to easily reproduce your undertow server install/configuration?
hi @cconlon yes it should be fairly simple.
let me also paste my sample code here : https://drive.google.com/file/d/10n50Sy_DZIZOAH2r1ZjdAI9Ckd3e3doN/view?usp=sharingmv
pom.xml
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-core</artifactId>
<version>2.2.14.Final</version>
</dependency>
the command I used to build wolfssl
./configure --enable-intelasm --enable-aesni --enable-sp --enable-sp-asm --enable-jni --enable-alpn --enable-tlsv12 --enable-tls13 --enable-fastmath --enable-pkcs12
Hi @onlynishant, pull request https://github.com/wolfSSL/wolfssljni/pull/84 implements SSLEngine.getApplicationProtocol() and should resolve your issue. I was able to reproduce your Undertow test case locally and have verified these changes fix the issue for me. Thanks for the test code!
Can you test out this fix and let me know if you are seeing any other issues?
Thanks, Chris
@cconlon Thanks for the quick fix. I confirm that the reported issue is fixed for TLSv1.2 however I see a different error while using TLSv1.3
Security.insertProviderAt(new WolfSSLProvider(), 1);
SSLContext sslContext = SSLContext.getInstance("TLSv1.3");
» curl -vk https://localhost:8081/\?exchange\=test --data 'msg' 1 ↵
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, handshake failure (552):
* error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
* Closing connection 0
curl: (35) error:14004410:SSL routines:CONNECT_CR_SRVR_HELLO:sslv3 alert handshake failure
without wolfssl it works fine:
» curl -vk https://localhost:8081/\?exchange\=test --data 'msg'
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8081 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: OU=Domain Control Validated; CN=*.server.test.io
* start date: Jun 1 03:49:53 2021 GMT
* expire date: Jul 3 03:49:53 2022 GMT
* issuer: C=US; ST=Arizona; L=Scottsdale; O=GoDaddy.com, Inc.; OU=http://certs.godaddy.com/repository/; CN=Go Daddy Secure Certificate Authority - G2
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fb9cb808200)
> POST /?exchange=test HTTP/2
> Host: localhost:8081
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 3
> Content-Type: application/x-www-form-urlencoded
>
* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 204
< content-type: text/plain
< date: Wed, 29 Dec 2021 07:16:06 GMT
<
* Connection #0 to host localhost left intact
* Closing connection 0
I am expecting that TLSv1.3 context should also support TLSv1.2 like other Providers.
Hi @onlynishant,
The way wolfJSSE SSLContext creation currently works is that when a user specifies a specific protocol version, that is the only protocol that will be supported by that SSLContext. At the native level, that is equivalent to doing:
wolfSSL_CTX_new(wolfTLSv1_3_server_method());
Based on the Java Secure Socket Extension JSSE Reference Guide, when creating a SSLContext and specifying a specific protocol version, only that specific version is guaranteed to be supported by that SSLContext. The underlying provider may choose to also support other protocols (which is what appears the SunJSSE provider does):
SSLContext objects are created using the getInstance() factory methods of the SSLContext class.
These static methods each return an instance that implements at least the requested secure socket
protocol. The returned instance may implement other protocols, too. For example, getInstance("TLSv1")
may return an instance that implements TLSv1, TLSv1.1, and TLSv1.2.
Our current viewpoint is that locking the SSLContext to the specified protocol provides the users with more assurances that their desired security level will be met, and the connection will not negotiate a lower protocol instead. If a user does want to allow for downgrade in TLS versions, the "TLS" version should be used when creating an SSLContext object. For example:
SSLContext sslContext = SSLContext.getInstance("TLS");
Are you able to use the more generic "TLS" version when creating your SSLContext, if you are interested in having that session downgrade? If TLS 1.3 is enabled in native wolfSSL, using "TLS" will start at TLS 1.3, then downgrade to TLS 1.2 (etc) as needed.
Thanks, Chris
Hi @cconlon thanks for the clarification. I don't see handshake failure error with TLS with curl.
I did a few more tests and noticed that while using OpenSSL client, I get some exceptions. You can try it in the same example I shared. I also got the same exception in production so it seems it's not the issue with openssl.
SSLContext sslContext = SSLContext.getInstance("TLSv1.2", "wolfJSSE");
$ openssl version 1 ↵
OpenSSL 1.1.1l 24 Aug 2021
$ curl -k https://localhost:8081/\?exchange\=test --data 'msg'
OK%
$ openssl s_client -connect localhost:8081 -tls1_2
....
....
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5791 bytes and written 320 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: F4642A620674B3A7F1BE66CA0AD058749440C421A92445F873D5543829A1CB86
Session-ID-ctx:
Master-Key: 2456AE01AD181FE284507F34464C0D0AB399666E6924478DA23FB211FA7B21D07FA5A1787D75DB0C35CB5699EC81CEC8
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - fe b4 04 2b 6c a5 8c e1-61 f4 d4 8d 2f a6 51 10 ...+l...a.../.Q.
0010 - 15 cd 31 1a 8d 08 d7 dd-81 5e 7b 93 3e 7c ff 5f ..1......^{.>|._
0020 - 00 4c 05 30 8b 1b bb ed-1f db eb 91 02 b7 ca 25 .L.0...........%
0030 - 20 99 59 ef ce e0 11 b1-86 9b 5d f7 99 f1 38 87 .Y.......]...8.
0040 - 90 95 a8 d0 13 f4 30 85-4d c5 89 19 63 d5 12 43 ......0.M...c..C
0050 - 5c 06 6e d4 ce c8 d5 4a-9c e7 b4 9e a0 66 71 0c \.n....J.....fq.
0060 - 29 ba c7 58 01 cf 6d 15-bc 2e f1 3c 79 57 44 cb )..X..m....<yWD.
0070 - a6 0f 96 22 11 87 bf a1-19 08 79 92 e5 1c 00 00 ..."......y.....
0080 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 ..............
Start Time: 1640849600
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
read:errno=0
Exception in logs:
2021-12-30 12:56:42.526 [ERROR] [XNIO-1 I/O-4] io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener:handleEvent(407): UT005090: Unexpected failure
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:124) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener.handleEvent(AlpnOpenListener.java:365) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.AlpnOpenListener$AlpnConnectionListener.handleEvent(AlpnOpenListener.java:341) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1254) [undertow-core-2.2.14.Final.jar:2.2.14.Final]
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591) [xnio-nio-3.8.4.Final.jar:3.8.4.Final]
Caused by: java.lang.reflect.InvocationTargetException
at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
... 7 more
Caused by: java.lang.NullPointerException
at java.lang.String.<init>(String.java:3781) ~[?:?]
at com.wolfssl.WolfSSLSession.getAlpnSelectedString(WolfSSLSession.java:2695) ~[wolfssl-jsse.jar:?]
at com.wolfssl.provider.jsse.WolfSSLEngineHelper.getAlpnSelectedProtocolString(WolfSSLEngineHelper.java:261) ~[wolfssl-jsse.jar:?]
at com.wolfssl.provider.jsse.WolfSSLEngine.getApplicationProtocol(WolfSSLEngine.java:524) ~[wolfssl-jsse.jar:?]
at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at io.undertow.protocols.alpn.JDK9AlpnProvider.getSelectedProtocol(JDK9AlpnProvider.java:122) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
... 7 more
Hi @onlynishant, thanks! I pushed one more commit to the open pull request that should fix this NullPointerException:
https://github.com/wolfSSL/wolfssljni/pull/84/commits/c90b73841a1e9dd0a65c35f74a6f83151ed01792
Hi @cconlon I still see exceptions in the production. After 4-5 mins of use, logs are flooded with exceptions:
2022-01-04 05:18:45.094 [ERROR] [XNIO-1 task-26] io.server.test.handler.RequestHandler$RequestProcessor$1:lambda$onSuccess$0(537): Exception:
java.lang.IllegalArgumentException: Invalid Parameter(s)
at javax.net.ssl.SSLEngineResult.<init>(SSLEngineResult.java:231) ~[?:?]
at javax.net.ssl.SSLEngineResult.<init>(SSLEngineResult.java:196) ~[?:?]
at com.wolfssl.provider.jsse.WolfSSLEngine.wrap(WolfSSLEngine.java:297) ~[jsse-1.jar:?]
at io.undertow.server.protocol.http.ALPNLimitingSSLEngine.wrap(ALPNLimitingSSLEngine.java:136) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.protocols.ssl.SslConduit.wrapAndFlip(SslConduit.java:987) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.protocols.ssl.SslConduit.doWrap(SslConduit.java:921) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.protocols.ssl.SslConduit.write(SslConduit.java:397) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:260) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:639) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:148) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:154) ~[xnio-api-3.8.4.Final.jar:3.8.4.Final]
at io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:187) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2164) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:248) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:348) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:316) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:354) ~[undertow-core-2.2.14.Final.jar:2.2.14.Final]
at io.server.test.exchange.BaseExchange.sendResponse(BaseExchange.java:1194) ~[test-java-1.0-SNAPSHOT.jar:?]
at io.server.test.handler.RequestHandler$RequestProcessor.postProcess(RequestHandler.java:654) ~[test-java-1.0-SNAPSHOT.jar:?]
at io.server.test.handler.RequestHandler$RequestProcessor$1.lambda$onSuccess$0(RequestHandler.java:535) [test-java-1.0-SNAPSHOT.jar:?]
at io.server.test.handler.RequestHandler$RequestProcessor$1$$Lambda$2271/000000000000000000.run(Unknown Source) [test-java-1.0-SNAPSHOT.jar:?]
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) [jboss-threads-3.1.0.Final.jar:3.1.0.Final]
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2019) [jboss-threads-3.1.0.Final.jar:3.1.0.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558) [jboss-threads-3.1.0.Final.jar:3.1.0.Final]
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1449) [jboss-threads-3.1.0.Final.jar:3.1.0.Final]
at org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1280) [xnio-api-3.8.4.Final.jar:3.8.4.Final]
at java.lang.Thread.run(Thread.java:836) [?:?]
There is also a msg during app start
Unable to set FIPS callback without wolfCrypt FIPS code
PS: this is not the sample test code I shared. However request/response structure is almost same
@onlynishant Sorry for the delay on this issue. Are you still seeing this issue with the latest wolfssljni master? We have made some fixes/changes to our SSLEngine code since your last test above.
@cconlon I am using a diff lib now. I will try to test the latest code when I get some time. Thanks
Hi @onlynishant, do you think you will have time to re-test this using our current master branch? Or should I go ahead and close this issue for now?
Hi @cconlon, I am afraid that I might not be able to prioritize it soon so please close it.