All queries fails when 'google' is used: ERR_SSL_PROTOCOL_ERROR

Status changed to 'Confirmed' because the bug affects multiple users.

AFAICT this just fails with Google (tried google.com and blogger.com) domains. Can you confirm if you type in ssllabs.com or duckduckgo.com if they work?

I can reproduce on a LiveCD, installing Chromium and then loading it.

I confirmed that downgrading the libnss2 package from 2:3.21-1ubuntu2 to 2:3.19.2.1-0ubuntu0.15.10.1 fixed the issue.

I've only been able to reproduce in Chromium, unable to reproduce in Epiphany, curl, Google Chrome, Pidgin and the ubuntu browser.

@Bryan

like your tests, i get that issue with chromium & midori browsers when google is used:
- no problem with duckduckgo
- no problem with 'ssllabs.com' (http://www. auto-completion works)

- i have not tested with other browsers

so its seems affects 'google' use only

I can't seem to reproduce this. https://www.google.com works fine in an up-to-date image with Chromium and nss 2:3.21-1ubuntu2.

Could you please give the exact steps require to see this issue?

I just tested with the latest image (via testdrive). All I'm doing is, adding universe, installing chromium.
On open the second tab fails to load (guessing it's login to Google), trying google.com or blogger.com also fails.

I can also reproduce in canonistack, Marc and Chad I added your ssh keys to my VM.
ssh ubuntu@10.55.60.217 -Y
then run chromium-browser

Thank you bq.

Hrm, it's error -12218 SSL_ERROR_ENCRYPTION_FAILURE

"Bulk data encryption algorithm failed in selected cipher suite."

Status changed to 'Confirmed' because the bug affects multiple users.

I just noticed this today. AFAICT, it only affects https to www.google.com and other Google subdomains (first noticed on docs.google.com). It does not affect Firefox.

Odder still, I have two fully up-to-date (AFAICT) Xenial machines, both amd64. One of them connects to https://www.google.com just fine, the other produces the error shown here. https to other sites, e.g. Launchpad, gitlab, github, etc. all work fine. No proxies involved, no weird networking setups afaict (I did have bridge networking set up on the failing machine, but disabled that and still had the problem after a reboot). Running chromium in --verbose mode on the console didn't show up anything obvious. I even disabled all plugins and it still had the problem after a browser restart.

But at least I have two systems that are exhibiting different behavior, so maybe that can help debug the issue. I'm at a loss as to what to look at next.

@barry.. Maybe do LiveCD tests on both of them to see if it's a configuration issue or if it might be hardware related.

On Nov 30, 2015, at 08:51 PM, Bryan Quigley wrote:

>@barry.. Maybe do LiveCD tests on both of them to see if it's a
>configuration issue or if it might be hardware related.

I'd be very surprised if it was hardware, but I can try it. I never had this
problem on this machine until this morning's dist-upgrade.

Same error here, and the package downgrade fixes it for now.

Which IPs show the errors? It could be that different results may be due to different TLS terminators at Google. Figuring out one specific IP that demonstrates the issue may help (assuming Google hasn't done something crazy like anycast on their search IPs).

Looks like related to these changes:

nss (2:3.21-1) unstable; urgency=medium

  * New upstream release.
  * nss/lib/ssl/sslsock.c: Disable transitional scheme for SSL renegotiation.
    5 years after the transition started, it shouldn't be necessary anymore.
  * nss/lib/ckfw/builtins/certdata.txt: Remove the SPI CA.
  * nss/lib/util/secload.c: Fix a warning introduced by our patch to this file.
  * debian/libnss3.symbols: Add NSS_3.21 symbol versions.

 -- Mike Hommey <email address hidden> Wed, 25 Nov 2015 09:18:30 +0900

> dino99 (9d9)
> Looks like related to these changes:
> nss (2:3.21-1)

The question is, why the Google Chrome is not affected by this, since it depends on the same library?

OK, a few more notes on reproducing this:

1- I can't reproduce this by installing the daily live cd in a VM
2- I can reproduce it successfully by installing the daily live cd on real hardware

This means it's probably not related to which Google servers are being hit, and is likely hardware-dependent. This matches the behaviour Barry noticed in comment #10.

On the real hardware, where the problem occurs, I see "Fontconfig error: Cannot load default config file" on the console with every character that I type in the URL bar which results in a failed google lookahead search.

@Igor

- chromium is affected, and indeed use the faulty libnss3 package (which works again if libnss3 is downgraded)
- midori is also affected, but does not use libnss3 as a dependency directly; supposing some sub-depency is disturbed

- problem exist with 'google' as the default browser, but not with 'duckduckgo' for example (and possibly with the other search engines)

That system is a 64 bits wily -> xenial installation with 'proposed' archive activated

nss 3.20.1 works, nss 3.21 doesn't.

confirm #19 test above

On Dec 01, 2015, at 01:38 PM, Marc Deslauriers wrote:

>1- I can't reproduce this by installing the daily live cd in a VM
>2- I can reproduce it successfully by installing the daily live cd on real hardware

Confirmed that my working machine is a VM and the busted one is physical
hardware.

@dino99 I can't reproduce this with midori. Are the symptoms identical for you? Are there any midori specific steps?

I couldn't reproduce this issue on Debian sid.

@Bryan

Get the same issue with midori (its confusing as it is not directly depending on libnss3).
The default browser used is 'google'; and i get that issue when:
- i use the 'google' search field
- i type an incomplete part url into the top url bar (without http://www.)

So the steps are identical. When libnss3 is downgraded, midori works again.

Doesn't affect duckduckgo.com etc but only google (sub)domains!

This bug also affects https://te-st.ru

Can somebody reproduce?

I can't reproduce this issue in midori at all.

I can reproduce it with https://te-st.ru

Midori feedback:

my problem was due to something else: after purging then reinstalling it, the problem is gone. Sorry for the noise.

Chromium settings:

chrome://settings (with libnss3 3.21-1ubuntu2)
-> HTTPS/SSL , Manage certificates :
         - your certificates : empty list
         - servers: Global Trustee -> untrusted; Google Ltd -> all untrusted

So if the latest libnss3 version is not faulty, then its a chromium problem, not able to get the good certificates from at least Google Ltd

#29 addon

as a side effect with chromium, the auto translate feature also has stopped working

I tried libnss just now with version 3.21 and it fails consistently. I have downgraded again to 3.19 to keep work going on...
To me, if it's not libnss itself, then it's some weird interaction with the last version of it.

I've tried a newer version of chromium-browser (47) from this ppa:
ppa:canonical-chromium-builds/stage

And it seem to work normally.

The PPA Chromium 47 also fixed it for me.

Confirm that version 47 works here too , even if the issue described above (#29) is still not resolved.
Chad as been asked to upgrade to version 47 ( Bug #1522411 ) , so its a matter of a couple days to get it into xenial archive.

Thanks, Dino !!!

I've been fighting this battle for a few days under Chromium 45 (same as other's problems above - and more).

Upgrading to "47.0.2526.73 (Developer Build) Ubuntu 16.04 (32-bit)" restored my Chromium install to sanity.

Everything appears to work normally now.

version 47 has landed into xenial archive, resolving that issue

chromium-browser (47.0.2526.73-0ubuntu1.1218) xenial; urgency=medium
....
 -- Chad MILLER <email address hidden> Tue, 01 Dec 2015 15:37:11 -0500

(still exist the 'untrusted' certificates (#29) but i does not know if it really matters or not)

The untrusted certificates in comment #29 are normal. They are fraudulent certs that were issued and revoked and are in that list so that they are deliberately marked as untrusted.

It works in chromium 47. But Chromium 47 has other bugs like very jittery scrolling, and slow when maximized under compiz in Xenial. It is basically a development version after all.

BTW, How do I downgrade libnss3? Removing it tries to remove almost all other desktop-packages.

I downloaded the previous package and installed it with 'dpkg -i'. It leaves apt in broken state but keeps things working.

Later, when this is solved, I will fix apt with "apt-get install -f" and continue upgrading

#38 : that was only an issue with chromium 45; so you does not need to downgrade libnss3 now with chromium 47; that issue is solved.

Affected OS: Kubuntu 12.04.05
Affected Browser: Chromium Version 37.0.2062.120 Ubuntu 12.04 (281580)
Affected Domains: 'All things Google'

Downgraded libnss3 from 2:3.21-0ubuntu0.12.04.1 to 3.19.2.1-0ubuntu0.12.04.2
Deinstalled libnss3-1d 2:3.21-0ubuntu0.12.04.1 and depending packages (mostly Java)

Former Internet experience restored

All is well with Chromium Version 48.0.2564.82 Built on Ubuntu 14.04, running on LinuxMint 17.2,
and libnss3 2:3.21-0ubuntu0.14.04.1.

I've noticed a recent pre-release of CB 48 for Precise that is currently marked as "unsafe to use".
I'll wait for the final version before updating libnss3 to 3.21 again.

Dropped Chromium on Kubuntu 12.04.5 __LTS__ and switched to Firefox 44.0.2.

It's just bad practice to let this situation slip. Missing updates for "the browser" far too long and some dubious PPAs with non-compatible packages (GLIBCXX_4.18 not found) is just not bearable.

12.04 LTS (32 & 64 bit) up-to-date Chromium has this problem for me.

I removed Chromium and installed Google Chrome. It works, but is not open source!

Chrome says:

This computer will soon stop receiving Google Chrome updates because this system will be not compatible.

It's the end of 12.04 LTS, https://wiki.ubuntu.com/LTS

Next months, time to migrate to 16.04 LTS...

Concerning Ubuntu 12.04.6-LTS, I ran into the ERR_SSL_PROTOCOL_ERROR consistently withchromium-browser 37.0.2062.120. My comparison attempt with 48.0.2564.109-0ubuntu0.12.04.1.987 (from the Canonical Chromium Builds PPA) terminated on open with the error "/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.18' not found" in triplicate (required by /usr/lib/chromium-browser/chromium-browser, /usr/lib/chromium-browser/libs/libnet.so, and /usr/lib/chromium-browser/libs/libskia.so). I presume this terminate-on-open condition does not affect chromium-browser in 14.04.3-LTS and newer? (I am currently acquiring rebuild hardware in preparation for a 16.04.0-LTS install on my primary rig.)

From the link in [#44](https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1520568/comments/44) I take it that 12.04 LTS will be supported at least until **fall 2017**. I have no intention to upgrade my main machine until then. With all the hickup around CB 37./48. I'd rather live with a slightly slower browser with regular support updates.

This bug was fixed in the package chromium-browser - 37.0.2062.120-0ubuntu0.12.04.2

---------------
chromium-browser (37.0.2062.120-0ubuntu0.12.04.2) precise-security; urgency=medium

  * debian/patches/nss-321-fix.patch: fix compatibility with nss 3.21.
    (LP: #1520568)

 -- Marc Deslauriers <email address hidden> Wed, 24 Feb 2016 13:42:57 -0500

12.04 current

Received .99 image two days ago... add and restart. Received 3 updates... "new" libnss3 + ???... problem is not solved

What version of chromium-browser do you have installed? Is it the version with the fix?

Please type the following in a terminal and paste the results here:

apt-cache policy chromium-browser

Did you restart after updating chromium-browser?

just received a software update today 02/25/2016 their were to chromium updates ( i am runnging ubuntu 12.04 LTS seems to be running ok now