Thanks for gibberbot.
An issue with the latest 9/16 build:
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.
Thanks. Will look at this right away!
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.
regarding the jid and SRV record,, the behavior is similar:
Again, you are saying we should not set a connect server by default, and instead we should just use SRV?
This should be addresses by this commit: a59b8d3
and it will be in our next update.
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">
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
regarding your questions:
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.
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?
What is different about Google's PLAIN? It sends this:
Looks the same, yes? Does it respond differently?
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.
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.