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

Comment(by gagern):

 New insights gained using wireshark: 65.54.170.19 doesn't like TLS 1.1.
 When confronted with a TLS 1.1 client hello, it immediately terminates the
 TCP connection.

 You can use gnutls-cli-debug to have a look at the features and protocols
 the host supports. You will notice that fallback from TLS 1.1 to 1.0 seems
 to be broken:
 {{{
 $ gnutls-cli-debug -p 443 65.54.170.19
 Resolving '65.54.170.19'...
 Connecting to '65.54.170.19:443'...
 Checking for TLS 1.1 support... no
 Checking fallback from TLS 1.1 to... failed
 Checking for TLS 1.0 support... yes
 Checking for SSL 3.0 support... yes
 Checking for HTTPS server name... not checked
 Checking for version rollback bug in RSA PMS... no
 Checking for version rollback bug in Client Hello... yes
 Checking whether we need to disable TLS 1.0... N/A
 Checking whether the server ignores the RSA PMS version... yes
 Checking whether the server can accept Hello Extensions... yes
 Checking whether the server can accept cipher suites not in SSL 3.0
 spec... yes
 Checking whether the server can accept a bogus TLS record version in the
 client hello... no
 Checking for certificate information... N/A
 Checking for trusted CAs... N/A
 Checking whether the server understands TLS closure alerts... partially
 Checking whether the server supports session resumption... yes
 Checking for export-grade ciphersuite support... yes
 Checking RSA-export ciphersuite info... N/A
 Checking for anonymous authentication support... no
 Checking anonymous Diffie Hellman group info... N/A
 Checking for ephemeral Diffie Hellman support... yes
 Checking ephemeral Diffie Hellman group info... N/A
 Checking for AES cipher support (TLS extension)... yes
 Checking for CAMELLIA cipher support (TLS extension)... no
 Checking for 3DES cipher support... no
 Checking for ARCFOUR 128 cipher support... yes
 Checking for ARCFOUR 40 cipher support... yes
 Checking for MD5 MAC support... yes
 Checking for SHA1 MAC support... yes
 Checking for ZLIB compression support (TLS extension)... no
 Checking for LZO compression support (GnuTLS extension)... no
 Checking for max record size (TLS extension)... no
 Checking for SRP authentication support (TLS extension)... yes
 Checking for OpenPGP authentication support (TLS extension)... no
 }}}

 You can then simulate the way pisgin probably connects:
 {{{
 $ gnutls-cli -p 443 65.54.170.19
 Resolving '65.54.170.19'...
 Connecting to '65.54.170.19:443'...
 *** Fatal error: A TLS packet with unexpected length was received.
 *** Handshake has failed
 GNUTLS ERROR: A TLS packet with unexpected length was received.
 }}}

 By restricting the protocol to TLS version 1.0 and thus disallowing 1.1,
 you can get a successful handshake:
 {{{
 $ gnutls-cli --protocols TLS1.0 -p 443 65.54.170.19
 This method of specifying algorithms is deprecated. Please use the
 --priority option.
 Resolving '65.54.170.19'...
 Connecting to '65.54.170.19:443'...
 - Certificate type: X.509
  - Got a certificate list of 3 certificates.

  - Certificate[0] info:
  # The hostname in the certificate does NOT match '65.54.170.19'.
 }}}

 So there now are several possible solutions to this whole mess:
  1. Bug MS to install a proper TLS implementation on 65.54.170.19
  2. Disable TLS 1.1 for this connection for the time being
  3. Try 1.1 but fall back to TLS 1.0 in pidgin code whenever this issue
 turns up

 I've got the feeling that the last option might make the most sense.
 Haven't yet looked at the GnuTLS API to figure out how to achieve this
 protocol restriction.

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