GNOME Bugzilla – Bug 781854
Cannot access some https sites with epiphany (e.g. google)
Last modified: 2018-05-22 12:05:03 UTC
When I try to access https://www.google.com (or https://www.google.co.uk.), either directly or through the search function, epiphany reports: "This Connection is Not Secure ... This website’s identification was not issued by a trusted organization." This is nonsense. When I test the certificate directly with openssl, it shows that the issuer is "Google Internet Authority G2" ("Google Inc" from "US") as expected. Other browsers (firefox, chrome, midori, ...) have no problem with google. So it seems like epiphany is doing something strange with its certificate checks. I have the following packages (GNOEME 3.24): - epiphany-3.24.1 - glib2-2.52.1 - gtk3-3.22.12 - gnome-shell-3.24.1 - libsoup-2.58.0 - p11-kit-0.23.2 - webkit2gtk3-2.16.0 running under openSUSE 42.2. Thanks.
(In reply to K. Pili from comment #0) > When I try to access https://www.google.com (or https://www.google.co.uk.), > either directly or through the search function, epiphany reports: > "This Connection is Not Secure ... This website’s identification was not > issued by a trusted organization." > > This is nonsense. When I test the certificate directly with openssl, it > shows that the issuer is "Google Internet Authority G2" ("Google Inc" from > "US") as expected. Dude, if there is a MITM attacker, they can name the issuer certificate whatever they want, and would be dumb to choose anything other than "Google Internet Authority G2". > Other browsers (firefox, chrome, midori, ...) have no > problem with google. So it seems like epiphany is doing something strange > with its certificate checks. But this does indeed indicate that it's more likely a problem in the GNOME stack rather than an attacker. I've never heard this reported before and I don't have any guesses, so let's start by getting some more information. Please run the command 'gnutls-cli www.google.com' and paste the full output you see here. (Press Ctrl+D to exit the program.)
This is the output from gnutls-cli: Processed 167 CA certificate(s). Resolving 'www.google.com:443'... Connecting to '172.217.20.100:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=www.google.com,O=Google Inc,L=Mountain View,ST=California,C=US', issuer `CN=Google Internet Authority G2,O=Google Inc,C=US', serial 0x7e98e1a93936ac0b, RSA key 2048 bits, signed using RSA-SHA256, activated `2017-04-21 08:47:28 UTC', expires `2017-07-14 08:26:00 UTC', pin-sha256="LRNyD/oROO0DIOmhWIyQhc+aEMc9VgNXlWRU5sEo/sU=" Public Key ID: sha1:17f76417d73b666d9ffb54b7c0c7b32fcba92547 sha256:2d13720ffa1138ed0320e9a1588c9085cf9a10c73d560357956454e6c128fec5 Public Key PIN: pin-sha256:LRNyD/oROO0DIOmhWIyQhc+aEMc9VgNXlWRU5sEo/sU= Public key's random art: +--[ RSA 2048]----+ | .o| | +| | . . o +| | o.+.*o| | S . oE=*| | . .o.B| | . ooo| | =.+.| | ..+o+| +-----------------+ - Certificate[1] info: - subject `CN=Google Internet Authority G2,O=Google Inc,C=US', issuer `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', serial 0x023a92, RSA key 2048 bits, signed using RSA-SHA256, activated `2015-04-01 00:00:00 UTC', expires `2017-12-31 23:59:59 UTC', pin-sha256="7HIpactkIAq2Y49orFOOQKurWxmmSFZhBCoQYcRhJ3Y=" - Certificate[2] info: - subject `CN=GeoTrust Global CA,O=GeoTrust Inc.,C=US', issuer `OU=Equifax Secure Certificate Authority,O=Equifax,C=US', serial 0x12bbe6, RSA key 2048 bits, signed using RSA-SHA1, activated `2002-05-21 04:00:00 UTC', expires `2018-08-21 04:00:00 UTC', pin-sha256="h6801m+z8v3zbgkRHpq6L29Esgfzhj89C1SyUCOQmqU=" - Status: The certificate is trusted. - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(CHACHA20-POLY1305) - Session ID: CE:70:83:D2:4D:AF:B1:D9:74:18:4C:68:51:73:EB:97:EB:D1:F2:3C:D1:9C:0F:E4:26:09:DD:0F:15:71:BC:2E - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: CHACHA20-POLY1305 - MAC: AEAD - Compression: NULL - Options: extended master secret, safe renegotiation, - Handshake was completed - Simple Client Mode:
That's exactly the same as what I see. It all looks straightforward, so I'm out of ideas. Moving to glib-networking for further review. (I presume you also have glib-networking 2.50.0, judging by the other version numbers?)
Also it would be good to know if other openSUSE users can reproduce this issue, as CA certificates packages tend to have distro-specific bugs. (But since GnuTLS accepts the chain, that's a bit less-likely here.)
DimStar: mcatanzaro: don't have a Leap 42.2 setup around; tested on Tumbleweed and can access https://www.google.com without issues mcatanzaro: DimStar: OK... has that user enabled GNOME:Factory or some other custom repo? He has really new packages, all GNOME 3.24 stuff. DimStar: mcatanzaro: but then, we never released GNOME 3.24 for Leap 42.2 - so I can't say what kind of mess the user must have in his repo setup DimStar: mcatanzaro: neither GNOME:Factory nor GNOME:Next have a 42.2 build target enabled I'm going to put this back into NEEDINFO state... can you reproduce this issue on a fresh OS install with some supported combination of packages (e.g. openSUSE 42.2 or Tumbleweed with no extra repos enabled)? I'm well aware of the different sorts of bugs that can occur when you start enabling extra repos in openSUSE distros.
Just to add a couple of packages that might be interfering, I have: - glib-networking-2.50.0 - glib-openssl-2.50.2 All my GNOME are compiled from source in GNOME:Factory openSUSE repositories.
OK, I have tried a couple of experiments to try to narrow the problem: Firstly, in a different partition with pure openSUSE 42.2, I installed epiphany-3.20.3. Initially, I got errors lie "Oops! This page is not displaying properly .." on sites like yahoo and google. However, other https sites (e.g. gnome.org) worked well. So I deleted my .config and .local files and after a couple of logout/in rounds, I finally managed to get to google and yahoo. The problem seemed to be with the search functionality because even when I got into google and searched for yahoo finance, the link generated would fail to load. So that particular setup now works. I went back to my main partitions and downgraded to epiphany-3.20.3, but retaining some GNOME 3.24 apps. The behaviour is practically the same as that of epiphany-3.24, i.e. it will not load google.com or yahoo.com. It is trying to redirect the browser to google.co.uk, etc. Once again. gnome.org and other https sites work well. It is just these search websites (yahoo.com and google.com) that present problems when they are redirected automatically. Now interestingly, yahoo.co.uk works if accessed directly, but google.co.uk does not. I think it is probably a google certificate that epiphany is using that is different from the one used by firefox, etc. Where does epiphany read certificates from? How can I get it to use the firefox certificate store?
(In reply to K. Pili from comment #6) > Just to add a couple of packages that might be interfering, I have: > - glib-networking-2.50.0 > - glib-openssl-2.50.2 Does it work if you uninstall glib-openssl? If so, close this bug as NOTGNOME and report a bug against that.
Oh *wow*, I had no clue that was a separate module and now packaged by distros... good catch Dan. Does it really not have a Bugzilla product here, since it's packaged by GNOME now? (In reply to K. Pili from comment #7) > I think it is probably a google certificate that epiphany is using that is > different from the one used by firefox, etc. Where does epiphany read > certificates from? How can I get it to use the firefox certificate store? Well there are two answers to this question. The normal answer that I give is that it uses your system trust store, wherever that is on openSUSE. On Fedora it's under /etc/pki. The layers here are normally Epiphany -> WebKit -> libsoup -> GLib -> glib-networking -> GnuTLS. However, it looks like you have installed a different GLib networking backend that uses OpenSSL instead of GnuTLS. There's nothing wrong with doing that -- GLib is designed to let you replace the entire networking backend -- but we can't possibly support it when you find bugs, as you have a totally different TLS stack now. The layers you are using are Epiphany -> WebKit -> libsoup -> glib -> glib-openssl -> OpenSSL. So TLS-related bug reports need to be directed to the glib-openssl project.
It has a Bugzilla product. :)
(In reply to Michael Catanzaro from comment #10) > It has a Bugzilla product. :) It really shouldn't. My understanding when glib-openssl was created was that it was going to be made very clear that it was NOT supported by GNOME (and that ordinary users were not expected to install it under any circumstances; it exists only for weirdo embedded and other custom use cases).
Well it is what does a project part of gnome? 2 gnome devs maintaining should do it :)
A very abbreviated version of what just happened on IRC: mcatanzaro: Basically my concern is that people will install this package thinking "oh it's a GNOME thing, might as well", it breaks epiphany -> people think epiphany is bad danw: glib-openssl was not intended to be used by ordinary users. it was intended only for use in weirdo custom cases like embedded systems DimStar: danw: fair enough: I'll drop the module from Tumbleweed mcatanzaro: DimStar: Thank you!
BTW the point of this module, to my understanding, is to avoid having GnuTLS installed at all. This is a problem for some companies because GnuTLS depends on software that is licensed (GPLv2+ or LGPLv3+), which is unacceptable to some companies. That's not a problem for desktop users.
I'll try to fix this during the upcoming days... I wonder why this is not catched by the unit tests though.
Well, indeed glib-openssl was the problem. I removed it and now I get to google without a problem. Thanks a lot for the tips.
Let's make something clear, glib-openssl resides in the GNOME infrastructure. So I am reopening this and I will get it fixed.
Created attachment 350715 [details] [review] filedatabase: rework the verification of the chain
I am not able to reproduce this problem with epiphany 3.18. Any chance you could try out this patch?
Do you mean patch epiphany 3.24 and reinstall glib-openssl?
Just to report back, I applied the patch to glib-openssl-2.50.2 and reinstalled with epiphany-3.24.1. This seems to have solved the problems I had with google.com. For completeness, I should also say that I had already replaced mozilla-nss-certs with p11-kit-nss-trust before this - I am not sure if this has any relevance at all. Those packages have a single file: libnssckbi.so. Thanks.
Thanks a lot for testing it. I just pushed the patch upstream and I will make a new release soon.
I just tested this on fedora 25 and I am able to reproduce the problem even with this patch applied.
I managed to reproduce this problem using the openssl command directly: openssl verify -CAfile /etc/pki/tls/certs/ca-bundle.crt ~/Downloads/\*googlecom.crt /home/nacho/Downloads/*googlecom.crt: C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com error 20 at 0 depth lookup:unable to get local issuer certificate
I retested epiphany with the patched glib-openssl and it still works for me. I suppose that my certificate bundle is different (/etc/ssl/ca-bundle.pem). I also used a tool, testssl (https://testssl.sh/) and it reports no errors in google.com. Lastly, the output of "openssl s_client -showcerts -connect www.google.com:443" is: CONNECTED(00000003) depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = www.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 ... --- Server certificate subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2 --- ...
What if you try again without the patch? Do you get the problem again?
Without the patch, the problem recurs as before. With the patch, I get through without a problem. So, from my perspective, the patch does definitely solve the particular issue.
OK, thanks for the testing. I'll keep the bug opened for now until I figure out the problem I've found with my own system.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib-openssl/issues/1.