Client with TLS configuration not working on version v22.12.0 onwards - java.lang.IllegalArgumentException: ApplicationProtocols.Supported is not supported at this time for SslContextClientEngineFactory. Remote Info: Not Available #965
Comments
|
hi guys, did you got the chance to look at this issue? Would love to get your input on the issue which I have. |
|
@Hakky54 have you found a workaround for this ? |
|
No, I haven't. I tried even downgrading/upgrading every transitive dependency Independently but that also didn't work. Are you also facing the same issue? |
|
@Hakky54 Yes. Obviously the behavior is changed in some way, but couldn't figure out how yet. |
|
I have the feeling that it is related to the code changes. I have not received any response from the maintainers... So I have the feeling that it can only be resolved fast if I compare the differences between the two versions myself. The only downside is that I don't have much scala knowledge. What about combining the effort and doing together? |
|
I tried debugging the issue in the deeper levels of the code and I might have found the issue and the workaround for it. In the previous versions, the below code would not add However, in the recent versions, when you pick After the client is initialized successfully, netty tries to establish a connection with the target. In the previous versions, both would have Unspecified and it would pass the checks in the screenshot in your original message. But now, the client stack.params contains a The workaround I have is to bypass the checks in that class altogether by creating a custom The skipped checked can be seen here: https://github.com/twitter/finagle/blob/develop/finagle-core/src/main/scala/com/twitter/finagle/ssl/client/SslContextClientEngineFactory.scala#L26 I'm not sure about the implications of this change, but it works locally for my use case. It would be better if the maintainers could chime in and talk about the implications or suggest a workaround. |
|
Thank you for pointing out and doing this analysis! I have tried to override the Application protocols by creating a SslClientConfiguration instead of just passing a SSLContext to the client as shown here. In this way I was able to pass empty protocols and it worked, however my compiler had issues with me using scala code in java code. I was not able to fix that, so I had converted my finagle client configuration and http request service into scala and now it just work with the latest version. I don't need the So basically the code changes of the finagle maintainers didn't sort of introduce regression. If I just write it in scala it works, however if I write it in java it fails after version |
|
@Hakky54 no we are using it in a scala project. I didn't have time to try your suggestion, as it will require a significant code change in our codebase. I really would like to hear from the maintainers whether this behavior change is intended, or a side effect ? |
|
Hi @jyanJing and @tigerlily-he not quite sure whether you both are still involved and maintaining the finagle project. Some time ago you both responded on my earlier github issue here: #913 it is related to the same issue as what is still happening after version 22.12.0 Any idea how this can be properly resolved? |
Describe the bug
Https requests fails. Finagle client cannot call https server from version 22.12.0 onwards. This issue is also present on the latest version of 24.x.x I am using http1 which should work. Even when switching to http2 it still fails.
The full stacktrace is here
To Reproduce
Steps to reproduce the behavior:
git clone [email protected]:Hakky54/mutual-tls-ssl.gitor go to https://github.com/Hakky54/mutual-tls-ssl and download the repo./script/configure-two-way-authentication-by-trusting-root-ca.sh black-hole./mvnw clean installExpected behavior
I would expect the test to pass, but it fails
Environment
Finagle: 22.12.0
Java: 17 (OpenJDK)
Maven 3.6.3
OS: Mac OS X 14.5
Additional context
I used code snippet in project to configure finagle:
When I debug the code in intellij I see that the protocol is supported, however the supported switch case is throwing an exception which should not happen right. Not supported or unknown protocol should throw an exception I would assume. See here:
The text was updated successfully, but these errors were encountered: