Java client cannot connect over TLS to a 4.1.0 with pre-existing greatly restricted TLS configuration

[gs-harris]

Describe the bug

Connection from java client application to RabbitMQ node worked fine
version 3.13.7 with Erlang 26.2.5.11

After upgrading to version 4.1.0 with Erlang 27.3.3 (Zero dependency Erlang/OTP 27.3.3 )
seems to break the ability to connect using the factory.setSaslConfig(DefaultSaslConfig.EXTERNAL)

Info about my config and testing with openssl

Server CONFIG
Zero dependency Erlang/OTP 27.3.3 

RabbitMQ 4.1.0
Erlang 27.3.3

using plugin: rabbitmq_auth_mechanism_ssl ==> auth_mechanisms.1 = EXTERNA

Client CONFIG

Java Client: com.rabbitmq:amqp-client:5.24

code ... factory.setSaslConfig(DefaultSaslConfig.EXTERNAL);

Result from testing tls connection:: openssl s_client -connect myrabbitmq:5671 -tls1_2

WITH version 3.13.7 with Erlang 26.2.5.11

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: CB58DE01E6F92D4A371D3E995250E415BA411FF0FF1C3E47442D9681AA3ADEF3
    Session-ID-ctx: 
    Master-Key: <removed>
    Start Time: 1746536744
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

With version 4.1.0 with Erlang 27.3.3

no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 194 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Start Time: 1746543720
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

Reproduction steps

1. at earlier version 3.13.7 with Erlang 26.2.5.11, executed command openssl s_client -connect myrabbitmq:5671 -tls1_2
2. output shows: Secure Renegotiation IS supported, client app also connects at this level
3. upgrade to 4.1.0 with Erlang 27.3.3, executed command openssl s_client -connect myrabbitmq:5671 -tls1_2
4. output shows: Secure Renegotiation IS NOT supported, handshake phase doesn't try to present cert from host

Expected behavior

we expect the handshake to exchange certs and negotiate the exchange/set up of the tls handshake

Additional context

Java Client reports exception
javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake

[lukebakken]

Hello, thanks for using RabbitMQ.

In general, Team RabbitMQ does not diagnose TLS issues for the community (link).

In this case, you haven't provided enough information for someone to assist you. Ideally, you would at least provide your full RabbitMQ configuration file.

Since I have a few minutes, I will try to reproduce this issue using tls-gen generated certs and openssl.

[gs-harris]

what else would you need? I posted my conf file

[gs-harris]

thanks for helping!

[lukebakken]

I've put together the following repo that demonstrates that RabbitMQ 4 works just fine using TLS 1.2 and openssl s_client:

https://github.com/lukebakken/rabbitmq-server-13864

More than likely, your issue stems from the fact that you are limiting ciphers to just one. Don't do that. Comment out ssl_options.ciphers.1 and I'm sure your environment will work fine.

It doesn't matter that this used to work using an older version of Erlang, there must have been something that changed in Erlang 27, or the underlying OpenSSL library, because that's what the Erlang VM uses to do cryptographic computations.

[gs-harris]

Here is my rabbitmq.conf

listeners.ssl.default = 5671
listeners.tcp.default = 5672
ssl_options.cacertfile = /etc/certs/exp_all_cacerts.pem
ssl_options.certfile   = /etc/certs/<removed>.pem
ssl_options.keyfile    = /etc/certs/<removed>.pem
ssl_options.password   = <removed>
ssl_options.versions.1 = tlsv1.2
ssl_options.depth = 3

log.default.level = debug
auth_mechanisms.1 = EXTERNAL

ssl_options.verify     = verify_peer
ssl_options.fail_if_no_peer_cert = true
ssl_options.honor_cipher_order = true
ssl_options.honor_ecc_order    = true

ssl_options.ciphers.1 = ECDHE-RSA-AES256-GCM-SHA384

management.tcp.port       = 15672
management.tcp.ip   = 0.0.0.0

management.ssl.port       = 15671
management.ssl.cacertfile = /etc/certs/<removed>.pem
management.ssl.certfile   = /etc/certs/<removed>.pem
management.ssl.keyfile    = /etc/certs/<removed>.pem
management.ssl.password   = <removed>

management.ssl.honor_cipher_order   = true
management.ssl.honor_ecc_order      = true
management.ssl.client_renegotiation = false
management.ssl.secure_renegotiate   = true

management.ssl.versions.1 = tlsv1.2

## Usually RabbitMQ nodes do not perform peer verification of HTTP API clients
## but it can be enabled if needed. Clients then will have to be configured with
## a certificate and private key pair.
##
## See ./ssl#peer-verification for details.
# management.ssl.verify = verify_peer
# management.ssl.fail_if_no_peer_cert = true

[lukebakken]

As a suggestion, review how I edited the original discussion and your comments to fix the formatting. It was very difficult to read at first.

[gs-harris]

Thank you for the help - I took your certs and tried them on my server - openssl shows handshake/connection works! So it must be my a certificate problem on my end. I was in a hurry to get my bug posted, thus the sloppiness.

[michaelklishin]

@gs-harris it likely comes down to the key usage extensions that your certificate has (or rather does not have).

[michaelklishin]

@gs-harris our team does not troubleshoot TLS for non-paying users. See the Troubleshooting TLS guide that explains how to do narrow problems down efficiently.

In addition, your set has a lot of restrictions, namely one lonely cipher suite that is allowed.
Remove those restrictions and start reintroducing them one by one, adding the cipher suite one last.

Cipher suite overlap between the client and the server is critically important for TLS to function. This is primarily important for those adopting TLS 1.3 exclusively but is an important factor generally, because a TLS handshake cannot possibly succeed if the two sides of the connection do not have at least one cipher suite in common.

When one side is restricted to just one cipher suite, the risk of such incompatibilities is the greatest it can be.

If @lukebakken wants to continue helping out, I'm not going to object.

[michaelklishin]

A 4.1.0 node running on Erlang 27.3.3 (without any TLS build-time tweaks) on OpenSSL 3.5.0 lists the following cipher suites as supported and enabled:

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-CCM
ECDHE-ECDSA-AES256-CCM8
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-CCM
ECDHE-ECDSA-AES128-CCM8
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
ECDH-RSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
ECDH-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA

Our TLS guide has an example setup that passes a widely used test suite both with TLS 1.2 with a restricted set of suites (not down to a single suite) and TLS 1.3 (that has no suites in common with 1.2 by design, as explained in the docs).

I could not find any documented cipher suites-related changes in Erlang/OTP 27.x.

Our team (in fact, @lukebakken) has previously reported a number of issues to the Erlang maintainers specifically in this area, and specifically when interacting with Java clients, e.g. this one (has to do with ECC suites) erlang/otp#6435 but the last time that happened was probably a good year ago.

In any case, the recommendation to remove all restrictions and start reintroducing them, still stands.
You can choose to go straight to TLS 1.3 (whose setup on the RabbitMQ end will be simpler and documented). Using TLS 1.2 with a single whitelisted cipher suite seems like an inferior idea than just using TLS 1.3 only to me.

[michaelklishin]

This guide on choosing an optimal cipher suite combination from Mozilla can also be useful.

As is testssl.sh, which is what our team uses to produce the cipher suite sets used in the docs.

[gs-harris]

Thank you for the added info - you guys have helped me a lot!

[michaelklishin]

Sorry about the noise, I see the comment that it could be the certificate above.