no getApplicationProtocol() method in WolfSSLEngine #82

onlynishant · 2021-12-23T18:13:54Z

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

The text was updated successfully, but these errors were encountered:

cconlon · 2021-12-23T18:24:28Z

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?

onlynishant · 2021-12-23T20:45:48Z

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

cconlon · 2021-12-28T23:51:26Z

Hi @onlynishant, pull request #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

onlynishant · 2021-12-29T07:26:48Z

@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.

cconlon · 2021-12-29T17:08:43Z

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

onlynishant · 2021-12-30T07:37:39Z

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

cconlon · 2022-01-03T18:37:01Z

Hi @onlynishant, thanks! I pushed one more commit to the open pull request that should fix this NullPointerException:

c90b738

onlynishant · 2022-01-05T18:57:36Z

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 · 2022-11-30T11:40:38Z

@cconlon any update on it?

cconlon · 2023-03-27T23:11:35Z

@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.

onlynishant · 2023-03-28T03:13:31Z

@cconlon I am using a diff lib now. I will try to test the latest code when I get some time.
Thanks

cconlon self-assigned this Dec 23, 2021

onlynishant mentioned this issue Dec 29, 2021

Add support for SSLEngine.getApplicationProtocol() #84

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

no getApplicationProtocol() method in WolfSSLEngine #82

no getApplicationProtocol() method in WolfSSLEngine #82

onlynishant commented Dec 23, 2021

cconlon commented Dec 23, 2021

onlynishant commented Dec 23, 2021

cconlon commented Dec 28, 2021

onlynishant commented Dec 29, 2021

cconlon commented Dec 29, 2021 •

edited

onlynishant commented Dec 30, 2021

cconlon commented Jan 3, 2022

onlynishant commented Jan 5, 2022 •

edited

onlynishant commented Nov 30, 2022

cconlon commented Mar 27, 2023

onlynishant commented Mar 28, 2023

no getApplicationProtocol() method in WolfSSLEngine #82

no getApplicationProtocol() method in WolfSSLEngine #82

Comments

onlynishant commented Dec 23, 2021

cconlon commented Dec 23, 2021

onlynishant commented Dec 23, 2021

cconlon commented Dec 28, 2021

onlynishant commented Dec 29, 2021

cconlon commented Dec 29, 2021 • edited

onlynishant commented Dec 30, 2021

cconlon commented Jan 3, 2022

onlynishant commented Jan 5, 2022 • edited

onlynishant commented Nov 30, 2022

cconlon commented Mar 27, 2023

onlynishant commented Mar 28, 2023

cconlon commented Dec 29, 2021 •

edited

onlynishant commented Jan 5, 2022 •

edited