[ejabberd] Psi misbehavior when using latest ejabberd svn version

Zbyszek Żółkiewski zbyszek at toliman.pl
Wed Sep 26 20:38:36 MSD 2007


generally i think in-band registration is not bad, and we should not resign
from it, instead we should find better way of using it.
Maybe it is good idea to hold open socket for particular time and disconnect
user (then client should advise user about that)
after inactivity time...we need discussion here...
For now on my production server i have setup timeout on level of 60 seconds
and i am observing quite good behavior, users have enough time for
registering,
but after one minute they get message "Disconnected" - well Psi would behave
better to display "Sorry, timeout for registration" try again.
But 60s timeout is not enough in other hand to prevent DoS, i am even not
sure if timeout is the right way of fighting DoS, probably better solution
is to load-balance traffic, but
this is not discussion for this topic...

One thing i am sure of: timeouts should be implemented, the question is -
how to deal with in-band registration? Anyone want to join discussion?


On 9/25/07, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>
> > 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
> service.
>
> What do you think?
>
> Peter
>
> > 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
> >> version
> >> To: Mickaël Rémond <mickael.remond at process-one.net >
> >>
> >> here is my answer on Remko post:
> >>
> http://groups.google.com/group/psi-devel/browse_thread/thread/4d884b0b5ed91ae7
> >>
> >> 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
> >> 60s
> >> with should temporary resolve registration issues.
> >> As for the problem, as i write on Psi-devel list it should by held by
> >> the
> >> client - there is no reason (in my opinion) to hold open connection -
> >> even
> >> 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
> >> enabled,
> >> 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
> >> some
> >> kind password-measurement tools, even so - we should not hurry user in
> >> any
> >> situation, after that client reconnect to server, check features again
> >> and
> >> 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
> >> could
> >> > be changed in the middle of a user registration (This is correct for
> a
> >> user
> >> > to change his policy even if the user has retrieved the form to
> create
> >> a
> >> > user).
> >> >
> >> > In my opinion this should be handled by the client displaying the
> >> error
> >> > to the user. There are in any case lots of possible error case (user
> >> exists
> >> > 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/
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> pozdrawiam,
> >> Zbyszek Żółkiewski
> >>
> >> --
> >> pozdrawiam,
> >> Zbyszek Żółkiewski
> >
> >
> >
> >
> > --
> > pozdrawiam,
> > Zbyszek Żółkiewski
> > _______________________________________________
> > ejabberd mailing list
> > ejabberd at jabber.ru
> > http://lists.jabber.ru/mailman/listinfo/ejabberd
> >
>
> _______________________________________________
> ejabberd mailing list
> ejabberd at jabber.ru
> http://lists.jabber.ru/mailman/listinfo/ejabberd
>



-- 
pozdrawiam,
Zbyszek Żółkiewski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jabber.ru/pipermail/ejabberd/attachments/20070926/fdb2182c/attachment-0001.htm 


More information about the ejabberd mailing list