[Pidgin] #5910: Jabber - protocol connection for server broken while sending too long buffer over SASL-encrypted channel

[Pidgin]

#5910: Jabber - protocol connection for server broken while sending too long
buffer over SASL-encrypted channel
----------------------+-----------------------------------------------------
  Reporter:  geekkoo  |       Owner:  nwalp                                   
      Type:  patch    |      Status:  new                                     
  Priority:  minor    |   Milestone:                                          
 Component:  XMPP     |     Version:  2.4.1                                   
Resolution:           |    Keywords:  XMPP, Jabber, encryption, security layer
   Pending:  0        |  
----------------------+-----------------------------------------------------
Comment (by geekkoo):

 Replying to [comment:2 datallah]:
 > The proposed behavior change doesn't seem correct at all to me.
 >
 I think this should be in RFC but I can not find it.

 > I also don't understand what is problematic about the current behavior -
 whether or not the message is written in one chunk shouldn't change the
 server's behavior.

 That's true but the server responds right when I repeat messages.

 Once more. I have a Jabberd2 server compiled with Cyrus-SASL support. I
 use GSSAPI mechanism. Cyrus-SASL  with GSSAPI or DIGEST-MD5 mechanisms
 supports security layers (in contrast to default GSASL, which does not
 support security layers). So once SSF was negotiated the client and the
 server agree upon max message length (SASL_MAXOUTBUF). In case of Jabberd2
 it is 1024 (it is jabberd2 limit not pidgin's). So both client and server
 split messages according to this length and encrypt them. Once the message
 can not be send at once by pidgin it is split once more. But jabberd2
 server can not decrypt such broken messages. Here may be two possible ways
 - server waits for the end of the message and concatenates all parts
 together or server waits for the message to be repeated. Jabberd2 seems to
 choose the second case. In the way as the things are now the connection
 just breaks (with short timeout) after such a broken packet is sent to
 server. If I apply my hack the connection survives.

 It is happens regularly in such circumstances (Jabberd2 server, Cyrus-SASL
 and GSSAPI mechanism) when the message length is bigger than 1024 byte -
 for example 6-8kB. The message is lost and after awhile pidgin gets
 disconnected. Brief investigation shows that this happens when the message
 can not be sent at once.

 May be another possibility is to disable SSF negotiation on the server end
 altogether but in that case the encryption will be gone too. Jabberd2
 developers seems to accept patches for Cyrus-SASL although the support for
 it is deprecated.

 I just want some advice how this situation should be handled according to
 protocol specification or how it is handled by other servers (OpenFire for
 example).

-- 
Ticket URL: <http://developer.pidgin.im/ticket/5910#comment:3>
Pidgin <http://pidgin.im>
Pidgin