Can't connect to yahoo: A TLS packet with unexpected length was received

[momo]

The relevant debug log:

libpurple/gnutls: Serial: 25:0c:e8:e0:30:61:2e:9f:2b:89:f7:05:4d:7c:f8:fd                                                                                                                                                                                                  │
libpurple/gnutls: Cert DN: C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=(c) 2006 VeriSign\, Inc. - For authorized use only,CN=VeriSign Class 3 Public Primary Certification Authority - G5                                                                          │
libpurple/gnutls: Cert Issuer DN: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority                                                                                                                                                                 │
libpurple/certificate/x509/tls_cached: Starting verify for login.yahoo.com                                                                                                                                                                                                 │
libpurple/certificate/x509/tls_cached: Checking for cached cert...                                                                                                                                                                                                         │
libpurple/certificate/x509/tls_cached: ...Found cached cert                                                                                                                                                                                                                │
libpurple/gnutls: Attempting to load X.509 certificate from certificates/x509/tls_peers/login.yahoo.com                                                                                                                                             │
libpurple/certificate/x509/tls_cached: Peer cert matched cached                                                                                                                                                                                                            │
libpurple/util: Writing file certificates/x509/tls_peers/login.yahoo.com                                                                                                                                                                            │
libpurple/certificate: Successfully verified certificate for login.yahoo.com                                                                                                                                                                                               │
libpurple/util: request constructed                                                                                                                                                                                                                                        │
libpurple/util: Response headers: 'HTTP/1.1 200 OK␍                                                                                                                                                                                                                        │
Date: Sun, 23 Mar 2014 16:45:33 GMT␍                                                                                                                                                                                                                                       │
Set-Cookie: B=c2ngvmp9iu3td&b=3&s=kq; expires=Wed, 23-Mar-2016 16:45:33 GMT; path=/; domain=.yahoo.com␍                                                                                                                                                                    │
P3P: policyref="http://info.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV"␍                                                    │
Cache-Control: private␍                                                                                                                                                                                                                                                    │
Pragma: no-cache␍                                                                                                                                                                                                                                                          │
Expires: Thu, 05 Jan 1995 22:00:00 GMT␍                                                                                                                                                                                                                                    │
Vary: Accept-Encoding␍                                                                                                                                                                                                                                                     │
Content-Type: text/html␍                                                                                                                                                                                                                                                   │
Age: 0␍                                                                                                                                                                                                                                                                    │
Connection: close␍                                                                                                                                                                                                                                                         │
Server: ATS␍                                                                                                                                                                                                                                                               │
␍                                                                                                                                                                                                                                                                          │
'                                                                                                                                                                                                                                                                          │
libpurple/gnutls: receive failed: A TLS packet with unexpected length was received.                                                                                                                                                                                        │
libpurple/yahoo: Authentication: In yahoo_auth16_stage1_cb                                                                                                                                                                                                                 │
libpurple/yahoo: Login Failed, unable to retrieve login url: Error reading from login.yahoo.com: Input/output error                                                                                                                                                        │
libpurple/connection: Connection error on 0x8cd49f8 (reason: 0 description: Error reading from login.yahoo.com: Input/output error) 

[stelardactek]

I have also been getting this error since the 28th of March.

[bjh]

I'm getting the same since yesterday (March 29) - verified for 3 Yahoo accounts - tried to play a bit with the server names, IPs with no success. No problems with AIM, ICQ or Google accounts. The Yahoo accounts are all right when I use them with Kopete.

[lucian80]

Same error, same date, March 28th.

Very important error I think as nobody can use yahoo messenger any more on pidgin.

(00:51:11) gnutls: receive failed: A TLS packet with unexpected length was received. (00:51:11) yahoo: Authentication: In yahoo_auth16_stage1_cb (00:51:11) yahoo: Login Failed, unable to retrieve login url: Error reading from login.yahoo.com: Input/output error

[andrei.mihaila]

Getting the same error ("Error reading from login.yahoo.com: Input/output error") starting from about the same date with a very similar cause:

(11:05:47) gnutls: receive failed: The TLS connection was non-properly terminated.
(11:05:47) yahoo: Authentication: In yahoo_auth16_stage1_cb
(11:05:47) yahoo: Login Failed, unable to retrieve login url: Error reading from login.yahoo.com: Input/output error

[robert74]

I am also getting the error "Error reading from login.yahoo.com: Input/output error" for the last couple of days.

[datallah]

Please follow the instructions to get a debug log and attach it to this ticket.
This has been confirmed to be an issue when using the gnutls ssl implementation - it appears to work fine when the NSS implementation is used - a full debug log may be useful, along with the output of gnutls-cli-debug -V -p 443 login.yahoo.com

[datallah]

Also, set the PURPLE_GNUTLS_DEBUG environment variable to 9 to get more debug output (quit pidgin and then start it from a terminal):

export PURPLE_GNUTLS_DEBUG=9
pidgin -d > /tmp/debug.log

[djberriman]

Workaround for this issue.

Ensure you have nspr-devel and nss-devel installed (on fedora at least).

Configure pidgin without gnutls (--enable-gnutls=no), check the output of the configure command to confirm the SSL library is just Mozilla NSS

Make and install pigdin

Finally ensure you remove the gnutls libraries otherwise they will still be used by pidgin/libpurple

rm /usr/lib/purple-2/ssl-gnu*

Everything should now work as long as your account isn't locked out from login failures.

[djberriman]

debug log of gnutls session

[djberriman]

gnutls-cli-debug -V -p 443 login.yahoo.com Resolving 'login.yahoo.com'... Connecting to '217.146.186.54:443'... Error in %INITIAL_SAFE_RENEGOTIATION Checking for Safe renegotiation support...

[djberriman]

debug log attached to ticket from my libpurple based client.

[trac-robot]

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

[spradnyesh]

Not fixed; i am still facing this issue

[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. ​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 ​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?

[MarkDoliner]

Just submitted 42ba908c25c7 which fixes this.

[MarkDoliner]

Also, thanks xnyhps for typing all that info! Super useful. I think it's fine to not require close_notify, and that's the change I made.

Coincidentally we talked about this problem briefly on devel@… when Tomasz implemented his new http code. Email subject was "SSL compatibility mode," from Oct and Nov 2012 and March 2013. You can also find the email by searching for GNUTLS_E_PREMATURE_TERMINATION.