[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 datallah):

 Replying to [comment:3 geekkoo]:
 > 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.

 I'm with you until here, everything so far makes sense.

 > 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.

 This doesn't seem at all correct - there is no guarantee that even if the
 client sends stuff in one chunk that the server will be able to read it in
 the same way.

 > 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.

 I think that this appears to work is something of a coincidence - it
 sounds like a server bug.

 There is no provision for this type of thing that I can see in the RFC -
 it wouldn't make much sense.

 > 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).

 As I mentioned above, I see nothing in the RFC that indicates resending is
 a reasonable thing to do.
 I have no idea how it is handled by OpenFire, you'd have to ask the
 OpenFire people or look at the source.

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