[
https://issues.apache.org/jira/browse/QPID-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ken Giusti updated QPID-1899:
-----------------------------
Attachment: qpid-1899-9-17.patch
Good question - I haven't found an example for the recommended usage of
SASL_SSF_EXTERNAL. On experimentation, setting it to 256 appears to prevent
the additional encryption, whereas setting it to 56 (the value that usually
gets negotiated) doesn't prevent the additional encryption. I'll google/post
a Q to the sasl mailing lists to see if I can get some clarification on its
intended use.
Ideally, I'd like to see a solution where the new encrypted() outputcontrol
method returns an "ssf-like" encryption level supplied by the transport (with 0
== none), instead of a bool. The returned value could be used to determine a
meaningful input to SASL_SSF_EXTERNAL. Thoughts?
In any case, attached is the current, non-SASL_SSF_EXTERNAL fix.
> --require-encryption doesn't work unless cyrus sasl authentication is turned
> on
> -------------------------------------------------------------------------------
>
> Key: QPID-1899
> URL: https://issues.apache.org/jira/browse/QPID-1899
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.5
> Reporter: Gordon Sim
> Assignee: Gordon Sim
> Fix For: 0.6
>
> Attachments: qpid-1899-9-17.patch, qpid-1899-hacky.patch
>
>
> If you specify --require-encryption and --auth no then the broker will allow
> un-encrypted conections. (If on the other hand you have authentication on, it
> will prevent you connecting with anything other than a mech that supports
> encryption and will require an encrypting sasl security layer - or of course
> an ssl connection)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
