1092701 - Cannot connect to Google Talk

Status: VERIFIED FIXED

(Chat Core :: XMPP, defect)

Description

[Kapil Singh [:kapy]]

Attachment: Capture.PNG

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36

Steps to reproduce:

1) Add a new account.
2) Choose google talk protocol.
3) Set up your account (Enter gmail address and password ).

After the google talk account is set up, it cannot connect.


Actual results:

The google talk account can't be connected.
It shows two errors :
Connection reset by peer.
Server closed the connection.


Expected results:

Google talk account should have connected without any errors.

Comment 1

[Patrick Cloke [:clokep]]

Can you please provide a debug log? Right click on the account in the account manager > Copy debug log.

Comment 2

[Kapil Singh [:kapy]]

Here is the debug log - http://pastebin.mozilla.org/7066839

Comment 3

[Patrick Cloke [:clokep]]

I've started seeing this on the nightly from 20141103041916

Comment 4

[Patrick Cloke [:clokep]]

Attachment: Debug log

The error message from necko is 2152398868 == 0x804b0014, which is  NS_ERROR_NET_RESET (0x804B0014) according to https://developer.mozilla.org/en-US/docs/Table_Of_Errors, that's not very helpful.

Comment 5

[Patrick Cloke [:clokep]]

Bisecting nightlies:

20141031131149 works
20141102041644 does not work

I'll need to try bisecting m-c changes in there.

Comment 6

[Patrick Cloke [:clokep]]

Doh, I forgot to include the m-c and c-c revisions:

20141031131149 works
c-c d59eb3bf90e9ad40ab8194c4d3be9e9aebb7f60c
m-c 4750a2124fa5bc021368605a7cd92b596a5466dd

20141102041644 does not work
c-c 29fb511ba3876d71cea12d601787c11e94abf599
m-c 0e631971b84119f33d2d377512c031227f490d93

254 m-c changesets in there...

Comment 7

[Patrick Cloke [:clokep]]

I had to bisect, then extend and bisect again...eventually I landed on:

changeset:   213353:2c7ca0dc4155
user:        Masatoshi Kimura <[e-mail]>
date:        Wed Oct 22 01:11:29 2014 +0900
summary:     Bug 1088915 - Stop offering RC4 in the first handshakes. r=keeler

Comment 8

[Patrick Cloke [:clokep]]

I just did a local build with 2c7ca0dc4155 backed out and I was able to successfully connect to GTalk. https://www.ssllabs.com/ssltest/analyze.html?d=talk.google.com might be of interest, it seems like ONLY TLS_RSA_WITH_RC4_128_MD5 and TLS_RSA_WITH_RC4_128_SHA are supported. These are now both marked as deprecated, but I can't tell from the comments in bug 1088915 whether we're supposed to "fallback" and still connect or not. (I find the behavior isn't clearly defined in that bug.) I'm hoping emk can provide this information.

Comment 9

[Masatoshi Kimura [:emk]]

I think this is the same problem as bug 1092998 and bug 1092952. We should contact to Google first.

Comment 10

[aleth [:aleth]]

Bug 1088915 says that "the RC4 fallback logic works only if the NSS error code was SSL_ERROR_NO_CYPHER_OVERLAP", but we don't seem to be seeing that error (see above). Is that a (separate) bug?

Comment 11

[Masatoshi Kimura [:emk]]

See bug 1092952 comment #3. A compliant server must return SSL_ERROR_NO_CYPHER_OVERLAP here. In other words, the Google Talk server does not comply the spec.
Although I prepared a patch in case too many servers still require RC4 and do not comply the spec, David Keeler, the PSM owner, decided that we should make an effort to fix incompliant servers before landing the patch (see bug 1092998 comment #4).

Comment 12

[Patrick Cloke [:clokep]]

Earlier today I sent an email to the one contact I have at Google: David Bienvenu. We'll see if he can put me in contact with the right people.

Comment 13

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Hmmm. If Google got this wrong, maybe we do need the workaround in bug 1092998. I'd still like to hear what they say, though.

Comment 14

[Yvan Boily [:ygjb][:yvan]]

FWIW, I have confirmed that a bug was raised referencing this with the XMPP team by Ron Bowes from their security team.  I don't have any tracker information for it though.

Comment 15

[Frederik Braun [:freddy]]

Felix Gröbert, a Googler, said he filed a bug for us. It's internally tracked as number 18309680:

His tweets for reference:
https://twitter.com/fel1x/status/531823796899291136
https://twitter.com/fel1x/status/531859318199812096

Comment 16

[Patrick Cloke [:clokep]]

Yvan / Frederik, have we heard back from any Googlers about the status of this report? Thanks for your help so far! :)

Comment 17

[Frederik Braun [:freddy]]

https://twitter.com/fel1x/status/534809637007413248:
> @freddyb Seems like this will take longer :( Sure you tried all workarounds? https://xmpp.net/result.php?domain=google.com&type=client

Comment 18

[Florian Quèze [:florian]]

(In reply to Frederik Braun [:freddyb] from comment #17)
> Sure you tried all workarounds? https://xmpp.net/result.php?domain=google.com&type=client

I'm not aware of any workaround; is there something I'm missing?

Comment 19

[Patrick Cloke [:clokep]]

(In reply to Frederik Braun [:freddyb] from comment #17)
> https://twitter.com/fel1x/status/534809637007413248:
> > @freddyb Seems like this will take longer :( Sure you tried all workarounds? https://xmpp.net/result.php?domain=google.com&type=client

That link confuses me, we don't connect to google.com, we connect to talk.google.com:
https://xmpp.net/result.php?domain=talk.google.com&type=client (this seems to fail altogether...which is strange...)
https://www.ssllabs.com/ssltest/analyze.html?d=talk.google.com works

Comment 20

[Yuhong Bao]

(In reply to Patrick Cloke [:clokep] from comment #19)
> (In reply to Frederik Braun [:freddyb] from comment #17)
> > https://twitter.com/fel1x/status/534809637007413248:
> > > @freddyb Seems like this will take longer :( Sure you tried all workarounds? https://xmpp.net/result.php?domain=google.com&type=client
> 
> That link confuses me, we don't connect to google.com, we connect to
> talk.google.com:
> https://xmpp.net/result.php?domain=talk.google.com&type=client (this seems
> to fail altogether...which is strange...)
> https://www.ssllabs.com/ssltest/analyze.html?d=talk.google.com works

This is because this is cipher suite mismatch intolerance.

Comment 21

[aleth [:aleth]]

(In reply to Frederik Braun [:freddyb] from comment #17)
> https://twitter.com/fel1x/status/534809637007413248:
> > @freddyb Seems like this will take longer :( Sure you tried all workarounds? https://xmpp.net/result.php?domain=google.com&type=client

We can't use xmpp.google.com or google.com to connect to Google Talk, we need to use talk.google.com, which only offers RC4 (as above). So I am also not aware of any workaround. Is there (or should there be) a way to temporarily whitelist talk.google.com?

Merge day is rapidly approaching (end of this week): if there is no action from Google to fix this, how are we going to handle the problem?

Comment 22

[Frederik Braun [:freddy]]

I didn't understand the suggested workaround myself.
Anyway, the latest reply is
https://twitter.com/fel1x/status/537626534597898241:
> @freddyb still no internal traction on the issue. For us it doesn't look like an easy fix. I'd suggest to whitelist t.g.c for now.

i.e., re-allow RC4 (if only for this domain)

Comment 23

[aleth [:aleth]]

(In reply to Frederik Braun [:freddyb] from comment #22)
> I'd suggest to whitelist t.g.c for now.
> 
> i.e., re-allow RC4 (if only for this domain)

OK, thanks! Does that mean landing the patch referred to by emk in comment #11? What are the next steps to take here?

Comment 24

[Masatoshi Kimura [:emk]]

A sheriff or I will land the patch as soon as the tree reopened. I test the patch locally confirmed that it fixed this bug and bug 1092998.

Comment 25

[aleth [:aleth]]

(In reply to Masatoshi Kimura [:emk] from comment #24)
> A sheriff or I will land the patch as soon as the tree reopened. I test the
> patch locally confirmed that it fixed this bug and bug 1092998.

Thankyou very much!