[ejabberd] Psi misbehavior when using latest ejabberd svn version
stpeter at stpeter.im
Tue Sep 25 19:38:20 MSD 2007
> so the discussion went to dead end? maybe we need some XEP-best practices
> regarding client behavior - if there isn't already...Peter what you think?
I think there are conflicting interests here. In the early days, it was
fine to leave the connection open and wait for the user to register or
authenticate. Now there are large jabber services deployed and the admins
legitimately worry about DoS attacks (we recently changed the timeout at
jabber.org and now I can't use the telnet client!). On the other hand if
we deploy more sophisticated in-band registration techniques (with
CAPTCHAs and so on), then end users will take even more time to register
in-band. It's easy to say "oh well, big jabber services should force
people to register via the Web" but there are deployment issues involved
(e.g. no one has developed a good web-registration system for ejabberd and
other servers, and the web server may not be connected to the jabber
server at all, which is our situation at jabber.org). I don't see any
special reason why we should force people to register via HTTP instead of
developing smarter ways to register via XMPP.
I don't yet have a solution. I don't want people to DoS jabber.org,
believe me! But I also would like to retain (a smarter version of) in-band
registration. Could we develop a way for the client to tell the server
"I'm working on it, please give me 10 seconds" or whatever? What is the
exact attack we're concerned about? I think that if we make the DoS attack
more resource-intensive then it would become less appealing. So perhaps
the server could challenge the client to perform some resource-intensive
operation (as is done in hashcash) in order to keep the unauthenticated
connection open for a little while. Presumably someone who wants to
perform a DoS would find that unfriendly and move on to attack a different
What do you think?
> On 9/24/07, Zbyszek Å»Ã³Åkiewski <zbyszek at toliman.pl> wrote:
>> sorry, mail not went to all..resending..
>> ---------- Forwarded message ----------
>> From: Zbyszek Å»Ã³Åkiewski <zbyszek at toliman.pl >
>> Date: Sep 24, 2007 12:09 PM
>> Subject: Re: [ejabberd] Psi misbehavior when using latest ejabberd svn
>> To: MickaÃ«l RÃ©mond <mickael.remond at process-one.net >
>> here is my answer on Remko post:
>> the problem seams to be bigger - i thin Gajim(svn) also uses the same
>> technique as Psi - not tested but some user reports say that there are
>> problems with registering account.
>> For now i have changed default timeout in ejabberd_c2s.erl from 5s to
>> with should temporary resolve registration issues.
>> As for the problem, as i write on Psi-devel list it should by held by
>> client - there is no reason (in my opinion) to hold open connection -
>> when policy will change - user will not be registered, so reassuming, 2
>> stages for client (can be shorten to only one stage)
>> 1) select server, and check features (if in-band registration is
>> if not advise user), disconnect
>> 2) user selects username and password - this can be long as users may
>> selecting user and password longer time - also some clients may provide
>> kind password-measurement tools, even so - we should not hurry user in
>> situation, after that client reconnect to server, check features again
>> if policy have hanged, advise user, register account if no other errors
>> occur, disconnect.
>> i think this is most simple solution for that problem.
>> On 9/24/07, MickaÃ«l RÃ©mond < mickael.remond at process-one.net > wrote:
>> > Hello,
>> > I agree with you. Psi should not open a connection that is kept into
>> > unauthenticated state too long.
>> > Your solution posted on Psi mailing list seems correct.
>> > However, Remko points is correct too. In very rare case, you could try
>> > to push a form that has changed or rejecting registration because it
>> is not
>> > more authorized.
>> > Avoidting timeouts does not make the situation better however. In
>> > ejabberd, you can change the policy without restarting the server). It
>> > be changed in the middle of a user registration (This is correct for a
>> > to change his policy even if the user has retrieved the form to create
>> > user).
>> > In my opinion this should be handled by the client displaying the
>> > to the user. There are in any case lots of possible error case (user
>> > for example, missing mandatory field), it could be unauthorized
>> creation or
>> > missing field.
>> > Please, let me know if you disagree.
>> > Cheers,
>> > --
>> > MickaÃ«l RÃ©mond
>> > http://www.process-one.net/
>> Zbyszek Å»Ã³Åkiewski
>> Zbyszek Å»Ã³Åkiewski
> Zbyszek Å»Ã³Åkiewski
> ejabberd mailing list
> ejabberd at jabber.ru
More information about the ejabberd