Jorj Bauer

bug in OpenFire SASL handling

Discussion created by Jorj Bauer on Sep 24, 2015
Latest reply on Sep 24, 2015 by Jorj Bauer

(Apologies if this isn't an appropriate place to post this; hopefully it will help people debug this problem that I've been troubleshooting for the last few days.)

 

 

In src/java/org/jivesoftware/openfire/net/SASLAuthentication.java is this code:

 

    private static final Pattern BASE64_ENCODED = Pattern.compile("^(=|([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A- Za-z0-9+/]{2}==))$");

 

This makes the assumption that there is content in every stepwise reply. SASL allows the client to reply with empty strings, which allow the server to perform more work and send additional data before continuing. GSSAPI / Kerberos does exactly this; therefore, the base64 regex test above causes "invalid-encoding" XMPP errors to be sent to the client in the middle of SASL negotiation.

 

Modifying the pattern thusly fixes the issue, allowing an empty string in addition to base64 content:

 

    private static final Pattern BASE64_ENCODED = Pattern.compile("^((=|([A-Za-z0-9+/]{4})*([A-Za-z0-9+/]{4}|[A-Za-z0-9+/]{3}=|[A -Za-z0-9+/]{2}==)))?$");

Outcomes