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):zzzwith 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.zzzfails to start.This
hostname_check_failedfailure is also unexpected,openssl s_client ... -verify_hostname hasty-crimson-flamingo.rmq3.cloudamqp.comsucceeds, probably this is related to the following.xxxwith 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 fromzzzis disabled SNI.xxxsucceeds to start.zzzalso succeeds to start!zzzrestart , the unexpected behavior didn't reproduced. Repeating 1-5 also didn't reproduce.Also, similar shovel with
server_name_indication=*.rmq3.cloudamqp.comsucceeds. 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