On 12 June 2015 at 17:45, Gordon Sim <[email protected]> wrote: > On 06/12/2015 10:48 AM, Rob Godfrey wrote: >> >> The documentation doesn't tend to go into the detail of the SASL >> mechanisms available from each provider (and how they may differ >> between TLS and non-TLS)... and from a general user perspective I'm >> not sure that would be useful. > > > I think it is useful to know that certain mechanisms are excluded unless > using an encrypted (TLS) connection. I do now recall I hit this when testing > the 0.32 release, but had forgotten. > > Some kind of warning on the console (or even in the logs) might help > perhaps.
The broker won't know because the client should be the one to detect the failure... I guess Proton may try to pipeline the sending of the mechanism without waiting to see which mechanisms the Broker offers, in which case an error may already be logged (I'd have to go check). > >> The issue here is interop between >> clients and brokers... and in general I think all clients should >> support some way of sending password information in non-plaintext if >> they are not using an encrypted channel. > > > As of 0.10 proton-c on linux will support different mechanisms if built > against cyrus-sasl. (If dev packages for cyrus-sasl are not installed I > believe you just get PLAIN and ANONYMOUS, which is the same for > qpid:messaging). (CRAM-MD5 is officialy deprecated in favour of DIGEST-MD5. > Cyrus-sasl supports both, but in some installations the former may > conceivably be disabled). I'll look into DIGEST-MD5... With a Plain password file the Java broker can also use SCRAM-SHA1/SCRAM-SHA256 ... IIRC Cyrus can at least do one of these (I used it as an independent test against my Java implementations). I can't remember if we left it in or not, but at one point the AMQP 1.0 spec did say that SCRAM-SHA* should be supported by all compliant implementations. > > SSL/TLS is also supported however, so that can be used. The key is just > understanding what the issue is. None of the error handling (client side or > server side) is great with a lot of these issues, which is another area we > can improve in. > > More interop testing is certainly key. Now we are movingto separate > releases, hopefully we can get more focus on each individual component as it > releases, to ensure that other things which might conceivably used along > side it can in fact do so. Yep - we should make sure collectively we know how to test all the components against each other - what test packs each component contains and how they can be run against other AMQP services/containers (including non-Qpid ones). -- Rob > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
