Created attachment 821429 [details] qpidd broker log Description of problem: While testing the fix for bug 966636 in MRG/M 2.3.6 build, I came across the following problem. If EXTERNAL sasl mechanism is used for client authentication, the broker is supposed to extract the CN from the client's ssl certificate and use it as an 'authId' for sasl authentication. In case that the client certificate is malformed (it has a subject of the form "C=FR,O=SUNGARD,OU="CLEARVISION CN=GLKXV_GLKXVALBBDBGEN1""), the broker with the fix for bug 966636 extracts the CN as an empty string, and rejects the client connection, which is a valid behavior - the client with malformed certificate should get rejected. The problem is that the broker reports in this case that it does not support EXTERNAL mechanism at all, which is clearly incorrect and very misleading. Version-Release number of selected component (if applicable): qpid-cpp-0.18-18 How reproducible: 100% Steps to Reproduce: 1. Configure broker to use ssl and EXTERNAL sasl mechanism. 2. Add a malformed client certificate to the database. 3. Try to connect to the broker using the "bad" client certificate. Actual results: The connection gets rejected, and the broker reports that it does not support EXTERNAL sasl mechanism. Expected results: The connection gets rejected, and the broker reports the reason correctly - no CN was extracted from the client certificate. Additional info: I have two client certificates in the database on my testing machine: client and client2. The first one is perfectly valid, the second one has the before-mentioned incorrect Subject field. Here are the results of running a client using these two certificates: [root@lzhaldyb-rhel64x ~]# export QPID_SSL_CERT_NAME=client [root@lzhaldyb-rhel64x ~]# env | grep SSL QPID_SSL_USE_EXPORT_POLICY=yes QPID_SSL_CERT_DB=/var/lib/qpidd/qpid_nss_db QPID_SSL_CERT_NAME=client QPID_SSL_CERT_PASSWORD_FILE=/var/lib/qpidd/qpid_nss_db/ssl_pw_file [root@lzhaldyb-rhel64x ~]# qpid-perftest -p 5671 -b lzhaldyb-rhel64x --log-enable=info+ --count 1 -s -P ssl --mechanism EXTERNAL 2013-11-08 07:21:37 [Client] info Connection [57576 10.34.33.207:5671] connected to ssl:lzhaldyb-rhel64x:5671 2013-11-08 07:21:37 [Client] info Connection [57577 10.34.33.207:5671] connected to ssl:lzhaldyb-rhel64x:5671 2013-11-08 07:21:37 [Client] info Connection [57578 10.34.33.207:5671] connected to ssl:lzhaldyb-rhel64x:5671 2013-11-08 07:21:37 [Client] info Connection [57579 10.34.33.207:5671] connected to ssl:lzhaldyb-rhel64x:5671 1239.33 23.1634 710.274 0.693627 [root@lzhaldyb-rhel64x ~]# echo $? 0 [root@lzhaldyb-rhel64x ~]# export QPID_SSL_CERT_NAME=client2 [root@lzhaldyb-rhel64x ~]# qpid-perftest -p 5671 -b lzhaldyb-rhel64x --log-enable=info+ --count 1 -s -P ssl --mechanism EXTERNAL 2013-11-08 07:21:59 [Client] warning Closing connection due to Desired mechanism(s) not valid: EXTERNAL (supported: PLAIN ANONYMOUS DIGEST-MD5) (qpid/client/ConnectionHandler.cpp:258) Desired mechanism(s) not valid: EXTERNAL (supported: PLAIN ANONYMOUS DIGEST-MD5) (qpid/client/ConnectionHandler.cpp:258) [root@lzhaldyb-rhel64x ~]# echo $? 1 I've also attached the qpidd.log for the case of malformed certificate being used by the client.
(In reply to Leonid Zhaldybin from comment #0) > If EXTERNAL sasl mechanism is used for client > authentication, the broker is supposed to extract the CN from the client's > ssl certificate and use it as an 'authId' for sasl authentication. In case > that the client certificate is malformed (it has a subject of the form > "C=FR,O=SUNGARD,OU="CLEARVISION CN=GLKXV_GLKXVALBBDBGEN1""), the broker with > the fix for bug 966636 extracts the CN as an empty string, and rejects the > client connection, which is a valid behavior - the client with malformed > certificate should get rejected. The problem is that the broker reports in > this case that it does not support EXTERNAL mechanism at all, which is > clearly incorrect and very misleading. While I accept it is misleading and we can look at making it less so, I'm not sure I agree that it is incorrect. Whether the EXTERNAL mechanism is available for use on a connection is determined by whether the underlying transport provides sufficient authentication to be used. In the case where the broker feels it has been unable to establish the identity of that underlying transport, even though the certificate has been validated, then I would argue it should not offer EXTERNAL. The mechanism for determining identity may be a little too fragile of course and that is another area that could be improved.
Created attachment 907100 [details] Bash script which creates ssl database with malformed client certificate in it.
Created attachment 907104 [details] Bash script which creates ssl database with malformed client certificate in it (updated for qpid-0.22 compatibility)..
Made a change to SaslAuthenticator.cpp (see patch.txt attached). The errors are changed to the following: Broker log: ... 2014-06-12 14:17:16 [System] debug Exception constructed: SASL error: unable to set external auth: authid is empty (/root/iboverma/qpid-0.22-mrg/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp:305) 2014-06-12 14:17:16 [System] error internal-error: SASL error: unable to set external auth: authid is empty (/root/iboverma/qpid-0.22-mrg/qpid/cpp/src/qpid/broker/SaslAuthenticator.cpp:305) ... Client: 2014-06-12 14:54:20 [Client] info Failed to connect to mrg24.lab.bos.redhat.com:5671: Connection [10.16.44.229:50520 mrg24.lab.bos.redhat.com:5671] closed qpid-send: Failed to connect (reconnect disabled) Is this better than the original error?
Created attachment 908305 [details] Patch for SaslAuthenticator.cpp.
Created attachment 908604 [details] Revised patch for SaslAuthenticator.cpp.
checked in revision 1612838 & credited Irina.
This is all about misleading error reported by the broker that is caused by malformed SSL certificate used by the client (the broker extracts the malformed or missing 'Common Name' from client certificate as an empty string). Broker error reporting was updated to make the reason of the broker connection reject more clear. Following line is now reported to broker log at warning level if authid is empty (CN malformed or missing in the client certificate): [Security] debug External ssf=128 and auth= [Security] warning SASL error: unable to offer EXTERNAL mechanism as authid cannot be determined Client reporting was left unchanged: [Client] warning Closing connection due to Desired mechanism(s) not valid: EXTERNAL Fixed according solution suggested in comment 12. Verified on rhel6.6 (x86_64 and i386) and rhel7 (x86_64). Packages: qpid-cpp-0.30-7 -> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0805.html