Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 601222 - Feature Request: support for SASL EXTERNAL with TLS/SSL
Feature Request: support for SASL EXTERNAL with TLS/SSL
Status: CLOSED ERRATA
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.2
All Linux
high Severity medium
: 1.2.2
: ---
Assigned To: Gordon Sim
Jan Sarenik
:
Depends On: 533045
Blocks: 567603
  Show dependency treegraph
 
Reported: 2010-06-07 09:57 EDT by Mike Cressman
Modified: 2012-02-06 12:52 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.
Story Points: ---
Clone Of: 533045
Environment:
Last Closed: 2010-10-07 21:50:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
qpidd.log (5.40 KB, text/plain)
2010-08-06 10:08 EDT, Jan Sarenik
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0756 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Messaging security and bug fix update 1.2.2 2010-10-07 21:49:47 EDT

  None (edit)
Comment 1 Jan Sarenik 2010-06-08 03:50:38 EDT
According to changelog of qpidc package, I understood that version
0.5.752581-36_cust already contains the change. So I installed latest
build, which is qpidd-ssl-0.5.752581-39_cust.el5 on RHEL5 i386 and
it did not work.

[root@slanina bz533045-2]# ./run 
Creating certificates... done
2010-jun-08 09:48:21 critical Broker start-up failed: Error in command line options: unknown option ssl-require-client-authentication
Use --help to see valid options
Comment 2 Gordon Sim 2010-06-08 04:17:27 EDT
ssl-require-client-authentication was not a new option introduced with this change. That error implies/suggests that the ssl module was not loaded. what does /usr/sbinqpidd --help show? Does it list the ssl options?
Comment 4 Jan Sarenik 2010-06-08 04:59:55 EDT
Verified on RHEL5 i386, qpidd-ssl-0.5.752581-39_cust.el5
Comment 5 Jan Sarenik 2010-06-08 06:46:36 EDT
Verified also on RHEL5 x86_64, qpidd-ssl-0.5.752581-39_cust.el5
Comment 7 Mike Cressman 2010-07-30 16:50:48 EDT
Please reverify with errata build -41 when we get it to candidate
Comment 8 Jan Sarenik 2010-08-04 02:46:29 EDT
I will verify as soon as qpidc-0.5.752581-41 appears in Brew.
Comment 9 Jan Sarenik 2010-08-06 06:20:56 EDT
I am having problems with this build (-41) on both RHELs, both archs.
Will write more soon.
Comment 10 Jan Sarenik 2010-08-06 10:08:20 EDT
Created attachment 437162 [details]
qpidd.log

redhat-release-5Server-5.5.0.2 x86_64
qpidc-perftest-0.5.752581-41.el5
qpidd-0.5.752581-41.el5
qpidd-ssl-0.5.752581-41.el5
qpidc-ssl-0.5.752581-41.el5

1. I create all the certificates using certutil (from nss-tools):
    echo "hoj11597" > pwdfile.txt
    echo "aoeunthao eanote haont he432 aontueh" > noise.txt
    certutil -N -d . -f pwdfile.txt
    certutil -G -d . -z noise.txt -f pwdfile.txt
    certutil -S -n ourCA -s "cn=CAcert" -x -t "CT,," -m 1000 -v 120 -d . \
        -z noise.txt -f pwdfile.txt
    certutil -S -n ourServer -s "CN=$HOSTNAME,O=acme,ST=Mass,C=US" \
        -c ourCA -t "u,u,u" -m 1001 -v 120 -d . -z noise.txt -f pwdfile.txt
    certutil -S -n ourClient -s "CN=bob@example.com,O=acme,ST=Mass,C=US" \
        -c ourCA -t "u,u,u" -m 1002 -v 120 -d . -z noise.txt -f pwdfile.txt
    certutil -L -d . -n ourCA -a > cacert.asc

2. I run qpidd using following command:
    qpidd -d --ssl-require-client-authentication \
    --ssl-cert-db $PWD \
    --ssl-cert-password-file $PWD/pwdfile.txt \
    --ssl-cert-name ourServer \
    --auth yes --log-to-file qpidd.log -t

3. I run perftest:
    export QPID_LOAD_MODULE=`rpm -ql qpidc-ssl | grep sslconnector.so`
    export QPID_SSL_CERT_NAME=ourClient
    export QPID_SSL_CERT_DB=$PWD
    export QPID_SSL_CERT_PASSWORD_FILE=$PWD/pwdfile.txt
    perftest --count 10 --port 5671 -P ssl -b $HOSTNAME --summary

When prompted for password, I press ENTER.

4. Stop the qpidd:
    qpidd -q

(and if I repeat step #3 a couple of times, I get a core dump
from perftest)

My question is, why is PLAIN password being asked for?
Comment 11 Jan Sarenik 2010-08-06 10:17:22 EDT
It is vital to add --ssl-sasl-no-dict to qpidd options.
Comment 12 Gordon Sim 2010-08-06 10:25:00 EDT
--ssl-sasl-no-dict restricts the valid mechanisms (for ssl connections); if not present the client can select from all those configured for the broker as usual. If the client does not explicitly choose one the choice will be made by the cyrus sasl libs (and is essentially random it seems).

So to test EXTERNAL, either choose it explicitly (as for any other mechanism) or force it to be the only one available by specifying --ssl-sasl-no-dict.
Comment 13 Jan Sarenik 2010-08-18 04:35:53 EDT
Verified on RHEL4 and RHEL5, builds
  qpidc-0.5.752581-41.el4
  qpidc-0.5.752581-41.el5
Comment 14 Jan Sarenik 2010-08-18 04:59:16 EDT
Both architectures, of course...

       | RHEL4 | RHEL5 |
------------------------
i386   |  OK   |  OK   |
x86_64 |  OK   |  OK   |
Comment 15 Gordon Sim 2010-09-24 12:29:07 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Desire to utilise the client identity as authenticated by SSL in authorisation.

Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs.

Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL.

Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.
Comment 16 errata-xmlrpc 2010-10-07 21:50:00 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0756.html
Comment 17 Jaromir Hradilek 2010-10-08 09:35:03 EDT
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1 @@
-Cause: Desire to utilise the client identity as authenticated by SSL in authorisation.
+Previously, the only way for a user to connect over Secure Sockets Layer (SSL) was to authenticate using a different username, otherwise the access control list (ACL) denied the access. This update introduces a support for the EXTERNAL mechanism for Simple Authentication and Security Layer (SASL), so that users can now connect using the SSL client certificates for authentication.-
-Consequence: Without this feature clients connecting over SSL would need to authenticate themselves by some other username for them to have permission granted via ACLs.
-
-Change: Allow the authenticated identity from the underlying SSL connection to be used. This is done by supporting the EXTERNAL mechanism defined for SASL.
-
-Result: Can now use the identity as authenticated by SSL (i.e. based on the clients certificate) when writing ACL rules.

Note You need to log in before you can comment on or make changes to this bug.