We're updating the issue view to help you get more done. 

SASL server in OF creates digest-uri based on xmpp.fqdn but it sends xmpp.domain to the client

Description

SMACK use for digest-uri whatever receives from OPENFIRE:

PacketReader.java

Here is how Openfire calculates the "from" tag:

StanzaHandler.java

Looking at:
sb.append("\" from=\"");
sb.append(serverName); - serverName represents session.getServerName() - which may be different than xmpp.fqdn

On the other hand, Openfire creates the SASL Server like this:

SASLAuthentication.java

The value: JiveGlobals.getProperty("xmpp.fqdn", session.getServerName()) is used for creating the digest-uri at server level, but it does not match with the value sent to the client (smack) for creating the client digest-uri. There is no reason to use JiveGlobals.getProperty("xmpp.fqdn", session.getServerName()) , we can use only session.getServerName(), even if it does not have the exact form of RFC-2831 - but server's digest-uri must be the same with what is sent to the client in the "form" tag

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Guus der Kinderen
May 9, 2016, 8:34 PM

Note that none of our SaslMechanism implementations actually use this value. Smack 4 sends the fully qualified host name when doing GSSAPI. Reverting the change should have minimal impact.

Guus der Kinderen
August 16, 2016, 10:55 AM

In my last statement, I was partly wrong. At least one third party SaslMechanism does use the serverName value: it's the DIGEST-MD5 mechanism. Specifically: the value is used to compute the digest-url value.

Here's where things get interesting: according to the specifications in RFC2831, DIGEST-MD5's digest-url should use the fully qualified host name. With that in mind, my last change would have been an improvement. However, it turns out that many XMPP clients actually use the XMPP domain name, instead of the fully qualified host name (we've checked the current code of Smack, Conversations and Gajim). So, even though Openfire is currently (prior to my fix) misbehaving in regards to DIGEST-MD5, many clients are doing the same thing, causing the combination of the two to work.

I've now prepared a change that will cause openfire to use the FQHN by default, but will use the XMPP domain name when the DIGEST-MD5 mechanism is used. The pull request is here: https://github.com/igniterealtime/Openfire/pull/629

It'd be nicer to have a DIGEST-MD5 mechanism implementation that would allow for the domain name as well as the FQHN to be used. So far, I've not been able to find an implementation that does that, or is Apache-licensed, allowing us to make modifications.

Guus der Kinderen
August 16, 2016, 1:45 PM
Daryl Herzmann
December 12, 2016, 3:19 PM

Setting as blocker prior to 4.1 release as this issue needs to be resolved.

Guus der Kinderen
December 18, 2016, 10:19 AM

From Openfire 4.1.0, the XMPP domain name will be used for SASL mechanisms, with the exception of the DIGEST-MD5 mechanism, which will use the fully qualified domain name (server name) as discussed in earlier comment on this issue.

Additionally, Openfire will now, by default, use the canonical hostname as a default server name (instead of an earlier value, that was less likely to be a fully qualified domain name). The setup wizard has been modified slightly to explicitly ask for both the XMPP domain name, as well as the fully qualified domain name.

Assignee

Guus der Kinderen

Reporter

Mircea Carasel

Labels

None

Expected Effort

None

Ignite Forum URL

None

Fix versions

Priority

Blocker
Configure