[
https://issues.apache.org/jira/browse/PROTON-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14652521#comment-14652521
]
Robbie Gemmell edited comment on PROTON-950 at 8/3/15 9:09 PM:
---------------------------------------------------------------
I'm increasingly feeling that this new option should be flipped so that PLAIN
works by default and those that want to restrict it to SSL only can use it to
do so. As mentioned earlier, it seems inconsistent to me to allow ANONYMOUS and
no-SASL by default but deny PLAIN. It should only be used for lack of a better
option, and yet we know there are times it is going to be the only option right
now. It also seems like none of the client code makes it particularly easy
toggle it. We are going to get a lot of questions about this (once we actually
get it released..).
Thinking about it, I guess people already could already have prevented use of
PLAIN [without SSL] if they wanted to using the previous pn_sasl_allowed_mechs
config method? In which case there may not be a need for a specific toggle if
we flipped the default, though I can see it would still be easier to use that
than setting 'everything but PLAIN' as the allowed mechs. (EDIT: client side
that is, server side needs a toggle I guess if it wants to accept SSL and non
SSL connections)
New side thought based on above, what happens currently if the allowed mech(s)
are set to include only PLAIN (which I can see folks doing when trying to
figure out why it doesnt work anymore) but its actual use is prevented by the
transport defaults? Would people get the error Gordon was hunting for above, or
something more specific since its detectable in advance that there are no
usable mechs?
was (Author: gemmellr):
I'm increasingly feeling that this new option should be flipped so that PLAIN
works by default and those that want to restrict it to SSL only can use it to
do so. As mentioned earlier, it seems inconsistent to me to allow ANONYMOUS and
no-SASL by default but deny PLAIN. It should only be used for lack of a better
option, and yet we know there are times it is going to be the only option right
now. It also seems like none of the client code makes it particularly easy
toggle it. We are going to get a lot of questions about this (once we actually
get it released..).
Thinking about it, I guess people already could already have prevented use of
PLAIN [without SSL] if they wanted to using the previous pn_sasl_allowed_mechs
config method? In which case there may not be a need for a specific toggle if
we flipped the default, though I can see it would still be easier to use that
than setting 'everything but PLAIN' as the allowed mechs.
New side thought based on above, what happens currently if the allowed mech(s)
are set to include only PLAIN (which I can see folks doing when trying to
figure out why it doesnt work anymore) but its actual use is prevented by the
transport defaults? Would people get the error Gordon was hunting for above, or
something more specific since its detectable in advance that there are no
usable mechs?
> SASL PLAIN over cleartext should be supported
> ---------------------------------------------
>
> Key: PROTON-950
> URL: https://issues.apache.org/jira/browse/PROTON-950
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: 0.10
> Reporter: Ted Ross
> Assignee: Andrew Stitcher
> Priority: Blocker
> Fix For: 0.10
>
>
> In the current 0.10 alpha, if SASL PLAIN is selected, it will only work if
> the connection is encrypted (using SSL). This is a surprising change of
> behavior from earlier versions of Proton and it's arguable that a security
> policy like that should be left to the application using the Proton library.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
