On 2 February 2012 14:57, Robbie Gemmell <[email protected]> wrote: > 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. >
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:[email protected]
