qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (PROTON-950) SASL PLAIN over cleartext should be supported
Date Mon, 03 Aug 2015 21:10:05 GMT

    [ 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)

Mime
View raw message