search

redsolution / xabber-android

Open-source XMPP client for Android
http://xabber.com
Other
1.82k stars 815 forks source link

Xabber/Android busy-looping with jabber.otr.im #851

Open ge0rg opened 5 years ago

ge0rg commented 5 years ago

Hi,

There is a busy-loop issue between Xabber/Android and jabber.otr.im, caused by a Xabber user sending a message to a user on jabber.otr.im:

  1. user contacts somebody on jabber.otr.im
  2. jabber.otr.im automatically responds with "For security reasons, OTR encryption is required for conversations on this server"
  3. Xabber automatically responds to that message with a message tagged as private (I have no logs of that one) - maybe a security question/captcha thing?
  4. jabber.otr.im automatically responds with "For security reasons, OTR encryption is required for conversations on this server"
  5. ....

This is going on for hours, with hundreds of thousands of messages exchanged. For a single user, my server has counted 260k of those pingpongs over just three days. This is a huge battery drain for a mobile device and might cause significant costs for mobile data.

The XML of the incoming message that triggers a response is:

<message type='chat' to='*redacted*@yax.im/xabber-android-*redacted*' from='jabber.otr.im'>
  <body>For security reasons, OTR encryption is required for conversations on this server</body>
</message>

I don't know the version of Xabber nor the settings used, as the user isn't currently online.

Please implement a rate-limiting with automatic message responses to prevent those things from happening.

andrewnenakhov commented 5 years ago

Looks like anti-spam filter works as designed. Xabber has an option to enable anti-spam filter on clientside (done by popular user request), and if server opts to spam such user with messages (as it does), it will result in endless loop. Not really sure that it's Xabber that should be fixed with this. Also, a user can disable anti-spam filter in app settings.

Btw, we really don't like it when someone enforces encryption, boo.

ge0rg commented 5 years ago

I'm not arguing against the anti-spam filter, but I'm pretty sure it doesn't need to tell a single JID about the spam 260 THOUSAND times. For example, you could cache the JID you respond to for some minutes to ~1hr, and not reply to each message, but only again after the cache timeout.

Your user doesn't see the traffic, but it eats their battery. And there are more bots out there.

andrewnenakhov commented 5 years ago

@ge0rg but server also does not need to spam user 260 thousand times! (I'd personally stop using such server). Spam filter is not enabled by default, so user brought this on himself, first by using server with a lousy set up, and by enabling anti-spam filter.

I think we'll let this issue be here, until we implement a better solution for a spam problem (limiting bounce back replies is an ok way), but for now we don't have the resources to do anything about it in the near future. Users have 2 workarounds for this problem: they can disable anti-spam filter if that causes some excessive problems with used servers, or they can add jid that is used to spam them to their roster. If it's in roster, filter won't respond with captcha on incoming messages.

ge0rg commented 5 years ago

The user in question is on my lousy server, but they interact with that other lousy server. I've also kindly asked the server admins to implement throttling. The user in question probably didn't even see this message, because the otr.im server obviously can't solve the anti-spam question. So your client feature is badly interacting with automated services, in a way that the user can't even see.

As stated above, the solution is easy: keep a (in-RAM) list of JIDs you sent anti-spam to, and don't send again within a threshold interval. Even with a 10s interval, this would break the busy-loop.

andrewnenakhov commented 5 years ago

Well, since it's your server, I'd probably suggest you not blocking non-encrypted traffic. It's bad practice to interfere with user's data!

Solution is, indeed, simple, but not free. I need to get our developers to switch from urgent tasks they have, get into context, do changes, test results, its hour (at best) of paid work to do properly. So far, we know that one user was affected by this issue, and he can solve this issue in under 10-15 seconds. So it's much more economically viable to leave it be for now, and suggest that one user to use a simple workaround.

ge0rg commented 5 years ago

Please let me try to explain it again, veeeeery sloooooowly:

That means, Xabber is misbehaving here, and this is bad for the user (data traffic, battery), and it is bad for my server (crap in my MAM database, traffic, CPU load). This misbehavior probably happens with all bots / servers that contact the user first.

Now I can not fix Xabber, and I can not fix the XMPP bots. The only solution I can implement is to ban Xabber users from my server (with a reference to this ticket). I'm not sure it is a solution that would please you or your users, and this is not something I want to do. But I want even less to have a broken client impact the service for other users.

P.S: it's nice that you have paid developers who work on your client. I don't have anybody paying me for running the service (or working on my XMPP client), and I still have to manage priorities.

andrewnenakhov commented 5 years ago

@ge0rg well you did quite vaguely explain which server misbehaves, from your previous message I got the impression that it's your server that enforces the encryption. Sorry for misunderstanding.

However, we're still not sure it's Xabber that needs to be urgently fixed, since all user in question has to do is turn off anti-spam filter. As for banning, it's up to you, but I'd rather suggest you ban misbehaving server, since there are way more XMPP servers than different XMPP clients out there, and because such behavior MUST be punished - if server operators chose to enforce encryption and spam not only their own users, but their chat partners from other servers too, they have no excuses and must bear the consequences of their malicious actions.

(that being said, we DO acknowledge this issue, it's just not getting high priority from us. Maybe some other day, eventually)

ge0rg commented 5 years ago

Alright, thanks. I agree that the other server / bot needs to be fixed as well, and I'll check whether I can implement some kind of throttling for them in the mid-term. This issue is not urgent, but I'd really like to see it fixed someday in Xabber. I suppose I got confused by the wontfix label. Thanks very much!

weiss commented 5 years ago

It seems Xabber also auto-responds to type='error' messages?

A user on my server received a message from (presumably) Xabber with the following <body/>:

To many attempts. Try request subscription again to generate new captcha

As the JID of the Xabber user is blocked, my server responded with a type='error' message. It seems this triggered Xabber to send a stand-alone <received/> marker, which resulted in another error from my server. Xabber then responded with the following <body/>:

This user has limited receiving messages from not-authorized users

... and played ping-pong with the resulting error messages.

ge0rg commented 5 years ago

(just noticed I had yet another incident with a Xabber user on my server, playing ping-pong with jabber.otr.im, with 420k messages in the user's MAM archive. Luckily it stopped after ~24hrs, probably because the user's phone battery went empty, or they noticed the huge data / battery drain and killed Xabber)