You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Andrew North <An...@campbellsci.co.uk> on 2024/06/10 14:56:50 UTC
Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Hi,
I've been using qpid-proton 0.39 C/C++, I have been testing with an extended version of the samples.
I'm sending secure messages and authenticating connections with SSL certificates I have generated manually connecting to a RabbitMQ broker.
I've validated the certificates and connections using openssl on the terminal and using qpid-proton samples.
I'm using both OpenSSL and CyrusSASL dependencies.
I have a "bug" perhaps in configuration of my client, where when I enable the dependency for cyrus-sasl.c over the cyrus-stub.c, I am no longer
able to authenticate using "PLAIN", and my default connection is forcing "EXTERNAL" SASL mechanism even if explicitly set it to false in connection options.
Below are some snippets from my tests:
This is my dummy_client
"""
class dummy_client : public proton::messaging_handler {
public:
void on_container_start(proton::container& c) override {
proton::connection_options client_opts;
client_opts.handler(*this);
if(this->_use_auth){
client_opts.user(this->_user);
client_opts.password(this->_password);
}
client_opts.sasl_enabled(false);
if(this->_use_ssl) {
std::string client_cert = this->_cert_dir + "client-cert.pem";
std::string client_key = this->_cert_dir + "client-key.pem";
std::string client_pw = "password";
std::string client_ca = this->_cert_dir + "ca-cert.pem";
proton::ssl_certificate ssl_cert(client_cert, client_key, client_pw);
proton::ssl_client_options ssl_client_opts(ssl_cert, client_ca, proton::ssl::VERIFY_PEER);
if(this->_use_sasl){
client_opts.sasl_enabled(true);
client_opts.ssl_client_options(ssl_client_opts).sasl_allowed_mechs(this->_sasl_mech);
} else {
client_opts.ssl_client_options(ssl_client_opts);
}
}
if(this->_sasl_mech == "INSECURE") {
client_opts.sasl_allow_insecure_mechs(true);
}
proton::sender s = c.open_sender(this->_url + "/" + this->_address, client_opts);
}
void on_sendable(proton::sender& s) override {
proton::message m;
m.body("Hello World!");
s.send(m);
s.close();
}
}
"""
Simplified test logic:
"""
{
dummy_client client;
proton::container container(client);
local_thread = std::jthread([&](){ container.run(); });
std::this_thread::sleep_for(std::chrono::microseconds(wait_sec*1000000));
if (local_thread.joinable()) {
container.stop();
local_thread.join();
}
}
"""
I have multiple tests with the following configurations:
* _url=target_ip:{5672,5671}
* _address=test_NN
* _use_auth={true,false}
* _user={guest,new_user}
* _password={guest,password}
* _use_ssl={true,false}
* _use_sasl={true,false}
* _sasl_mech={"INSECURE","PLAIN","EXTERNAL"}
I have run the tests in 4 different scenarios, below are the results:
* Using one of these two dependencies {cyrus_stub.c, cyrus_sasl.c}
* RabbitMQ - SASL_SSL authentication {on, off}
port
use_auth
user
password
use_ssl
use_sasl
sasl_mech
result w/plugin
w/cyrus_stub.c
result wo/plugin
w/cyrus_stub.c
result w/plugin
w/cyrus_sasl.c
result wo/plugin
w/cyrus_sasl.c
5672
-
-
-
-
-
-
PASS
PASS
PASS
PASS
5672
X
guest
guest
-
-
-
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5672
X
new_user
password
-
-
-
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
-
-
-
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
new_user
password
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
-
-
-
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
new_user
password
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
X
"PLAIN"
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
-
-
-
X
X
"PLAIN"
FAIL - auth mech=none
FAIL - auth mech=none
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
X
guest
guest
X
X
"EXTERNAL"
PASS
FAIL - auth mech=none
PASS
FAIL - auth
5671
-
-
-
X
X
"EXTERNAL"
PASS
FAIL - auth mech=none
PASS
FAIL - auth
Summary of results using cyrus_stub.c:
* Can always connect and send unsecure messages with no configuration set (assuming this means "ANONYMOUS")
* RabbitMQ NOT Using SASL_SSL:
* Can connect and send unsecure messages via port 5672, even with user credentials
* Can connect and send secure messages via port 5671, even with user credentials
* Can authenticate using "PLAIN" SASL
* Fails to authenticate using "EXTERNAL" assumed to be SASL_SSL authentication
* RabbitMQ Using SASL_SSL:
* Can connect and send unsecure messages via port 5672, even with user credentials
* Can't connect and send secure messages via port 5671
* Can authenticate using "PLAIN" SASL, and send secure messages via port 5671
* Can authenticate using "EXTERNAL", assumed to be SASL_SSL authentication and send secure messages via port 5671
Summary of results using cyrus_sasl.c:
* Can always connect and send unsecure messages with no configuration set (assuming this means "ANONYMOUS")
* RabbitMQ NOT Using SASL_SSL:
* Can't connect or send unsecure/secure message via ports 5672/5671, with or without user credentials
* Can't authenticate using "PLAIN" SASL
* Fails to authenticate using "EXTERNAL" assumed to be SASL_SSL authentication
* Always assumes SASL is using "EXTERNAL" mech when sasl is explicitly disabled using "client_opts.sasl_enabled(false);"
* RabbitMQ Using SASL_SSL:
* Can't connect and send unsecure messages via port 5672, even with user credentials
* Can connect and send secure messages via port 5671 - but transport assumes use of "EXTERNAL" mech.
* Can't authenticate using "PLAIN" SASL
* Can authenticate using "EXTERNAL", assumed to be SASL_SSL authentication and send secure messages via port 5671
Let me know if you can see the formatted results as a table, I also have the following questions:
* Are we forced to use SASL authentication if we use dependency cyrus_sasl.c as opposed to cyrus_stub.c?
* Is there a configuration I am doing by mistake?
* Can a client be configured to open a container with "PLAIN" authentication, and a second container be opened with "EXTERNAL" or "NONE" depending on other log
If you have any suggestions or further clarity regarding above, that would be great thanks. I will continue to experiment with what I have.
Kind Regards,
Andrew
Andrew North
SOFTWARE ENGINEER
Re: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Posted by Andrew Stitcher <as...@redhat.com>.
I'm not entirely clear from your description how you've been configuring
SASL. Usually the CMake configure phase will choose the SASL configuration
depending on the libraries it detects on the system you are running on. If
you only want to use PLAIN and EXTERNAL (over TLS presumably) then you
don't need Cyrus SASL and the default SASL provider will be sufficient for
your needs.
If you are using Cyrus SASL on some Linux distributions you may need to
have the package containing the PLAIN mechanism installed too otherwise
that mechanism will not be available for Cyrus SASL to use.
Hope that helps.
Andrew
On Tue, Jun 11, 2024 at 5:37 AM Andrew North <An...@campbellsci.co.uk>
wrote:
> Just to update on this, I have included both sources (cyrus_sasl.c and
> cyrus_stub.c) and it works as expected.
>
>
>
> Cheers
>
>
>
>
> *From:* Andrew North
> *Sent:* Monday, June 10, 2024 3:57 PM
> *To:* users@qpid.apache.org
> *Subject:* Is SASL_SSL enforced with qpid-proton when CyrusSASL
> dependency is used
>
>
>
> Hi,
>
>
>
> I’ve been using qpid-proton 0.39 C/C++, I have been testing with an
> extended version of the samples.
>
> I’m sending secure messages and authenticating connections with SSL
> certificates I have generated manually connecting to a RabbitMQ broker.
>
> I’ve validated the certificates and connections using openssl on the
> terminal and using qpid-proton samples.
>
> I’m using both OpenSSL and CyrusSASL dependencies.
>
>
>
> I have a “bug” perhaps in configuration of my client, where when I enable
> the dependency for cyrus-sasl.c over the cyrus-stub.c, I am no longer
> able to authenticate using “PLAIN”, and my default connection is forcing
> “EXTERNAL” SASL mechanism even if explicitly set it to false in connection
> options.
>
>
>
> Below are some snippets from my tests:
>
> This is my dummy_client
>
> “””
>
> class dummy_client : public proton::messaging_handler {
>
> public:
>
> void on_container_start(proton::container& c) override {
>
> proton::connection_options client_opts;
>
> client_opts.handler(*this);
>
>
>
> if(this->_use_auth){
>
> client_opts.user(this->_user);
>
> client_opts.password(this->_password);
>
> }
>
>
>
> client_opts.sasl_enabled(false);
>
>
>
> if(this->_use_ssl) {
>
> std::string client_cert = this->_cert_dir + "client-cert.pem";
>
> std::string client_key = this->_cert_dir + "client-key.pem";
>
> std::string client_pw = "password";
>
> std::string client_ca = this->_cert_dir + "ca-cert.pem";
>
> proton::ssl_certificate ssl_cert(client_cert, client_key,
> client_pw);
>
> proton::ssl_client_options ssl_client_opts(ssl_cert, client_ca,
> proton::ssl::VERIFY_PEER);
>
> if(this->_use_sasl){
>
> client_opts.sasl_enabled(true);
>
>
> client_opts.ssl_client_options(ssl_client_opts).sasl_allowed_mechs(this->_sasl_mech);
>
> } else {
>
> client_opts.ssl_client_options(ssl_client_opts);
>
> }
>
> }
>
>
>
> if(this->_sasl_mech == "INSECURE") {
>
> client_opts.sasl_allow_insecure_mechs(true);
>
> }
>
>
>
> proton::sender s = c.open_sender(this->_url + "/" + this->_address,
> client_opts);
>
> }
>
>
>
> void on_sendable(proton::sender& s) override {
>
> proton::message m;
>
> m.body("Hello World!");
>
> s.send(m);
>
> s.close();
>
> }
>
> }
>
> “””
>
>
>
> Simplified test logic:
>
> “””
>
> {
>
> dummy_client client;
>
> proton::container container(client);
>
> local_thread = std::jthread([&](){ container.run(); });
>
> std::this_thread::sleep_for(std::chrono::microseconds(wait_sec*1000000));
>
> if (local_thread.joinable()) {
>
> container.stop();
>
> local_thread.join();
>
> }
>
> }
>
> “””
>
>
>
> I have multiple tests with the following configurations:
>
> - _url=target_ip:{5672,5671}
> - _*address=test*_NN
> - _*use*_auth={true,false}
> - _*user={guest,new*_user}
> - _password={guest,password}
> - _*use*_ssl={true,false}
> - _*use_sasl={true,false}*
> - *_sasl_mech={“INSECURE”,”PLAIN”,”EXTERNAL”}*
>
>
>
> I have run the tests in 4 different scenarios, below are the results:
>
> - Using one of these two dependencies {cyrus_stub.c, cyrus_sasl.c}
> - RabbitMQ – SASL_SSL authentication {on, off}
>
>
>
> port
>
> use_auth
>
> user
>
> password
>
> use_ssl
>
> use_sasl
>
> sasl_mech
>
> result w/plugin
> w/cyrus_stub.c
>
> result wo/plugin
> w/cyrus_stub.c
>
> result w/plugin
>
> w/cyrus_sasl.c
>
> result wo/plugin
> w/cyrus_sasl.c
>
> 5672
>
> -
>
> -
>
> -
>
> -
>
> -
>
> -
>
> PASS
>
> PASS
>
> PASS
>
> PASS
>
> 5672
>
> X
>
> guest
>
> guest
>
> -
>
> -
>
> -
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> FAIL - SASL error (-4)
>
> 5672
>
> X
>
> new_user
>
> password
>
> -
>
> -
>
> -
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> FAIL - SASL error (-4)
>
> 5671
>
> -
>
> -
>
> -
>
> X
>
> -
>
> "INSECURE"
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> guest
>
> guest
>
> X
>
> -
>
> "INSECURE"
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> new_user
>
> password
>
> X
>
> -
>
> "INSECURE"
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> -
>
> -
>
> -
>
> X
>
> -
>
> -
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> guest
>
> guest
>
> X
>
> -
>
> -
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> new_user
>
> password
>
> X
>
> -
>
> -
>
> ERROR
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> guest
>
> guest
>
> X
>
> X
>
> "PLAIN"
>
> PASS
>
> PASS
>
> FAIL - SASL error (-4)
>
> FAIL - SASL error (-4)
>
> 5671
>
> -
>
> -
>
> -
>
> X
>
> X
>
> "PLAIN"
>
> FAIL - auth mech=none
>
> FAIL - auth mech=none
>
> FAIL - SASL error (-4)
>
> FAIL - SASL error (-4)
>
> 5671
>
> X
>
> guest
>
> guest
>
> X
>
> X
>
> "EXTERNAL"
>
> PASS
>
> FAIL - auth mech=none
>
> PASS
>
> FAIL - auth
>
> 5671
>
> -
>
> -
>
> -
>
> X
>
> X
>
> "EXTERNAL"
>
> PASS
>
> FAIL - auth mech=none
>
> PASS
>
> FAIL - auth
>
>
>
> Summary of results using cyrus_stub.c:
>
> - Can always connect and send unsecure messages with no configuration
> set (assuming this means “ANONYMOUS”)
> - RabbitMQ NOT Using SASL_SSL:
> - Can connect and send unsecure messages via port 5672, even with
> user credentials
> - Can connect and send secure messages via port 5671, even with
> user credentials
> - Can authenticate using “PLAIN” SASL
> - Fails to authenticate using “EXTERNAL” assumed to be SASL_SSL
> authentication
> - RabbitMQ Using SASL_SSL:
> - Can connect and send unsecure messages via port 5672, even with
> user credentials
> - Can’t connect and send secure messages via port 5671
> - Can authenticate using “PLAIN” SASL, and send secure messages via
> port 5671
> - Can authenticate using “EXTERNAL”, assumed to be SASL_SSL
> authentication and send secure messages via port 5671
>
>
>
> Summary of results using cyrus_sasl.c:
>
> - Can always connect and send unsecure messages with no configuration
> set (assuming this means “ANONYMOUS”)
> - RabbitMQ NOT Using SASL_SSL:
> - Can’t connect or send unsecure/secure message via ports
> 5672/5671, with or without user credentials
> - Can’t authenticate using “PLAIN” SASL
> - Fails to authenticate using “EXTERNAL” assumed to be SASL_SSL
> authentication
> - Always assumes SASL is using “EXTERNAL” mech when sasl is
> explicitly disabled using “client_opts.sasl_enabled(false);”
> - RabbitMQ Using SASL_SSL:
> - Can’t connect and send unsecure messages via port 5672, even with
> user credentials
> - Can connect and send secure messages via port 5671 – but
> transport assumes use of “EXTERNAL” mech.
> - Can’t authenticate using “PLAIN” SASL
> - Can authenticate using “EXTERNAL”, assumed to be SASL_SSL
> authentication and send secure messages via port 5671
>
>
>
> Let me know if you can see the formatted results as a table, I also have
> the following questions:
>
> - Are we forced to use SASL authentication if we use dependency
> cyrus_sasl.c as opposed to cyrus_stub.c?
> - Is there a configuration I am doing by mistake?
> - Can a client be configured to open a container with “PLAIN”
> authentication, and a second container be opened with “EXTERNAL” or “NONE”
> depending on other log
>
>
>
> If you have any suggestions or further clarity regarding above, that would
> be great thanks. I will continue to experiment with what I have.
>
>
>
> Kind Regards,
>
> Andrew
>
Re: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Posted by Andrew Stitcher <as...@redhat.com>.
On Wed, Jun 12, 2024 at 9:02 AM Andrew North <an...@campbellsci.co.uk>
wrote:
> Just a curiosity, are we able to build/use CyrusSASL on windows?
>
In theory I think you could use Cyrus SASL built with vcpkg, but I think
someone tried that and there were some specific issues with building the
proton cyrus sasl code because it assumes that it's only built on Unix and
so uses pthreads APIs.If you only need PLAIN and EXTERNAL at the client end
there is no advantage to using Cyrus SASL anyway.
> Also, you mentioned some SASL methods that are out of the box, do you know
> if SASL_SSL comes under EXTERNAL?
>
Could you explain what SASL_SSL is? I'm not aware of a SASL mechanism with
that name, but both PLAIN and EXTERNAL work well with TLS (SSL).
As I said previously, PLAIN, EXTERNAL (and ANONYMOUS too) are supported
using the default SASL implementation on Proton with no need for Cyrus SASL.
Andrew
RE: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Posted by Andrew North <an...@campbellsci.co.uk>.
Thanks so much for the reply, yes that is exactly the information I was looking for.
I'm able to configure the client for PLAIN and EXTERNAL, using TLS now yes.
Just a curiosity, are we able to build/use CyrusSASL on windows?
Also, you mentioned some SASL methods that are out of the box, do you know if SASL_SSL comes under EXTERNAL?
Many thanks,[cid:image002.png@01DABCA6.3CF6A100]
Andrew North
SOFTWARE ENGINEER
RE: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Posted by Andrew North <An...@campbellsci.co.uk>.
Just to update on this, I have included both sources (cyrus_sasl.c and cyrus_stub.c) and it works as expected.
Cheers
Andrew North
SOFTWARE ENGINEER
From: Andrew North
Sent: Monday, June 10, 2024 3:57 PM
To: users@qpid.apache.org
Subject: Is SASL_SSL enforced with qpid-proton when CyrusSASL dependency is used
Hi,
I've been using qpid-proton 0.39 C/C++, I have been testing with an extended version of the samples.
I'm sending secure messages and authenticating connections with SSL certificates I have generated manually connecting to a RabbitMQ broker.
I've validated the certificates and connections using openssl on the terminal and using qpid-proton samples.
I'm using both OpenSSL and CyrusSASL dependencies.
I have a "bug" perhaps in configuration of my client, where when I enable the dependency for cyrus-sasl.c over the cyrus-stub.c, I am no longer
able to authenticate using "PLAIN", and my default connection is forcing "EXTERNAL" SASL mechanism even if explicitly set it to false in connection options.
Below are some snippets from my tests:
This is my dummy_client
"""
class dummy_client : public proton::messaging_handler {
public:
void on_container_start(proton::container& c) override {
proton::connection_options client_opts;
client_opts.handler(*this);
if(this->_use_auth){
client_opts.user(this->_user);
client_opts.password(this->_password);
}
client_opts.sasl_enabled(false);
if(this->_use_ssl) {
std::string client_cert = this->_cert_dir + "client-cert.pem";
std::string client_key = this->_cert_dir + "client-key.pem";
std::string client_pw = "password";
std::string client_ca = this->_cert_dir + "ca-cert.pem";
proton::ssl_certificate ssl_cert(client_cert, client_key, client_pw);
proton::ssl_client_options ssl_client_opts(ssl_cert, client_ca, proton::ssl::VERIFY_PEER);
if(this->_use_sasl){
client_opts.sasl_enabled(true);
client_opts.ssl_client_options(ssl_client_opts).sasl_allowed_mechs(this->_sasl_mech);
} else {
client_opts.ssl_client_options(ssl_client_opts);
}
}
if(this->_sasl_mech == "INSECURE") {
client_opts.sasl_allow_insecure_mechs(true);
}
proton::sender s = c.open_sender(this->_url + "/" + this->_address, client_opts);
}
void on_sendable(proton::sender& s) override {
proton::message m;
m.body("Hello World!");
s.send(m);
s.close();
}
}
"""
Simplified test logic:
"""
{
dummy_client client;
proton::container container(client);
local_thread = std::jthread([&](){ container.run(); });
std::this_thread::sleep_for(std::chrono::microseconds(wait_sec*1000000));
if (local_thread.joinable()) {
container.stop();
local_thread.join();
}
}
"""
I have multiple tests with the following configurations:
* _url=target_ip:{5672,5671}
* _address=test_NN
* _use_auth={true,false}
* _user={guest,new_user}
* _password={guest,password}
* _use_ssl={true,false}
* _use_sasl={true,false}
* _sasl_mech={"INSECURE","PLAIN","EXTERNAL"}
I have run the tests in 4 different scenarios, below are the results:
* Using one of these two dependencies {cyrus_stub.c, cyrus_sasl.c}
* RabbitMQ - SASL_SSL authentication {on, off}
port
use_auth
user
password
use_ssl
use_sasl
sasl_mech
result w/plugin
w/cyrus_stub.c
result wo/plugin
w/cyrus_stub.c
result w/plugin
w/cyrus_sasl.c
result wo/plugin
w/cyrus_sasl.c
5672
-
-
-
-
-
-
PASS
PASS
PASS
PASS
5672
X
guest
guest
-
-
-
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5672
X
new_user
password
-
-
-
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
-
-
-
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
new_user
password
X
-
"INSECURE"
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
-
-
-
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
new_user
password
X
-
-
ERROR
PASS
PASS
FAIL - SASL error (-4)
5671
X
guest
guest
X
X
"PLAIN"
PASS
PASS
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
-
-
-
X
X
"PLAIN"
FAIL - auth mech=none
FAIL - auth mech=none
FAIL - SASL error (-4)
FAIL - SASL error (-4)
5671
X
guest
guest
X
X
"EXTERNAL"
PASS
FAIL - auth mech=none
PASS
FAIL - auth
5671
-
-
-
X
X
"EXTERNAL"
PASS
FAIL - auth mech=none
PASS
FAIL - auth
Summary of results using cyrus_stub.c:
* Can always connect and send unsecure messages with no configuration set (assuming this means "ANONYMOUS")
* RabbitMQ NOT Using SASL_SSL:
* Can connect and send unsecure messages via port 5672, even with user credentials
* Can connect and send secure messages via port 5671, even with user credentials
* Can authenticate using "PLAIN" SASL
* Fails to authenticate using "EXTERNAL" assumed to be SASL_SSL authentication
* RabbitMQ Using SASL_SSL:
* Can connect and send unsecure messages via port 5672, even with user credentials
* Can't connect and send secure messages via port 5671
* Can authenticate using "PLAIN" SASL, and send secure messages via port 5671
* Can authenticate using "EXTERNAL", assumed to be SASL_SSL authentication and send secure messages via port 5671
Summary of results using cyrus_sasl.c:
* Can always connect and send unsecure messages with no configuration set (assuming this means "ANONYMOUS")
* RabbitMQ NOT Using SASL_SSL:
* Can't connect or send unsecure/secure message via ports 5672/5671, with or without user credentials
* Can't authenticate using "PLAIN" SASL
* Fails to authenticate using "EXTERNAL" assumed to be SASL_SSL authentication
* Always assumes SASL is using "EXTERNAL" mech when sasl is explicitly disabled using "client_opts.sasl_enabled(false);"
* RabbitMQ Using SASL_SSL:
* Can't connect and send unsecure messages via port 5672, even with user credentials
* Can connect and send secure messages via port 5671 - but transport assumes use of "EXTERNAL" mech.
* Can't authenticate using "PLAIN" SASL
* Can authenticate using "EXTERNAL", assumed to be SASL_SSL authentication and send secure messages via port 5671
Let me know if you can see the formatted results as a table, I also have the following questions:
* Are we forced to use SASL authentication if we use dependency cyrus_sasl.c as opposed to cyrus_stub.c?
* Is there a configuration I am doing by mistake?
* Can a client be configured to open a container with "PLAIN" authentication, and a second container be opened with "EXTERNAL" or "NONE" depending on other log
If you have any suggestions or further clarity regarding above, that would be great thanks. I will continue to experiment with what I have.
Kind Regards,
Andrew