You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (Commented) (JIRA)" <ji...@apache.org> on 2012/01/31 20:00:11 UTC
[jira] [Commented] (QPID-3175) SSL support in Python client
libraries
[ https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197121#comment-13197121 ]
Keith Wall commented on QPID-3175:
----------------------------------
I think the change of the default SASL mechanism to ANONYMOUS broken the Python/Javabuild:
{code}
Error during test: Traceback (most recent call last):
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid-python-test", line 340, in run
phase()
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/tests/messaging/endpoints.py", line 34, in testEstablish
self.conn = Connection.establish(self.broker, **self.connection_options())
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 68, in establish
conn.open()
File "<string>", line 6, in open
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 255, in open
self.attach()
File "<string>", line 6, in attach
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 273, in attach
self._ewait(lambda: self._transport_connected and not self._unlinked())
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 208, in _ewait
self.check_error()
File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 201, in check_error
raise self.error
AuthenticationFailure: sasl negotiation failed: no mechanism agreed
{code}
See:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/lastCompletedBuild/testReport/
Whilst I think we could change the test harness configuration to pass through the sasl_mechanisms of PLAIN, I wonder why the decision to default has been made? I don't see how this contributes to SSL support.
The old code would default to PLAIN if username/password was supplied and PLAIN was support by the Broker (sasl.py:89) which I think was a useful default regardless of Broker choice.
Any thoughts please?
> SSL support in Python client libraries
> --------------------------------------
>
> Key: QPID-3175
> URL: https://issues.apache.org/jira/browse/QPID-3175
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
> Affects Versions: 0.8
> Environment: Windows XP, Python 2.7.1, (broker Red Hat MRG 1.3 on RHEL 5.5)
> Reporter: JAkub Scholz
> Assignee: Rafael H. Schloming
> Fix For: 0.15
>
> Attachments: QPID-3175.patch, QPID-3175a.patch
>
>
> I was trying to connect to my broker with SSL encrypted connection (both PLAIN and EXTERNAL authentication methods). However, it seems to be not working. I get following error messages:
> Traceback (most recent call last):
> File "ssl-external.py", line 20, in <module>
> connection.open()
> File "<string>", line 6, in open
> File "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py", line 244, in open
> self.attach()
> File "<string>", line 6, in attach
> File "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py", line 262, in attach
> self._ewait(lambda: self._transport_connected and not self._unlinked())
> File "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py", line 197, in _ewait
> self.check_error()
> File "c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py", line 190, in check_error
> raise self.error
> qpid.messaging.exceptions.ConnectError: [Errno 1] _ssl.c:499: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
> In the source codes (messaging/transports.py), the SSL seems to be supported and implemented, but it is not working. I didn't found any possibilities how to pass the certificates to the SSL libraries and the wrap_socket call in transports.py is calling the wrap_socket without any additional attributes except the original socket.
> I didn't had the chance to test other platforms or Python versions, except Python 2.4.3 on RHEL 5.5, where the SSL is not supported at all (the SSL support in Python changed significantly with 2.6)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] [Commented] (QPID-3175) SSL support in Python client libraries
Posted by Robbie Gemmell <ro...@gmail.com>.
On 2 February 2012 14:57, Robbie Gemmell <ro...@gmail.com> wrote:
> On 31 January 2012 19:28, Justin Ross <jr...@redhat.com> wrote:
>>
>>
>> On Tue, 31 Jan 2012, Keith Wall (Commented) (JIRA) wrote:
>>
>>>
>>> [
>>> https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197121#comment-13197121
>>> ]
>>>
>>> Keith Wall commented on QPID-3175:
>>> ----------------------------------
>>>
>>> I think the change of the default SASL mechanism to ANONYMOUS broken the
>>> Python/Javabuild:
>>>
>>> {code}
>>>
>>> Error during test: Traceback (most recent call last):
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid-python-test",
>>> line 340, in run
>>> phase()
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/tests/messaging/endpoints.py",
>>> line 34, in testEstablish
>>> self.conn = Connection.establish(self.broker,
>>> **self.connection_options())
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>>> line 68, in establish
>>> conn.open()
>>> File "<string>", line 6, in open
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>>> line 255, in open
>>> self.attach()
>>> File "<string>", line 6, in attach
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>>> line 273, in attach
>>> self._ewait(lambda: self._transport_connected and not
>>> self._unlinked())
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>>> line 208, in _ewait
>>> self.check_error()
>>> File
>>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>>> line 201, in check_error
>>> raise self.error
>>> AuthenticationFailure: sasl negotiation failed: no mechanism agreed
>>>
>>> {code}
>>>
>>> See:
>>>
>>>
>>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/lastCompletedBuild/testReport/
>>>
>>> Whilst I think we could change the test harness configuration to pass
>>> through the sasl_mechanisms of PLAIN, I wonder why the decision to default
>>> has been made? I don't see how this contributes to SSL support.
>>>
>>> The old code would default to PLAIN if username/password was supplied and
>>> PLAIN was support by the Broker (sasl.py:89) which I think was a useful
>>> default regardless of Broker choice.
>>>
>>> Any thoughts please?
>>
>>
>> You're right, this relates to ssl but doesn't contribute to it.
>>
>> Taken as a question on its own, however, I think the default sasl mech lists
>> ought to be the following:
>>
>> client (anonymous)
>> broker (anonymous, digest-md5)
>> -> negotiates to anonymous
>>
>> The trouble with plain is that it offers no meaningful security when not
>> used in concert with ssl. We've gone one worse and faked anonymous by
>> introducing default 'guest' credentials. The straightforward, no-surprises
>> way to do this is simply to use anonymous.
>>
>> Digest-md5 does offer meaningful security and requires little integration
>> with other systems. It therefore should serve as our primary option for
>> credentialed access. In this case:
>>
>> client explicitly sets (digest-md5), overriding default (anonymous)
>> broker (anonymous, digest-md5)
>> -> negotiates to digest-md5
>>
>> Importantly, by using anonymous we can create a separate privilege domain
>> for operations such as wiring changes, etc. It also could reduce the number
>> of steps an administrator must take to make the system secure. We can
>> (eventually) make it as simple as "disable anonymous".
>>
>> In summary, I think plain should be out of the *default* picture, for all
>> clients and brokers.
>>
>> Justin
>>
>>
>
>
> Hi Justin,
>
> I have to say I disagree with agood chunk of what you have said above,
> and see PLAIN as a better default than ANONYMOUS for a variety of
> reasons.
>
> I am heavily of the opinion that anonymous is something you should
> have to turn on if you want it, not the other way around. It is easy
> to think of a situation where someone doesnt know they should disable
> it, could accidently forget to disable it one time, etc. It seems less
> likely somone would accidently enable it. From my experience of other
> products, this is how I've found it usually works.
>
> Administrative actions in general are something I would normally
> expect to be authenticated, so even if there were to be an option to
> have some of those made anonymous I would never expect that to be the
> norm. An "enable anonymous" option is just as easy as the reverse
> would be and is, in my experience at least, far less likely to be
> used.
>
> Although in itself PLAIN offers little real security, it can and does
> help prevent people accidentally doing stupid things like connecting
> to the wrong broker (really, it happens), and coupled with SSL is as
> mentioned in some ways still a very useful choice.
>
Or as not actually mentioned because I seemed to have inadvertantly
deleted it, what makes PLAIN useful with SSL is the ability for the
broker (/external system) to still authenticate passwords which are
not stored as clear text.
> This topic has obviously come up due to the fact the Java broker
> currently doesnt support anonymous at all, which is why the Python
> tests are now failing or not running (most of the useful ones are
> skipped) against it after the change was made. The underlying support
> is actually there but just isnt used, and although we could (and
> probably should) add the ability to do so it isn't something I recall
> anyone ever requesting.
>
> Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] [Commented] (QPID-3175) SSL support in Python client libraries
Posted by Robbie Gemmell <ro...@gmail.com>.
On 31 January 2012 19:28, Justin Ross <jr...@redhat.com> wrote:
>
>
> On Tue, 31 Jan 2012, Keith Wall (Commented) (JIRA) wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197121#comment-13197121
>> ]
>>
>> Keith Wall commented on QPID-3175:
>> ----------------------------------
>>
>> I think the change of the default SASL mechanism to ANONYMOUS broken the
>> Python/Javabuild:
>>
>> {code}
>>
>> Error during test: Traceback (most recent call last):
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid-python-test",
>> line 340, in run
>> phase()
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/tests/messaging/endpoints.py",
>> line 34, in testEstablish
>> self.conn = Connection.establish(self.broker,
>> **self.connection_options())
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>> line 68, in establish
>> conn.open()
>> File "<string>", line 6, in open
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>> line 255, in open
>> self.attach()
>> File "<string>", line 6, in attach
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>> line 273, in attach
>> self._ewait(lambda: self._transport_connected and not
>> self._unlinked())
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>> line 208, in _ewait
>> self.check_error()
>> File
>> "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py",
>> line 201, in check_error
>> raise self.error
>> AuthenticationFailure: sasl negotiation failed: no mechanism agreed
>>
>> {code}
>>
>> See:
>>
>>
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/lastCompletedBuild/testReport/
>>
>> Whilst I think we could change the test harness configuration to pass
>> through the sasl_mechanisms of PLAIN, I wonder why the decision to default
>> has been made? I don't see how this contributes to SSL support.
>>
>> The old code would default to PLAIN if username/password was supplied and
>> PLAIN was support by the Broker (sasl.py:89) which I think was a useful
>> default regardless of Broker choice.
>>
>> Any thoughts please?
>
>
> You're right, this relates to ssl but doesn't contribute to it.
>
> Taken as a question on its own, however, I think the default sasl mech lists
> ought to be the following:
>
> client (anonymous)
> broker (anonymous, digest-md5)
> -> negotiates to anonymous
>
> The trouble with plain is that it offers no meaningful security when not
> used in concert with ssl. We've gone one worse and faked anonymous by
> introducing default 'guest' credentials. The straightforward, no-surprises
> way to do this is simply to use anonymous.
>
> Digest-md5 does offer meaningful security and requires little integration
> with other systems. It therefore should serve as our primary option for
> credentialed access. In this case:
>
> client explicitly sets (digest-md5), overriding default (anonymous)
> broker (anonymous, digest-md5)
> -> negotiates to digest-md5
>
> Importantly, by using anonymous we can create a separate privilege domain
> for operations such as wiring changes, etc. It also could reduce the number
> of steps an administrator must take to make the system secure. We can
> (eventually) make it as simple as "disable anonymous".
>
> In summary, I think plain should be out of the *default* picture, for all
> clients and brokers.
>
> Justin
>
>
Hi Justin,
I have to say I disagree with agood chunk of what you have said above,
and see PLAIN as a better default than ANONYMOUS for a variety of
reasons.
I am heavily of the opinion that anonymous is something you should
have to turn on if you want it, not the other way around. It is easy
to think of a situation where someone doesnt know they should disable
it, could accidently forget to disable it one time, etc. It seems less
likely somone would accidently enable it. From my experience of other
products, this is how I've found it usually works.
Administrative actions in general are something I would normally
expect to be authenticated, so even if there were to be an option to
have some of those made anonymous I would never expect that to be the
norm. An "enable anonymous" option is just as easy as the reverse
would be and is, in my experience at least, far less likely to be
used.
Although in itself PLAIN offers little real security, it can and does
help prevent people accidentally doing stupid things like connecting
to the wrong broker (really, it happens), and coupled with SSL is as
mentioned in some ways still a very useful choice.
This topic has obviously come up due to the fact the Java broker
currently doesnt support anonymous at all, which is why the Python
tests are now failing or not running (most of the useful ones are
skipped) against it after the change was made. The underlying support
is actually there but just isnt used, and although we could (and
probably should) add the ability to do so it isn't something I recall
anyone ever requesting.
Robbie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [jira] [Commented] (QPID-3175) SSL support in Python client
libraries
Posted by Justin Ross <jr...@redhat.com>.
On Tue, 31 Jan 2012, Keith Wall (Commented) (JIRA) wrote:
>
> [ https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197121#comment-13197121 ]
>
> Keith Wall commented on QPID-3175:
> ----------------------------------
>
> I think the change of the default SASL mechanism to ANONYMOUS broken the Python/Javabuild:
>
> {code}
>
> Error during test: Traceback (most recent call last):
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid-python-test", line 340, in run
> phase()
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/tests/messaging/endpoints.py", line 34, in testEstablish
> self.conn = Connection.establish(self.broker, **self.connection_options())
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 68, in establish
> conn.open()
> File "<string>", line 6, in open
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 255, in open
> self.attach()
> File "<string>", line 6, in attach
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 273, in attach
> self._ewait(lambda: self._transport_connected and not self._unlinked())
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 208, in _ewait
> self.check_error()
> File "/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/trunk/qpid/python/qpid/messaging/endpoints.py", line 201, in check_error
> raise self.error
> AuthenticationFailure: sasl negotiation failed: no mechanism agreed
>
> {code}
>
> See:
>
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/lastCompletedBuild/testReport/
>
> Whilst I think we could change the test harness configuration to pass through the sasl_mechanisms of PLAIN, I wonder why the decision to default has been made? I don't see how this contributes to SSL support.
>
> The old code would default to PLAIN if username/password was supplied and PLAIN was support by the Broker (sasl.py:89) which I think was a useful default regardless of Broker choice.
>
> Any thoughts please?
You're right, this relates to ssl but doesn't contribute to it.
Taken as a question on its own, however, I think the default sasl mech
lists ought to be the following:
client (anonymous)
broker (anonymous, digest-md5)
-> negotiates to anonymous
The trouble with plain is that it offers no meaningful security when not
used in concert with ssl. We've gone one worse and faked anonymous by
introducing default 'guest' credentials. The straightforward,
no-surprises way to do this is simply to use anonymous.
Digest-md5 does offer meaningful security and requires little integration
with other systems. It therefore should serve as our primary option for
credentialed access. In this case:
client explicitly sets (digest-md5), overriding default (anonymous)
broker (anonymous, digest-md5)
-> negotiates to digest-md5
Importantly, by using anonymous we can create a separate privilege domain
for operations such as wiring changes, etc. It also could reduce the
number of steps an administrator must take to make the system secure. We
can (eventually) make it as simple as "disable anonymous".
In summary, I think plain should be out of the *default* picture, for all
clients and brokers.
Justin
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org