[Bug]: Fluvio client tls handshake when using latest openssl-src

[digikata]

What happened A customer updated their cargo dependencies and connections to a tls fluvio cluster started to fail.

The client returns error: connect error Socket io failed to connect: the handshake failed: Connection reset by peer (os error 54), can't connect to router.infinyon.cloud:9003

Expected behavior The fluvio client should connect to fluvio tls enabled cluster successfully

Describe the setup A rust app on a Fluvio client on MacOs where openssl-src crate is used

[digikata]

Reproduced

Building fluvio client 0.26.2 with openssl-src v300.5.0+3.5.0 released on Apr 8, 2025 causes this error. connect error Socket io failed to connect: the handshake failed: Connection reset by peer (os error 54), can't connect to router.infinyon.cloud:9003

Ref: https://github.com/alexcrichton/openssl-src-rs/releases/tag/300.5.0%2B3.5.0

You can check which version of openssl-src is being used with:

cargo tree | grep openssl-src

Workaround

Use the previous release of openssl-src.

Add the following line to Cargo.toml:

# openssl-src 300.5.0+3.5.0 associated w/ tls handshake errors
openssl-src = "=300.4.2+3.4.1"

Run cargo update

Clean: cargo clean The clean is required because intermediate openssl library files are not automatically rebuilt with a cargo version change of openssl-src

Rebuild: cargo build

[sehz]

We need to use tls version for cd-dev workflow which only tested with non TLS.

[github-actions[bot]]

Stale issue message

[fraidev]

That was probably a problem in Infinyon Cloud actually, we're using a limit size buffer to get the Hello Client msg, I found it replacing openssl by rustls.