[BUG] SASL mechanisms provided if TLS is required

RFC 3920: Section 6.2.2:

If Use

of TLS (Section 5) needs to be established before a particular

authentication mechanism may be used, the receiving entity MUST

NOT provide that mechanism in the list of available SASL

authentication mechanisms prior to TLS negotiation.

so in /src/java/org/jivesoftware/wildfire/ClientSession.java: (line ~300)

sb.append("");

}

if (connection.getTlsPolicy() != Connection.TLSPolicy.required) {

// Include available SASL Mechanisms

sb.append(SASLAuthentication.getSASLMechanisms(session));

}

// Include Stream features

String specificFeatures = session.getAvailableStreamFeatures();

if (specificFeatures != null) {

sb.append(specificFeatures);

}

sb.append("</stream:features>");

Hi Norman,

this seems to be the only location where the SASL authentication methods are sent to the client, so if you change it like this the server seems to be no longer able to send SASL methods. Or did I miss something?

Does this RFC also apply for s2s, there’'s very similar code in IncomingServerSession.java?

LG

Ahh, then my guess would be that the SASLAuthentication.getSASLMechanisms call should be moved into the getAvailableStreamFeatures method at the same place that the iq-auth is announced.

And on the IncomingServerSession you’‘d need to do a similar check for ‘‘is tls required’’/’‘issecure’’, and only announce the sasl mechs if it’‘s secure, or doesn’'t require tls.

Message was edited by: normanr