sonnyp
March 14, 2021, 10:14pm
1
Hello,
I am the author and maintainer of xmpp.js, a popular multi-platform JavaScript library for XMPP. A user opened an issue about being unable to use xmpp.js with OpenFire.
See https://github.com/xmppjs/xmpp.js/issues/889
I was able to reproduce the issue with starttls and direct tls but not with secure websocket. Here is a small reproduce test case.
I don’t use Openfire myself and I have limited time to dedicate to this, any help would be appreciated.
npm install @xmpp/client
NODE_TLS_REJECT_UNAUTHORIZED=0 node openfire.js
// openfire.js
const { client, xml } = require("@xmpp/client");
const xmpp = client({
// direct TLS - affected
// service: "xmpps://localhost:5223",
// starttls - affected
service: "xmpp://localhost:5222",
// plain websocket - not affected
// service: "ws://localhost:7070/ws",
// secure websocket - not affected
// service: "xmpp://localhost:744/ws",
domain: "localhost",
resource: "example",
username: "admin",
password: "*****",
});
xmpp.on("output", (data) => console.log("output\n", data));
xmpp.on("input", (data) => console.log("input\n", data));
xmpp.on("status", (status) => console.log("status", status));
xmpp.on("error", (err) => {
console.error(err);
});
xmpp.on("offline", () => {
console.log("offline");
});
xmpp.on("online", async (address) => {
console.log("online as", address.toString());
await xmpp.stop();
});
xmpp.start().catch(console.error);
3 Likes
Mike90
August 19, 2021, 2:16pm
2
I’m having the same issue. Has anyone been able to look into this?
Mike90
August 19, 2021, 8:33pm
3
After debugging this for a while, I found that disabling TLSv1.3 in Openfire seems to solve the issue. But with TLSv1.3 enabled, it doesn’t work (neither with Java11 nor with Java8, so JVM version doesn’t seem to matter). Hope this might help someone willing to research this
I think this is a known problem if you are using Openfire with Java 11.
Mike90
August 20, 2021, 1:25pm
5
Thanks for the reply!
Do you have any reference about the problem I could read up on?
I tried using Java 8 yesterday, but it behaved the same.
I managed to find a workaround in the client though. You can refer to my debugging result here:
opened 03:26PM - 14 Mar 21 UTC
**Describe the bug**
Same issue as #592 when using starttls
**Client Code**
…
```
this._client = client({
service: 'xmpp://example.com:5222',
resource: "some-resource",
username: 'ANONYMOUS',
});
```
**Logs**
```
status connecting xmpp://example.com:5222
status connect
status opening
status open <stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="example.com" id="1khlg8il52" xml:lang="en" version="1.0"/>
IN
<stream:features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/><mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>ANONYMOUS</mechanism></mechanisms><compression xmlns="http://jabber.org/features/compress"><method>zlib</method></compression><ver xmlns="urn:xmpp:features:rosterver"/><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="https://www.igniterealtime.org/projects/openfire/" ver="JiSz8RBGEqqFfx+GUdpJNXragQo="/></stream:features>
OUT
<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
IN
<proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>
status opening
TimeoutError
at Timeout.<anonymous> (/node_modules/@xmpp/events/lib/promise.js:33:16)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
TimeoutError
at Timeout.<anonymous> (/node_modules/@xmpp/events/lib/promise.js:33:16)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
(node:85777) UnhandledPromiseRejectionWarning: TimeoutError
at Timeout.<anonymous> (/node_modules/@xmpp/events/lib/promise.js:33:16)
at listOnTimeout (internal/timers.js:549:17)
at processTimers (internal/timers.js:492:7)
```
**Environment**
node v12.18.3
@xmpp/client v0.12.0
Server: Openfire 4.6.2, build b61bce3, configured with a valid TLS certificate for the domain I'm using.
OS: macOS Catalina 10.15.7
As an additional note: when I connect Adium to that Openfire server, it also takes quite some time (~ 10-30sec) to establish the connection. I suppose this has to do with TLS checking / negotiation / whatever. Maybe the expected timeout just has to be raised?
If there’s a better explanation somewhere on why this happens exactly, I’d be really thankful to learn about it!
guus
May 5, 2022, 4:20pm
6
Apologies for being so late to the party, but I believe I might have identified the cause and a potential fix for this.
@sonnyp ’s comment that this affects only certain endpoints, but not others, made me suspect the third-party library that we use for exactly those endpoints. We are using Apache MINA for those endpoints.
After discussing the issue within that community, they have asked me to test against a new implementation (as of yet unreleased). Again, using Sonny’s reproduction path, I was able to confirm that the problem seems to be gone when using that updated third party library.
We probably need to update to a new version of MINA to resolve this issue.
I have raised a new ticket to track this change: [OF-2435] - Ignite Realtime Jira
2 Likes