[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:16 khc]:
 > I think we should let gnutls developers know about this, because this
 quite possibly is a legitimate gnutls bug. nss seems to work fine as far
 as I know, and distros tend to ship with compiled packages that use nss. I
 wouldn't mind to have msn require nss and/or some gnutls version that
 actually works.

 From what wiresharking a firefox connection tells me, nss only uses TLS
 1.0 and doesn't even try TLS 1.1. The
 [http://www.mozilla.org/projects/security/pki/nss/overview.html NSS
 overview] doesn't even mention the TLS 1.1
 [http://tools.ietf.org/html/rfc4346 RFC 4346], nor the TLS 1.2
 [http://tools.ietf.org/html/rfc5246 RFC 5246].

 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.

 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.

 On the whole, I see no gnutls bug here at all. You might wish to have
 workarounds for buggs TLS servers as a feature, but I'm not sure if gnutls
 would be the place for this, especially as you can't transparently
 implement this client-side fallback in the current API, since you need to
 re-establish the connection over a new TCP socket.

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