GNOME Bugzilla – Bug 735365
Epiphany fails to render facebook properly
Last modified: 2014-08-29 07:52:45 UTC
Created attachment 284383 [details] Facebook not rendered correctly I compiled epiphany in commit 8d8b38a and WebKit 2.5.3. It seems to fail to render facebook properly as it had a problem with getting or rendering with CSS.
I forgot to say that this works perfectly in WebKit trunk with Minibrowser
I guess the code that removes garbage from the URLs might be breaking the CSS urls. Could you try again with the do not track setting disabled?
Looks awfully similar to bug #735350.
Created attachment 284584 [details] Do not track disabled
In the second screenshot I show how I had the do not track disabled (actually it was already like that) and I still have the same problem with Facebook. Please let me know if I need to do something else.
Then it's not the code that removes garbage from urls.
It seems it has to do with the TLS stuff, if you open the inspector and tries to see the resources it says: Failed to load resource: Unacceptable TLS certificate. The thing is that when running epiphany -p it works.
It seems the difference has to do with the URL used for resources, for example, this one: https://fbstatic-a.akamaihd.net/rsrc.php/v2/yL/r/x3bsMJyVkPp.css fails with invalid certificate error, while https://static.xx.fbcdn.net/rsrc.php/v2/yy/r/FxODjpqnjep.css works. The first url works in firefox and chromium, even if the CA is unknown. Should we accept certificates with an unknown CA?
Can you please install the gnutls-bin (Debian) or gnutls-tools (Fedora) package and paste the output of 'gnutls-cli fbstatic-a.akamaihd.net'? I have a complete chain of trust rooted in GTE CyberTrust Global Root, and it doesn't seem plausible that you'd be missing that. I'm also researching how Firefox handles insecure CSS. When it loads CSS over HTTP from an HTTPS page Firefox will definitely block it (we should but don't -- yet); I thought when it loaded CSS over HTTPS from an invalid certificate it would be blocked silently (which is what we do, and I thought I had tested this in Firefox too).
Actually, I think I see what's happening: that is secure CSS with a good chain of trust, I have no security level lock in the address bar: WebKit either did not load it via TLS (I'm surprised this is possible), or else thinks it did not. That's bad, and surely why it's getting blocked. I see this sometimes also with developer.gnome.org (often when pages are restored after a previous load).
$ gnutls-cli fbstatic-a.akamaihd.net Processed 163 CA certificate(s). Resolving 'fbstatic-a.akamaihd.net'... Connecting to '80.239.142.42:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=MA,L=Cambridge,O=Akamai Technologies\, Inc.,CN=a248.e.akamai.net', issuer `O=Cybertrust Inc,CN=Cybertrust Public SureServer SV CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-06-12 20:35:45 UTC', expires `2015-06-12 20:35:45 UTC', SHA-1 fingerprint `f01a81f9c6c0a1ffb26b477fa38145ce428a4ff9' Public Key ID: 729d81d2de120831624910be826e1ce8f306e4b2 Public key's random art: +--[ RSA 2048]----+ |o++.+. | |.... o o . | | . o + . | |o.. o + o | |*o . S + | |*o. o . | |.B. | |E o. | | .. | +-----------------+ - Certificate[1] info: - subject `O=Cybertrust Inc,CN=Cybertrust Public SureServer SV CA', issuer `C=IE,O=Baltimore,OU=CyberTrust,CN=Baltimore CyberTrust Root', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-09-08 17:35:16 UTC', expires `2020-09-08 17:34:08 UTC', SHA-1 fingerprint `30d1fd4a296ab1a8831cd56b4110a227f557bfff' - Certificate[2] info: - subject `C=IE,O=Baltimore,OU=CyberTrust,CN=Baltimore CyberTrust Root', issuer `C=US,O=GTE Corporation,OU=GTE CyberTrust Solutions\, Inc.,CN=GTE CyberTrust Global Root', RSA key 2048 bits, signed using RSA-SHA1, activated `2012-04-18 16:36:18 UTC', expires `2018-08-13 16:35:17 UTC', SHA-1 fingerprint `4d34ea92764b3a3149119952f41930ca11348361' - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate.
(In reply to comment #10) > Actually, I think I see what's happening: that is secure CSS with a good chain > of trust, I have no security level lock in the address bar: WebKit either did > not load it via TLS (I'm surprised this is possible), or else thinks it did > not. Well it seems bad, but obviously not the reason it's getting blocked if there's a real cert error. So Epiphany is doing the right thing -- yay -- the question is why gnutls doesn't accept the chain for you when it does for me (in both Fedora and Debian Testing), and when Firefox and Chrome both accept it. Carlos, from our chat on IRC it looks like you're using an unstable version of gnutls (3.3 is currently their development branch) so I'm going to try upgrading to that version to see if I can reproduce this. One more thing: please check the version of your ca-certificates package. GTE CyberTrust Global Root was removed from Debian and then restored in their 20140325 release, which was a good while ago so you should have it by now....
I can't reproduce this even with Debian sid, gnutls 3.3.6. :/ I guess my advice is to try updating, and if that doesn't fix it, report a bug to gnutls and see if they can figure out what's wrong. Or ask on this list: http://lists.gnupg.org/mailman/listinfo/gnutls-help
Using F21: https://images-na.ssl-images-amazon.com/images/G/08/gno/sprites/global-sprite-32-v1._V351965906_.png Worked a couple of days ago. Before upgrading to gnutls-3.3.6-2. $ gnutls-cli images-na.ssl-images-amazon.com Processed 173 CA certificate(s). Resolving 'images-na.ssl-images-amazon.com'... Connecting to '54.192.128.124:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `C=US,ST=Washington,L=Seattle,O=Amazon.com Inc.,CN=Images-na.ssl-images-amazon.com', issuer `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', RSA key 2048 bits, signed using RSA-SHA1, activated `2014-06-01 00:00:00 UTC', expires `2015-05-21 23:59:59 UTC', SHA-1 fingerprint `e0d0f5925742bfb7d3659daabfb07a14c51c8080' Public Key ID: 0d95f98e41acaaa5cbdb0e3b7596c6d865974c1b Public key's random art: +--[ RSA 2048]----+ | ..o | | .= E | | .o + + | | .o+ * | | =S+.= | | = B . . | | .= + | | .++ | | ==o | +-----------------+ - Certificate[1] info: - subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)10,CN=VeriSign Class 3 Secure Server CA - G3', issuer `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', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-08 00:00:00 UTC', expires `2020-02-07 23:59:59 UTC', SHA-1 fingerprint `5deb8f339e264c19f6686f5f8f32b54a4c46b476' - Certificate[2] info: - subject `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', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-08 00:00:00 UTC', expires `2021-11-07 23:59:59 UTC', SHA-1 fingerprint `f4a80a0cd1e6cf190b8cbc6fbc991711d482c9d0' - Status: The certificate is trusted. - Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA256) - Session ID: F6:10:23:C8:EA:6A:2E:C8:CB:93:9F:59:46:12:A4:2F:D1:6D:D2:98:C3:33:86:84:7E:34:FB:87:9B:3B:87:FF - Ephemeral EC Diffie-Hellman parameters - Using curve: SECP256R1 - Curve size: 256 bits - Version: TLS1.2 - Key Exchange: ECDHE-RSA - Server Signature: RSA-SHA256 - Cipher: AES-128-CBC - MAC: SHA256 - Compression: NULL - Handshake was completed - Simple Client Mode: - Peer has closed the GnuTLS connection I get the same "Peer closed the GnuTLS connection" with the Facebook host above.
3.3.7-1[1] shows the same symptoms. [1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=570420
Going all the way back to version 3.3.2 doesn't fix the problem.
OK, Bastien, your problem -- which I CAN reproduce -- looks like a real GNOME bug, since gnutls accepts the cert but we don't. We're using gnutls to verify the cert (indirectly, through webkit, libsoup, glib, and finally glib-networking) so we should accept the same certs that it does (or more). It's probably a bug in glib-networking. I'm still investigating, but this is a different issue from the original problem with Facebook (which is definitely not a GNOME bug).
OK, so * Xabier, Carlos: your problem might also be https://bugzilla.mozilla.org/show_bug.cgi?id=1046343 -- looks like Mozilla removed this root and then put it back AGAIN. My confusion is how you would have wound up with an affected version of ca-certificates on Debian. NOTGNOME regardless, since gnutls-cli says it's invalid. * Bastien: we figured out that the Amazon problem was caused by a ca-certificates update. F20's gnutls-cli rejects the cert, but F21's accepts it. I think the next step is a bug report to the folks at gnutls, since the only apparent difference here is the version of gnutls involved.
Oh, background: Mozilla is removing a bunch of root certs, upstream Firefox users will be affected beginning with Firefox 32 (which is soon), and sites will probably notice they're broken then. So we don't need to worry too much about this.
So the solution is not to browse Facebook with Ephy until the problem is solved in GNUTLS?
(In reply to comment #20) > So the solution is not to browse Facebook with Ephy until the problem is solved > in GNUTLS? Downgrade your ca-certificates, or wait until Facebook fixes their certificate.
Basically the solution is: distros should use the same ca-certificates as Mozilla, lagging by a couple of weeks, because web sites will not notice that they're broken in Debian or Fedora, but they will notice if they're broken in upstream Firefox. We think the Amazon issue may or may not be a bug (we've moved that to Red Hat Bugzilla), but the Facebook issue is just something Facebook will have to fix (and they will, once Firefox 32 is released).
(In reply to comment #22) > but the Facebook issue is just something Facebook will have to fix > (and they will, once Firefox 32 is released). My bad, that's wrong: what I said in comment #18 is correct, you should have that root cert but you don't. My recommendation is to report a bug to your distro and try to find out why this cert is missing.
Debugging some more with Xabier, we discovered the line '!mozilla/GTE_CyberTrust_Global_Root.crt' in his /etc/ca-certificates.conf, whereas mine did not have the bang. Removing the bang should fix the bug. I think there is probably a bug in the script that updates this file, such that it does not properly handle reinstating a previously-removed certificate. I recommend reporting this on Debian's bugtracker, since /etc/ca-certificates does not exist on Fedora and the bug is most likely in a Debian-specific script that updates this file when the ca-certificates package is upgraded. History: that cert was removed by a Debian update in February, and reinstated by a Debian update in March, but the configuration file was not properly updated to reflect this.
(In reply to comment #24) > Removing the bang should fix the bug. Then run dpkg-reconfigure, Xabier discovered.
(In reply to comment #24) > Debugging some more with Xabier, we discovered the line > '!mozilla/GTE_CyberTrust_Global_Root.crt' in his /etc/ca-certificates.conf, > whereas mine did not have the bang. Removing the bang should fix the bug. I > think there is probably a bug in the script that updates this file, such that > it does not properly handle reinstating a previously-removed certificate. I > recommend reporting this on Debian's bugtracker, since /etc/ca-certificates > does not exist on Fedora and the bug is most likely in a Debian-specific script > that updates this file when the ca-certificates package is upgraded. > > History: that cert was removed by a Debian update in February, and reinstated > by a Debian update in March, but the configuration file was not properly > updated to reflect this. I suspect this is more related to unattended upgrades that didn't ask me to reconfigure that package or something.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743339
(In reply to comment #7) > It seems it has to do with the TLS stuff, if you open the inspector and tries > to see the resources it says: > > Failed to load resource: Unacceptable TLS certificate. > > The thing is that when running epiphany -p it works. This is concerning.... (In reply to comment #8) > The first url works in firefox and chromium, even if the CA is unknown. Should > we accept certificates with an unknown CA? We determined that these certificates were considered valid by Firefox and Chromium (but DV certs, so the owner displayed as unknown). If the cert didn't validate, then FF/Chromium would have blocked it.
(In reply to comment #28) > (In reply to comment #7) > > It seems it has to do with the TLS stuff, if you open the inspector and tries > > to see the resources it says: > > > > Failed to load resource: Unacceptable TLS certificate. > > > > The thing is that when running epiphany -p it works. > > This is concerning.... I realized that it worked in a private instance because for some reason the private instance was loading resource from https://static.xx.fbcdn.net instead of https://fbstatic-a.akamaihd.net. I have no idea why.
(In reply to comment #26) > (In reply to comment #24) > > Debugging some more with Xabier, we discovered the line > > '!mozilla/GTE_CyberTrust_Global_Root.crt' in his /etc/ca-certificates.conf, > > whereas mine did not have the bang. Removing the bang should fix the bug. I > > think there is probably a bug in the script that updates this file, such that > > it does not properly handle reinstating a previously-removed certificate. I > > recommend reporting this on Debian's bugtracker, since /etc/ca-certificates > > does not exist on Fedora and the bug is most likely in a Debian-specific script > > that updates this file when the ca-certificates package is upgraded. > > > > History: that cert was removed by a Debian update in February, and reinstated > > by a Debian update in March, but the configuration file was not properly > > updated to reflect this. > > I suspect this is more related to unattended upgrades that didn't ask me to > reconfigure that package or something. I never do unattended upgrades.
(In reply to comment #30) > I never do unattended upgrades. Me neither, I meant that you have different levels of what you want to be asked about when configuring the packages. This reconfiguration could be kicked out because it was considered as 'easy' and we have by default a higher value (which could be discussed, of course). That or it's a bug.