Profanity: Don't use legacy auth by default

Created on 7 Feb 2017 · 13Comments · Source: profanity-im/profanity

When I try to connect to a server that does not support legacy authentication (used by default in profanity) I always get rejected: xmpp: ERR: Server did not reply to legacy authentication request.
Can connect with same setup, forced TLS, etc from pidgin.

System info:

ArchLinux 4.9.6-1 x86_64

Profanity 0.5.1
XMPP library: libmesode
Desktop notification support: Enabled
OTR support: Enabled
PGP support: Enabled
C plugins: Enabled
Python plugins: Enabled
GTK icons: Disabled

improvement

Source

Silur

Most helpful comment

The authentication process is quite tricky. First of all, Profanity doesn't control this process. The only thing Profanity can do is to enable/disable some TLS features through flags (remember /connect ... tls trust and similar?).

All the connection and authentication process is done within libstrophe. And the library tries all available authentication methods until one succeeds. The more trusted and secure methods go first. For example, if both libstrophe and server support SCRAM-SHA-1 it will be checked first. If it fails, DIGEST-MD5 goes next, then PLAIN and if all methods fail legacy authentication goes the last. The thing is that wrong login/password always leads to using all auth methods and PLAIN and legacy auth send open password. This is not good. This is the reason I disabled it. PLAIN method should be treated as well.

And concluding the above, you login to your prosody server because one of SASL methods succeeds. If you enter a wrong password and look at debug logs, you will see an error from legacy auth just before connection is terminated.

pasis on 2 Oct 2019

👍2

All 13 comments

If you can attach the full logs (running profanity -l DEBUG) during the connection attempt I'll try to take a look.

Remember to remove any credentials etc.

Thanks.

boothj5 on 8 Feb 2017

07/02/2017 13:44:28: xmpp: DBG: Attempting to connect to REMOVED
07/02/2017 13:44:29: xmpp: DBG: connection successful
07/02/2017 13:44:29: conn: DBG: SENT: <?xml version="1.0"?><stream:stream to="REMOVED" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
07/02/2017 13:44:30: xmpp: DBG: RECV: <stream:stream version="1.0" from="REMOVED" id="919002f3-7095-41a3-bd2c-9c3d2825df37" to="" lang="en">
07/02/2017 13:44:30: xmpp: DBG: RECV: <features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><dialback xmlns="urn:xmpp:features:dialback"/></features>
07/02/2017 13:44:30: conn: DBG: SENT: <starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
07/02/2017 13:44:31: xmpp: DBG: RECV: <proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
07/02/2017 13:44:31: xmpp: DBG: handle proceedtls called for proceed
07/02/2017 13:44:31: xmpp: DBG: proceeding with TLS
07/02/2017 13:44:32: TLS: DBG: STACK
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /CN=www.REMOVED
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ENDSTACK
07/02/2017 13:44:32: TLS: DBG: STACK
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /CN=www.REMOVED
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ENDSTACK
07/02/2017 13:44:32: TLS: DBG: STACK
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /CN=www.REMOVED
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=RapidSSL SHA256 CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: SUBJECT : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ISSUER  : /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
07/02/2017 13:44:32: TLS: DBG: ENDSTACK
07/02/2017 13:44:33: conn: DBG: SENT: <?xml version="1.0"?><stream:stream to="REMOVED" xml:lang="en" version="1.0" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams">
07/02/2017 13:44:34: xmpp: DBG: RECV: <stream:stream version="1.0" from="REMOVED" id="3fac154a-fef3-4306-9c49-4bee08111691" to="" lang="en">
07/02/2017 13:44:34: xmpp: DBG: RECV: <features xmlns="http://etherx.jabber.org/streams"><dialback xmlns="urn:xmpp:features:dialback"/></features>
07/02/2017 13:44:34: conn: DBG: SENT: <iq id="_xmpp_auth1" type="set"><query xmlns="jabber:iq:auth"><username>REMOVED</username><password>REMOVED</password><resource>profanity</resource></query></iq>
07/02/2017 13:44:49: xmpp: ERR: Server did not reply to legacy authentication request.
07/02/2017 13:44:49: conn: DBG: SENT: </stream:stream>
07/02/2017 13:44:51: xmpp: DBG: RECV: </stream:stream>
07/02/2017 13:44:51: xmpp: DBG: Closing socket.
07/02/2017 13:44:51: prof: DBG: Connection handler: XMPP_CONN_DISCONNECT
07/02/2017 13:44:51: prof: DBG: Connection handler: Login failed
07/02/2017 13:44:51: prof: DBG: Connection handler: No reconnect timer
07/02/2017 13:44:51: prof: INF: Login failed

Silur on 8 Feb 2017

Legacy authentication is a part of the libstrophe's authentication process. Profanity can't control it. So the problem should be fixed in libstrophe.

pasis on 9 Feb 2017

@pasis what should we do with this?

jubalh on 20 Feb 2019

People complained about legacy auth multiple times. I will need to disable it by default in libstrophe.

pasis on 1 Oct 2019

Disabled in https://github.com/strophe/libstrophe/commit/30f3cc9263de9b063b7b04de51d8cc0ca240f589. Will be in libstrophe-0.9.3.

pasis on 1 Oct 2019

❤1

Do you know who will bring the new libstrophe commits to libmesode?

jubalh on 1 Oct 2019

The issue says profanity is using legacy auth by default. I wonder why profanity connects just fine to my server then, as you need to explicitly enable mod_legacyauth for prosody which I never did.

mdosch on 2 Oct 2019

pasis on 2 Oct 2019

👍2

Do you know who will bring the new libstrophe commits to libmesode?

@jubalh, unfortunately, merging libstrophe and libmesode takes too much effort. I would recommend libmesode-0.9.3 to be the last one and then close the project. The only difference between them feature-wise is TLS cert callback and so. Better move the effort to implement this functionality in libstrophe in proper way.

Moreover, there is a pull request which will make merging even more harder: https://github.com/strophe/libstrophe/pull/138.

pasis on 2 Oct 2019

I would recommend libmesode-0.9.3 to be the last one and then close the project. The only difference between them feature-wise is TLS cert callback and so. Better move the effort to implement this functionality in libstrophe in proper way.

I am strongly in favour of this. I never understood why the TLS changes were not made in libstrophe upstream in the first place instead forking. The non-Windows code in libmesode was also not a good reason for me. Especially when one thinks about the manpower the project has.

Moreover, there is a pull request which will make merging even more harder: strophe/libstrophe#138.

Yeah I saw that one too.
If you merge it. Then maybe for profanity 0.8.0 we should already drop recommending libmesode and say we depend on libstrophe 0.9.3?

jubalh on 2 Oct 2019

Until cert callback is implemented in libstrophe, you can leave libmesode recommendation (if someone going to merge bugfixes from libstrophe-0.9.3).

Profanity doesn't depend on 0.9.3, so this can be only recommendation, because earlier releases contain bugs, but Profanity still builds against earlier libstrophe.

Btw, I don't plan new TLS cert features in 0.9.3, it will be for 0.10.0 (if I or someone else will have time to implement it :))

pasis on 4 Oct 2019

Profanity doesn't depend on 0.9.3, so this can be only recommendation, because earlier releases contain bugs, but Profanity still builds against earlier libstrophe.

Yeah it builds. But if we want Profanity 0.8.0 to have this issue here (dont use legacy auth) closed, it might make sense to recommend 0.9.3 of libstrophe instead, in case noone is taking care of libmesode.

But I will try to take a look and merge libstrophe changes into libmesode. So that we have this fixed and still the TLS features.