#1006 prosody 0.10 does not handle s2s SASL EXTERNAL error gracefully
Reporter
Stefan Haller
Owner
Zash
Created
Updated
Stars
★★ (3)
Tags
Priority-Medium
Type-Defect
Milestone-0.10
Status-Fixed
Stefan Haller
on
What steps will reproduce the problem?
1. use self-signed certificate (or otherwise "invalid" cert, e.g. CACert as it got removed from Debian's default CA list)
2. establish s2s connection to server offering SASL EXTERNAL
What is the expected output?
Some other authentication mechanism than "EXTERNAL" succeeds.
What do you see instead?
Prosody is closing the connection after receiving an error from the remote side.
What version of the product are you using? On what operating system?
prosody-0.10, Debian stretch
Please provide any additional information below.
I don't know what the correct behaviour would be. According to [XEP-0178][0] the EXTERNAL authentication should fail if the certificate can not be validated. On the other hand a [discussion on a mailing list][1] indicates that EXTERNAL should only be offered by the remote server if the certificate has been validated successfully. Unfortunately, prosody can change the behaviour of the remote server and at least ejabberd offers "EXTERNAL" unconditionally and fails after validating the certificate.
Prior to prosody-0.10 everything worked, because prosody was falling back to dns dialback. This fallback was removed in changeset [2].
[0]: https://xmpp.org/extensions/xep-0178.html
[1]: https://mail.jabber.org/pipermail/standards/2007-January/013594.html
[2]: https://hg.prosody.im/0.10/rev/89c42aff8510
Zash
on
Prosody is following the XEP here. ejabberd is not.
We made Prosody follow the XEP more strictly in 0.10, but ejabberd went in the opposite direction.
Zash
on
Changes
owner Zash
tags Status-Started
Zash
on
According to ancient scrolls of wisdom, we removed the fallback becasue ejabberd simply closed the connection when we attempted it, which caused problems. Since then, ejabberd has apparently stopped that.
Reverted in https://hg.prosody.im/0.10/rev/e1d274001855
We may add a switch to turn this on or off.
Changes
tags Status-Fixed
Zash
on
Changes
tags Milestone-0.10
Lunar
on
I am still getting this problem in 0.10.1
May 30 19:56:35 s2sout55ae79cfd880 info Stream encrypted (TLSv1.2 with AES256-GCM-SHA384)
May 30 19:56:35 xmpp.is:saslauth info SASL EXTERNAL with exploit.im failed: unknown-condition
May 30 19:56:35 s2sout55ae79cfd880 info Outgoing s2s stream xmpp.is->exploit.im closed: stream closed
May 30 19:56:35 s2sout55ae79cfd880 info Sending error replies for 1 queued stanzas because of failed outgoing connection to exploit.im
What steps will reproduce the problem? 1. use self-signed certificate (or otherwise "invalid" cert, e.g. CACert as it got removed from Debian's default CA list) 2. establish s2s connection to server offering SASL EXTERNAL What is the expected output? Some other authentication mechanism than "EXTERNAL" succeeds. What do you see instead? Prosody is closing the connection after receiving an error from the remote side. What version of the product are you using? On what operating system? prosody-0.10, Debian stretch Please provide any additional information below. I don't know what the correct behaviour would be. According to [XEP-0178][0] the EXTERNAL authentication should fail if the certificate can not be validated. On the other hand a [discussion on a mailing list][1] indicates that EXTERNAL should only be offered by the remote server if the certificate has been validated successfully. Unfortunately, prosody can change the behaviour of the remote server and at least ejabberd offers "EXTERNAL" unconditionally and fails after validating the certificate. Prior to prosody-0.10 everything worked, because prosody was falling back to dns dialback. This fallback was removed in changeset [2]. [0]: https://xmpp.org/extensions/xep-0178.html [1]: https://mail.jabber.org/pipermail/standards/2007-January/013594.html [2]: https://hg.prosody.im/0.10/rev/89c42aff8510
Prosody is following the XEP here. ejabberd is not. We made Prosody follow the XEP more strictly in 0.10, but ejabberd went in the opposite direction.
According to ancient scrolls of wisdom, we removed the fallback becasue ejabberd simply closed the connection when we attempted it, which caused problems. Since then, ejabberd has apparently stopped that. Reverted in https://hg.prosody.im/0.10/rev/e1d274001855 We may add a switch to turn this on or off.
ChangesI am still getting this problem in 0.10.1 May 30 19:56:35 s2sout55ae79cfd880 info Stream encrypted (TLSv1.2 with AES256-GCM-SHA384) May 30 19:56:35 xmpp.is:saslauth info SASL EXTERNAL with exploit.im failed: unknown-condition May 30 19:56:35 s2sout55ae79cfd880 info Outgoing s2s stream xmpp.is->exploit.im closed: stream closed May 30 19:56:35 s2sout55ae79cfd880 info Sending error replies for 1 queued stanzas because of failed outgoing connection to exploit.im