[Pidgin] #3456: TLS handshake error(unexpected length packet) when recieving MSN contact list

[Pidgin]

#3456: TLS handshake error(unexpected length packet) when recieving MSN contact
list
--------------------------------------+-------------------------------------
 Reporter:  bsdunx                    |           Owner:  khc   
     Type:  defect                    |          Status:  closed
Milestone:  2.5.5                     |       Component:  MSN   
  Version:  2.2.1                     |      Resolution:  fixed 
 Keywords:  gnutls tls handshake msn  |   Launchpad_bug:        
--------------------------------------+-------------------------------------

Comment(by gagern):

 Replying to [comment:26 khc]:
 > For the latter, is that what nss does (and which is why it seems to work
 better at least in this case)?

 Don't think so. As mentioned in comment:17, NSS doesn't support TLS 1.1 at
 all, so even if it sends its highest supported record version, 1.0, that
 will be accepted by the server. Once NSS does support TLS 1.1 we will have
 to see what its default behaviour is then, and whether we need workarounds
 for specific hosts there as well.

 > I'd rather really prefer that our ssl plugins abstract out the backend
 differences instead of having a flag that's useful only in some cases.

 Problem is that hosts might be broken in both directions, which is the
 reason for the GnuTLS default behaviour in the first place. If we have to
 deal with both kinds of broken servers, we need some kind of flag to
 determine what workaround we use, or a rather elaborate automatic fallback
 mechanism.

 > I am going to checkin the second patch, other developers who are more
 well versed in ssl than I am feel free to decide otherwise.

 I'd say test that, see if it works. If any problems turn up in other
 protocols, where the SSL 3.0 record version causes trouble, revert that
 patch and apply the other instead.

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