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.

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

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

I've started seeing this on the nightly from 20141103041916

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.

Bisecting nightlies: 20141031131149 works 20141102041644 does not work I'll need to try bisecting m-c changes in there.

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...

I had to bisect, then extend and bisect again...eventually I landed on: changeset: 213353:2c7ca0dc4155 user: Masatoshi Kimura <VYV03354@nifty.ne.jp> date: Wed Oct 22 01:11:29 2014 +0900 summary: Bug 1088915 - Stop offering RC4 in the first handshakes. r=keeler

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.

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

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?

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).

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.

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.

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.

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

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

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

(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?

(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

(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.

(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?

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)

(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?

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.

(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!