On 31 January 2012 19:28, Justin Ross <[email protected]> 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:[email protected]
