#16172 closed defect (fixed)
Can't connect to yahoo: A TLS packet with unexpected length was received
Reported by: | momo | Owned by: | |
---|---|---|---|
Milestone: | 2.10.10 | Component: | libpurple |
Version: | 2.10.9 | Keywords: | yahoo gnutls tls |
Cc: | rwky, andrei.mihaila, robert74, djberriman, bertocci, sagi, bberberov |
Description
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)
Attachments (1)
Change History (17)
comment:1 Changed 5 years ago by stelardactek
comment:2 Changed 5 years ago by 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.
comment:3 in reply to: ↑ description Changed 5 years ago by 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
comment:4 Changed 5 years ago by 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
comment:5 Changed 5 years ago by robert74
I am also getting the error "Error reading from login.yahoo.com: Input/output error" for the last couple of days.
comment:6 Changed 5 years ago by datallah
- Status changed from new to pending
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
comment:7 Changed 5 years ago by 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
comment:8 Changed 5 years ago by 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.
comment:9 Changed 5 years ago by 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...
comment:10 Changed 5 years ago by djberriman
debug log attached to ticket from my libpurple based client.
comment:11 Changed 5 years ago by trac-robot
- Status changed from pending to closed
This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.
comment:12 Changed 5 years ago by spradnyesh
Not fixed; i am still facing this issue
comment:13 Changed 5 years ago 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. 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?
comment:14 Changed 5 years ago by Robby
- Status changed from closed to new
comment:15 Changed 5 years ago by MarkDoliner
- Milestone set to 2.10.10
- Resolution set to fixed
- Status changed from new to closed
Just submitted 42ba908c25c7 which fixes this.
comment:16 Changed 5 years ago by 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.
I have also been getting this error since the 28th of March.