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

 Replying to [comment:17 gagern]:
 > Using TLS in preference to TLS 1.0 is not a bug, as
 [http://tools.ietf.org/html/rfc4346#section-1.1 RFC 4346 section 1.1]
 mentions several security relevant improvements from TLS 1.0 to TLS 1.1.
 Always sending version 1.1 in the client hello is not a bug, as
 [http://tools.ietf.org/html/rfc2246#section-7.4.1.2 RFC 2246 section
 7.4.1.2] states that the client should indicate the highest protocol
 version it can handle. It is up to the server to give a lower protocol
 version in its reply hello, which will then be used for the communication.
 The server closing the connection instead is simply a bug there.

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

 > If you want to have the nss behaviour, you can simply choose to
 indiscrimately disable TLS 1.1 and higher for each and every connection
 established with gnutls. A simple call to
 [http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html#gnutls-
 protocol-set-priority gnutls_protocol_set_priority] in ssl_gnutls_connect
 would do the trick. The danger is that this configuration option would be
 likely to stay in place unrevised for a really long time, making pidgin
 use outdated and insecure protocols for all connections far into the
 future, just because some MSN server right now is buggy.
 >
 > So if you can think of a way to actually enforce revisiting this bug
 here say every year or so, and to check whether the restriction to TLS
 <1.1 is still required, then this might be a viable workaround for now. If
 not, I'm not a pidgin developer so I can't forbid this approach, but I
 would vote against it.

 I wholeheartedly think this is a very Bad Idea (the reasons you outlined
 plus the possibility of discoveries of further exploits in TLS 1.0). Your
 other suggestion (limiting just MSN soap connections) is better.

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