Unexpected dependency between shovels #4006
Replies: 4 comments
-
Individual Shovels are entirely independent. What they do share is the underlying Erlang client, TLS library and URI/credential obfuscation library. I don't think our team has the cycles to investigate issues like this. This is open source software, so you are welcome to do it if this makes any practical difference. |
Beta Was this translation helpful? Give feedback.
-
IIRC months ago ( The log contains virtual host access failures and one Shovel Shovel is a small plugin with only a couple of modules responsible for its state machine. Searching the repo or GitHub for some |
Beta Was this translation helpful? Give feedback.
-
Maybe this is related to unexpected https://github.com/erlang/otp/blob/master/lib/ssl/src/ssl_certificate.erl
but in https://github.com/rabbitmq/rabbitmq-server/blob/master/deps/amqp_client/src/amqp_ssl.erl
@michaelklishin are you sure UserState is hostname and not the record with |
Beta Was this translation helpful? Give feedback.
-
@michaelklishin I'm not a SSL expert, but SNI and hostname check are similar, but different checks. E.g.
Imho, it is unexpected, that setting |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We use RabbitMQ 3.8.16, Erlang 24.1.7 on the machine the logs from, 3.8.16 + 24.0.4 on CloudAMQP.
I tried to make our shovels work with
verify=verify_peer
, and I made the following testing actions (from browser):zzz
with both URIsamqps://varadmrabbit-d4cc9fdc:[redacted]@hasty-crimson-flamingo.rmq3.cloudamqp.com:5671/d4cc9fdc-2e48-4135-9863-87c9e9859351?cacertfile=C%3A%5CWorkingShare%5Crmqcluster_service%5Ccacert.pem&verify=verify_peer&heartbeat=900&server_name_indication=hasty-crimson-flamingo.rmq3.cloudamqp.com
.zzz
fails to start.This
hostname_check_failed
failure is also unexpected,openssl s_client ... -verify_hostname hasty-crimson-flamingo.rmq3.cloudamqp.com
succeeds, probably this is related to the following.xxx
with both URIsamqps://varadmrabbit-d4cc9fdc:[redacted]@hasty-crimson-flamingo.rmq3.cloudamqp.com:5671/d4cc9fdc-2e48-4135-9863-87c9e9859351?cacertfile=C%3A%5CWorkingShare%5Crmqcluster_service%5Ccacert.pem&verify=verify_peer&heartbeat=900&server_name_indication=disable
. The only difference fromzzz
is disabled SNI.xxx
succeeds to start.zzz
also succeeds to start!zzz
restart , the unexpected behavior didn't reproduced. Repeating 1-5 also didn't reproduce.Also, similar shovel with
server_name_indication=*.rmq3.cloudamqp.com
succeeds. It looks like in hostname matching process the wildcard pattern is used as a hostname, and vice versa.Beta Was this translation helpful? Give feedback.
All reactions