Gibberbot attempts plain text auth even when disabled #68

Closed
elijh opened this Issue Sep 21, 2011 · 11 comments

Comments

Projects
None yet
2 participants

elijh commented Sep 21, 2011

Thanks for gibberbot.

An issue with the latest 9/16 build:

  1. start gibberbot for the first time
  2. fill in username and password, leaving advanced settings untouched
  3. click "sign in"
  4. I get a generic connection error. the logs say "Server does not support compatible authentication mechanism." I get this error whenever "allow plain text auth" is enabled. This seems like a bug in its own right, because enabling plain text auth should not force plain text auth, but regardless, the point here is that "allow plain text auth" was NOT checked when i hit sign in, but now it is attempting plain text auth.
  5. hit back button and edit advanced settings.
  6. "allow plain text auth" has now been mysteriously checked. uncheck it.
  7. click "sign in"
  8. success

My conclusion: when setting up a new account, the visible defaults are ignore and "allow plain text auth" is enabled. For a chat app with a focus on security, I think this is not advisable (!).

The other advanced setting that is mysteriously altered is the "connect server" option. it goes from blank to the domain of the JID. In my case, I can still connect even though the incorrect "connect server" value is set, because the SRV record is still used, but ideally "connect server" would stay blank (and also override the SRV record if present).

Keep up the good work.

Owner

n8fr8 commented Sep 21, 2011

Thanks. Will look at this right away!

Owner

n8fr8 commented Sep 21, 2011

We have "allow plain text auth" as a default turned on along with TLS required and verify on as well. Some XMPP services, like Gmail but also others, only support plain text over TLS.

Essentially what happens is that when you enter in your usr/pwd the first time, we set some config defaults based on your domain, i.e. jabber.org has cert defaults. For a not known domain, we set TLS required, TLS verify ON, but also plain text auth ON.

Perhaps our default should be plain auth OFF, even with TLS on.

If you have TLS off, we don't allow plain text auth at all, even if checked.

Owner

n8fr8 commented Sep 21, 2011

regarding the jid and SRV record,, the behavior is similar:

  1. the first time, we set a connect server default value based on the domain from your username.
  2. We also turn ON the SRV record, and if configured the value will override the connect server setting.
  3. For the connect server value to be used, SRV check but be turned off.

Again, you are saying we should not set a connect server by default, and instead we should just use SRV?

Owner

n8fr8 commented Sep 21, 2011

This should be addresses by this commit: a59b8d3

and it will be in our next update.

n8fr8 closed this Sep 21, 2011

elijh commented Sep 22, 2011

I think there is an additional bug here at play. I agree that it would be OK to allow plain text auth over required TLS connections by default. The problem I experience is that the only way to successfully connect to a server that only accepts SASL PLAIN over TLS is to disable plain text auth.

My server (openfire) sends

<?xml version='1.0' encoding='UTF-8'?>
<stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="riseup.net" id="e69e3610" xml:lang="en" version="1.0">
<stream:features>
  <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls>
  <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism></mechanisms>
</stream:features>

And yet I must uncheck "plain text auth" to be able to connect. If I don't, I get this exception:

E/Gibberbot.XmppConnection(26140): login failed
E/Gibberbot.XmppConnection(26140): Server does not support compatible authentication mechanism.: 
E/Gibberbot.XmppConnection(26140):  at org.jivesoftware.smack.NonSASLAuthentication.authenticate(NonSASLAuthentication.java:95)
E/Gibberbot.XmppConnection(26140):  at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:239)
E/Gibberbot.XmppConnection(26140):  at info.guardianproject.otr.app.im.plugin.xmpp.XmppConnection.initConnection(XmppConnection.java:600)
E/Gibberbot.XmppConnection(26140):  at info.guardianproject.otr.app.im.plugin.xmpp.XmppConnection.do_login(XmppConnection.java:285)
E/Gibberbot.XmppConnection(26140):  at info.guardianproject.otr.app.im.plugin.xmpp.XmppConnection.access$200(XmppConnection.java:75)
E/Gibberbot.XmppConnection(26140):  at info.guardianproject.otr.app.im.plugin.xmpp.XmppConnection$1.run(XmppConnection.java:256)
E/Gibberbot.XmppConnection(26140):  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1088)
E/Gibberbot.XmppConnection(26140):  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:581)
E/Gibberbot.XmppConnection(26140):  at java.lang.Thread.run(Thread.java:1019)
W/Gibberbot.XmppConnection(26140): will not retry
W/Gibberbot.XmppConnection(26140): disconnected

elijh commented Sep 22, 2011

regarding your questions:

  1. I think it is really good to enable SASL PLAIN. This is by far the most common auth mechanism. For my two cents, I think it is more secure, because the passwords can be stored in a non-reversible way, unlike CRAM-MD5. So, definitely, SASL PLAIN should be enabled. I can't think of many scenarios where you would ever want it disabled if non-TLS connections are not ever allowed. The server, in this regard, should be in the driver's seat deciding what mechanism should be tried.
  2. Ideally, using a 'connect server' and SRV would be mutually exclusive, both in the UI and the code.
  3. From a ui standpoint, it is very confusing to have a user check the settings, then click login, then have those settings change. I am not sure it is a win to try to be smart to set good settings based on the domain. Good defaults seem to be good enough for the other clients (pidgin is just: try SRV, TLS required, use whatever auth mechanism is supported by the server).

elijh commented Sep 22, 2011

Upon further investigation, there does not seem to be much correlation between the option "allow plain text auth" and if SASL PLAIN is attempted. I seem to have to often enable and then disable the option in order to get SASL PLAIN to work.

Owner

n8fr8 commented Sep 22, 2011

I think there are two "PLAIN"'s, there is SASL Plain, and there is the non-SASL Plain over TLS that Google likes.

We need to think through how to expose this all to the user. Perhaps we should just ask What Would Pidgin Do?

elijh commented Sep 22, 2011

WWPD!

What is different about Google's PLAIN? It sends this:

<stream:features>
    <mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
        <mechanism>PLAIN</mechanism>
        <mechanism>X-GOOGLE-TOKEN</mechanism>
        <mechanism>X-OAUTH2</mechanism>
    </mechanisms>
</stream:features>

Looks the same, yes? Does it respond differently?

elijh commented Sep 22, 2011

I guess the difference is that google doesn't send SASL <mechanism>PLAIN</mechanism> until after the TLS negotiations. That seems like a very reasonable idea to me. It would be cool if more servers did this.

I suspect the pidgin way is to try whatever auth mechanisms are mutually supported, with PLAIN having the lowest precedence.

Owner

n8fr8 commented Sep 22, 2011

Right. We had some issue with SASL Plain and Google that Hans (_hc) was dealing with. I will review that bit of code all again.

The Smack library handles precedence and SASL, so some of this is us digging down into that source to make sure it is doing what it says it is doing. In some cases, like with the TLS verification, we've forked the specific class, and moved it into our own package in order to take better control. Hopefully we won't have to do that here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment