GNOME Bugzilla – Bug 794803
Epiphany 3.28 fails TLS handshake
Last modified: 2018-07-28 07:43:24 UTC
Hi GNOME people, just by chance I found out I cannot visit the website for Science Translational Medicine (https://stm.sciencemag.org/) using epiphany (gnome-web) version 3.28.0.1+4+g051d4f616-1 (latest available in Arch Linux). The error shown is the following: ---------- The site at https://stm.sciencemag.org seems to be unavailable. It may be temporarily inaccessible or moved to a new address. You may wish to verify that your internet connection is working correctly. ▼ Technical information The precise error was: Peer sent fatal TLS alert: Handshake failed ---------- I have checked with other browsers that have minimal additional dependencies like midori and eolie, and both show the website without any problem, so I'm guessing it has nothing to do with gnutls and the like. As far as I know, all of them use the same backend (webkit2gtk 2.20.0-1). I have found other bugs where (SSL) handshake fails but they were solved like 7-12 years ago. I tried running epiphany from the terminal, hoping to catch some more detailed info... but it doesn't. Let me know if there's another way to get that detailed info!
(In reply to Robert Paulson from comment #0) > I have checked with other browsers that have minimal additional dependencies > like midori and eolie, and both show the website without any problem, so I'm > guessing it has nothing to do with gnutls and the like. As far as I know, > all of them use the same backend (webkit2gtk 2.20.0-1). When testing in Midori and Eolie, I'm pretty sure you just loaded http://stm.sciencemag.org by accident, rather than https://stm.sciencemag.org, right? GnuTLS can't load it either: $ gnutls-cli stm.sciencemag.org Processed 151 CA certificate(s). Resolving 'stm.sciencemag.org:443'... Connecting to '104.24.107.144:443'... *** Fatal error: A TLS fatal alert has been received. *** Received alert [40]: Handshake failed *** handshake has failed: A TLS fatal alert has been received. SSLLabs can't load it either: https://www.ssllabs.com/ssltest/analyze.html?d=stm.sciencemag.org And Chromium can't load it either. But if you load http://stm.sciencemag.org, it works just fine. The problem seems to be that there's no TLS server running on 443. So I don't think there's any problem here. :)
Now that's weird (and sorry, it kind of makes me feel stupid). Indeed, checking my history it did show the http:// version in both. I checked the link given in https://www.sciencemag.org/journals and it does point to http://stm.sciencemag.org/, without https. Now, epiphany changes it automatically to https and that's why I can't see it.
(In reply to Robert Paulson from comment #2) > Now, epiphany changes it automatically to https and that's why I can't see > it. The problem is here: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/epiphany#n31 The HTTPS Everywhere code is experimental and only intended for developers right now. I'll move the code to a sidebranch to ensure distros stop playing with it.
I was just hooking it up now, sorry for posting this as a bug!
The following fix has been pushed: 762c7bc Remove the HTTPS Everywhere support
Created attachment 370310 [details] [review] Remove the HTTPS Everywhere support It's experimental and not supposed to be enabled, but got turned on in Arch, so best move it to a sidebranch for now. I'm not sure if we'll ever bring it back, though. HTTPS Everywhere was a great idea a few years ago, when it was common for websites to offer experimental support for HTTPS but not redirect users to it automatically. Nowadays, such websites almost always problems, such as blocked mixed content or invalid HTTPS certificates, or have disabled HTTPS since the ruleset was written. That means, to do this right, we have to ignore TLS errors -- including in subresources -- and disable mixed content blocking. This scheme to preserve web compatibility needs to be implemented before we consider bringing it back. Meanwhile, more and more websites are redirecting to HTTPS and are nowadays configured to handle this correctly, so the necessity of HTTPS Everywhere is lower now than ever before, and decreasing fast. Moreover, if a website implements its own proper support for HTTPS and starts automatically redirecting users to it, but the ruleset is not updated, then under the scheme I propose above, the ruleset would become a way of *reducing* security for websites once they've begun to support HTTPS. So I'm skeptical that we should bring this back at all. Times, they are a-changing.
Just for the record, I excluded libhttpseverywhere from the PKGBUILD and recompiled. Problem gone.
I came here because I saw the above commit message (after wondering how to use libhttpseverywhere). There are some things mentioned in there which don't seem to be true: > Nowadays, such websites almost always problems, such as blocked mixed content Those rules should be disabled by default (and only enabled in Tor Browser which indeed disables that check): https://www.eff.org/https-everywhere/rulesets#mixed-content-blocking-mcb Though it looks like libhttpseverywhere doesn't filter those out... > invalid HTTPS certificates, or have disabled HTTPS since the ruleset was written https-everywhere has automated tests to prevent those kind of things happening unnoticed: https://github.com/EFForg/https-everywhere/blob/master/ruleset-testing.md In the case of this specific example (stm.sciencemag.org), the ruleset only rewrites sciencemag.org and www.sciencemag.org - stm is even listed in a comment as a subdomain which is broken: https://github.com/EFForg/https-everywhere/blob/master/src/chrome/content/rules/Sciencemag.org.xml So if Epiphany was rewriting it, that was a bug in either libhttpseverywhere or Epiphany, but not how things were supposed to work. I guess what I'm trying to say is that HTTPS Everywhere would be useful even *without* the security changes you propose above - and even for websites which do a redirect, as the redirect itself can be hijacked as well (Airport WiFis, I'm looking at you!): https://www.eff.org/https-everywhere/faq#why-does-https-everywhere-include-rules-for-sites-like-paypal-that-already-require-https-on-all-their-pages The only thing that *does* make it obsolete is HSTS preloading, which isn't really widespread currently: https://hstspreload.org/