[Vortex] [patch] Problem with SASL DIGEST-MD5 authentication
Francis Brosnan Blázquez
francis at aspl.es
Thu Jul 2 19:39:19 CEST 2015
Thanks for reporting and giving a fully clean and working patch :-) I've
updated it to include a minor correction, but certainly it fixes
reporting GSASL level which is the hostName/serverName we are going to
> 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.
Certainly it is,
> This property is used to calculate the digest-uri value amongst others
> in the DIGEST-MD5 mechanism. Which is defined to be [RFC 2831]:
> 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.)
Perfect. BTW, does your implementation have a webpage? It would be very
useful to have it listed at beepcore.org. I can take care of this if you
are interested. Please, provide to the list more details about your
implementation (if possible :-)
> 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.
Ok, I've updated this code to first call to get current BEEP serverName,
which might be already configured previous, for example, due to TLS
profile activation or because a WebSocket transport was used, both cases
setup that serverName. After that, a call to vortex_connection_get_host
is done if nothing is reported,
> 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?)
Technically calling to vortex_connection_get_host() reports the host
address that was used to connect and vortex_connection_get_host_ip()
reports the IP address that resolved _get_host ()
...not sure why you are getting an IP there :-?
> - 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.
Technically initiator and listener have nothing to do with client and
server...however, in the context of the SASL technology, I see no better
way to initiate client/server defaults needed, especially knowing that
SASL is client/server technology (not peer to peer)... I see no problem
> - 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
Ok, you fixed it anyway by adding the last case,
> - 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.
Got it. I've updated configure.ac references to better reflect this,
> - 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.
Fixed too. It was already removed from vortex's autogen.sh but not
Again, thanks for reporting, and, if possible, let us know about your
> Vortex mailing list
> Vortex at lists.aspl.es
Francis Brosnan Blázquez <francis.brosnan at aspl.es>
91 134 14 22 - 91 134 14 45 - 91 116 07 57
Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
More information about the Vortex