[Pidgin] #16172: Can't connect to yahoo: A TLS packet with unexpected length was received

[Pidgin]

#16172: Can't connect to yahoo: A TLS packet with unexpected length was received
------------------------------+------------------------
 Reporter:  momo              |       Owner:
     Type:  defect            |      Status:  closed
Milestone:                    |   Component:  libpurple
  Version:  2.10.9            |  Resolution:
 Keywords:  yahoo gnutls tls  |
------------------------------+------------------------

Comment (by xnyhps):

 Taking the discussion from #a16678 here:

 Both GnuTLS and CDSA (Adium's SSL plugin) check whether a TLS connection
 has been closed properly by checking if the server sent a `close_notify`
 alert first. [https://bugzilla.mozilla.org/show_bug.cgi?id=508698 NSS
 doesn't]. If that alert wasn't sent, GnuTLS and CDSA consider it a fatal
 error, which for the HTTPS handler means the response is completely
 discarded. That's what's happening here with Yahoo: their HTTPS server
 closes the connection without sending `close_notify` first.

 The danger of not checking for that alert is that any MitM may cause a
 response to be truncated, yet we'd be unable to tell that it is.

 Is it really an error condition libpurple should consider fatal? I'm not
 entirely sure.

 **XMPP**: Shouldn't do anything with a stanza that is an incomplete XML
 node.
 **IRC**: Probably also doesn't handle packets until a newline is received.
 **HTTPS**: Occasionally resources need to be loaded over HTTPS. Some
 servers don't add a `Content-Length` header (Yahoo here doesn't), which
 means we'd be unable to tell when a HTTP response was maliciously
 truncated. However, as this ticket shows, and what seems to be indicated
 by [https://bugzilla.mozilla.org/show_bug.cgi?id=508698#c4 this comment],
 it is relatively common for HTTPS servers not to `close_notify` properly.
 **Other**: I have no idea what other connections happen over TLS in
 libpurple.

 So in general, I'd expect not too many security implications of ignoring
 this error condition, but I'm not fully convinced of this. Maybe libpurple
 should add a new error code for an uncleanly closed socket, so the HTTPS
 code can deal with it, somehow?

-- 
Ticket URL: <https://developer.pidgin.im/ticket/16172#comment:13>
Pidgin <https://pidgin.im>
Pidgin