[Bug 39057] Can't connect to Oracle Jabber server

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39057

--- Comment #16 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #15)
> So, uc-cup2 is the home server but the privacy-cm. prefix entered the stage
> just here.

uc-cup2 is not the home server; that would be "domain" (or possibly
"uc-cup2.domain" if you interpret it that way). Gabble doesn't have any way to
know that "uc-cup2" is under the same administrative control as example.com.

> Therefore a workaround would be much appreciated - especially as other
> clients can do this.

I want to help here, but I also don't want to enable denial of service attacks
(or worse), which is what the spoofing check is intended to prevent.

In this case, if we added an "it's OK if the reply is spoofed" flag and used it
for this query, what an attacker might be able to do is to tell users of other
servers that they can't be invisible, when actually, they can. Not the worst
thing in the world, but not really desirable.

> If I parse that log correctly, this is only about creating an invisible
> list?  So maybe this error could at least gracefully lead to disabling this
> feature or the likes?

We're waiting for the reply to "can I be invisible here?" before sending our
initial presence, so that the initial presence can be invisible if desired. The
reply "came from the wrong place" and was discarded, so we'll never proceed.

One possible workaround would be to put an arbitrary timeout on it: if we don't
get a reply to this question reasonably promptly, carry on regardless. It'll
take you longer to log in than it should, but you'll be able to log in.

A more elaborate workaround would be something like this: assume that the
server will reply to simple stanzas like this in-order. Send the "can I be
invisible?" query, then a different query. If we get a reply to the second
query before we have had a (valid) reply to "can I be invisible?", assume that
the answer is "no, you can't".

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.