qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: [jira] [Commented] (QPID-3175) SSL support in Python client libraries
Date Thu, 02 Feb 2012 14:57:10 GMT
On 31 January 2012 19:28, Justin Ross <jross@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


Mime
View raw message