[Vortex] [patch] Problem with SASL DIGEST-MD5 authentication
Matthias Peter Wimmer
mw at me-engineering-m2m.de
Thu Jun 25 13:24:26 CEST 2015
[Repost with correct/subscribed sender address.]
Hello,
current libvortex-1.1 sets the GSASL_HOSTNAME property of GnuSASL
always using the hostname of the system it is running on. In my opinion
this is incorrect.
This property is used to calculate the digest-uri value amongst others
in the DIGEST-MD5 mechanism. Which is defined to be [RFC 2831]:
digest-uri
Indicates the principal name of the service with which the client
wishes to connect, formed from the serv-type, host, and serv-name.
For example, the FTP service on "ftp.example.com" would have a
"digest-uri" value of "ftp/ftp.example.com"; [...]
This is meant to be able to detect if the SASL client did not connect to
the server it expected to.
This bug results in vortex not being able to communicate with our own
BEEP implemention that uses the SASL implementation that comes with
Java 8:
INFO: SASL auth failure: DIGEST-MD5: digest response format violation.
Mismatched URI: beep/atwork; expecting: beep/ci.vpatron.eu
(“atwork” is the hostname of the system vortex is running on.
“ci.vpatron.eu” is the hostname of the BEEP listening peer.)
I wrote a patch fixing this problem for us and thought it might be
helpful to fix this upstream as well. The patch is attached to this
e-mail message.
What I do in this patch:
- When Vortex is in the “VortexRoleInitiator” role I do initialize the
GnuSASL property “GSASL_HOSTNAME” with the host property of the
VortexConnection instead of the locale hostname.
Actually this did really work. With vortex_connection_get_host() I do
get the IP address of the host I connected to instead of the hostname
I provided. (Is this a bug as well?)
- I added a new Vortex-SASL property VORTEX_SASL_HOSTNAME with which the
user of the library can manually select the hostname the SASL
implementation is using.
Other notes:
- I am unsure if it is correct to check the role of the VortexConnection
to detect whether I am SASL server or client. I think as it is this
implementation only works if the BEEP Initiator is also the initiating
side of the SASL handshake.
- The “case VORTEX_SASL_ANONYMOUS_TOKEN” within the switch statement in
sasl/vortex_sasl.c line 319 misses a break statement. (Which currently
is no big problem as a fall-through to the next case did not cause
harm.)
- Accordning to configure.ac current libvortex claims to be compatible
with libaxl version 0.6.4 or higher. I was not able to compile
libvortex against version 0.6.4.b4604.g4608 as this version does not
define “axl_list_equal_ptr”. Updating to 0.7.0 from SVN did help.
- The autogen.sh script in libaxl did not work for me. Automake 1.14.1
does not accept the option “--Werror”. Removing this option did work.
Regards,
Matthias
--
‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒
ME Engineering M2M GmbH
Ein Unternehmen der ME Industries
Matthias Wimmer
Seniorentwickler
Neumarkter Straße 23
81673 München
Deutschland
Fon: +49 (0)89 4161552-14
Fax: +49 (0)89 4161552-90
http://me-engineering-m2m.de/
mailto:mw at me-engineering-m2m.de
‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒‒
Amtsgericht München: HRB 205071
Geschäftsführer:
Norman Weiß, Mathias Müller
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vortex_sasl_hostname.patch
Type: text/x-diff
Size: 3461 bytes
Desc: not available
URL: <http://lists.aspl.es/pipermail/vortex/attachments/20150625/7ae3a1bc/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.aspl.es/pipermail/vortex/attachments/20150625/7ae3a1bc/attachment.pgp>
More information about the Vortex
mailing list