[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:  new
Milestone:                            |       Component:  MSN
  Version:  2.2.1                     |      Resolution:     
 Keywords:  gnutls tls handshake msn  |   Launchpad_bug:     
--------------------------------------+-------------------------------------

Comment(by gagern):

 Replying to [comment:20 darkrain42]:
 > In reading [http://tools.ietf.org/html/rfc4346#appendix-E RFC4346 (tls
 1.1) Appendix E] and examining wireshark, I noticed something. The Client
 Hello contains two version fields; one in the SSL Record Layer and one in
 the Client Hello. For tls1.1, both are set to TLS 1.1 (`0x0302`), but
 Appendix E indicates that, for backward-compatibility, the record layer
 SHOULD be version SSL3.0 (`0x0300`, I assume) (and the Client Hello
 version 1.1). My reading is that doing this is the appropriate way to
 support >=SSL3.0 (since Microsoft's server doesn't understand TLS1.1).
 >
 > I may be reading that wrong and I also am not sure that gnutls allows
 what I just described, but I'm going to take a closer look and possibly
 add another test to the cli debug app and test setting the record layer to
 `0x0300` and `0x0301`.

 You are right. I just exported the packet from wireshark, changed the
 record version to 0x0300, and sent it to the server through netcat. The
 server kept the connection and responded with an appropriate server hello,
 establishing SSL 3.0 as the common version to use (which is still strange,
 as it negotiates a TLS 1.0 connection when talked to using the TLS 1.0
 record protocol).

 So now we indeed have what looks like a GnuTLS bug. I stand corrected, and
 acknowledge that this seems to be not (only) the MS server's fault, but a
 GnuTLS thing after all. darkrain42, will you forward this finding to the
 GnuTLS guys?

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