Description of problem: Trying to load https://www.timewarnercable.com/ in Epiphany: The site at “https://www.timewarnercable.com/” seems to be unavailable. The precise error was: Error performing TLS handshake: GnuTLS internal error. Version-Release number of selected component (if applicable): 3.3.10-1.fc21 How reproducible: Always Steps to Reproduce: 1. Try to load https://www.timewarnercable.com/ in Epiphany Actual results: GnuTLS internal error Expected results: The page may or may not fail to load. Regardless, GnuTLS should not report an internal error. Additional info: This site is TLS 1.1 and 1.2 intolerant; it SHOULD load due to insecure version negotiation implemented in libsoup, but it's not a GnuTLS bug if it fails to load. I'm reporting this because of the GnuTLS internal error.
Hi, Connecting with gnutls-cli prints a different error. What does epiphany use to connect to that site? Resolving 'www.timewarnercable.com'... Connecting to '71.74.42.231:443'... *** Fatal error: The TLS connection was non-properly terminated. *** Handshake has failed GnuTLS error: The TLS connection was non-properly terminated.
The dependency chain is Epiphany -> WebKitGTK+ -> libsoup -> GLib -> glib-networking -> GnuTLS. The error message is created in glib-networking (specifically, in tls/gnutls/gtlsconnection-gnutls.c) by passing the return code from end_gnutls_io() to gnutls_strerror().
I run epiphany with GNUTLS_DEBUG_LEVEL set to 99. One issue which is a bit troubling is: gnutls[1]: Note that the security level of the Diffie-Hellman key exchange has been lowered to 256 bits and this may allow decryption of the session data On the point now. The important lines are: gnutls[3]: ASSERT: gnutls_handshake.c:1965 gnutls[3]: ASSERT: gnutls_handshake.c:2694 There the underlying layer it seems it is attempting a TLS negotiation without any TLS versions enabled. That's why the INTERNAL_ERROR was returned. This should be either in libsoup or glib-networking.
Probably libsoup. I will investigate, thanks!
Sorry for the delay. Something has changed elsewhere in the stack, because when I test in my jhbuild environment (with the same version of GnuTLS) I see the error "Peer failed to perform TLS handshake" rather than "GnuTLS internal error." I haven't discovered the cause of that change, though. (In reply to Nikos Mavrogiannopoulos from comment #3) > I run epiphany with GNUTLS_DEBUG_LEVEL set to 99. > > One issue which is a bit troubling is: > gnutls[1]: Note that the security level of the Diffie-Hellman key exchange > has been lowered to 256 bits and this may allow decryption of the session > data So this means the server has chosen weak primes for the key exchange, correct? Do you allow this by default for compatibility reasons? Am I correct in saying that this is unrelated, and not a glib-networking issue? But we really should at the very least display the connection as insecure in our UI, so we would need an error code or something from GnuTLS. > On the point now. The important lines are: > gnutls[3]: ASSERT: gnutls_handshake.c:1965 > gnutls[3]: ASSERT: gnutls_handshake.c:2694 > > There the underlying layer it seems it is attempting a TLS negotiation > without any TLS versions enabled. That's why the INTERNAL_ERROR was > returned. This should be either in libsoup or glib-networking. First we handshake with this priority: NORMAL:%COMPAT:%LATEST_RECORD_VERSION:!VERS-SSL3.0 Then that fails, because the site is TLS 1.2 intolerant. Then we try again with a fallback handshake, where we disable everything except the lowest protocol level allowed in an attempt to connect to the broken server: NORMAL:%COMPAT:!VERS-SSL3.0:%COMPAT:!VERS-TLS-ALL:+VERS-TLS1.0 But I guess !VERS-TLS-ALL:+VERS-TLS1.0 disables all versions of TLS. I think our expectation was that !VERS-TLS-ALL followed by +VERS-TLS1.0 would disable all versions of TLS except TLS1.0. Do you consider this a usage error on our part, or a bug in gnutls? When I manually override the priority without !VERS-TLS-ALL, like this: G_TLS_GNUTLS_PRIORITY=NORMAL:%COMPAT:-VERS-SSL3.0:-VERS-TLS1.2:-VERS-TLS1.1:+VERS-TLS1.0 epiphany Then I can connect to this broken site.
(In reply to Michael Catanzaro from comment #5) > > One issue which is a bit troubling is: > > gnutls[1]: Note that the security level of the Diffie-Hellman key exchange > > has been lowered to 256 bits and this may allow decryption of the session > > data At least in the past, this was needed in order to be able to connect to some embedded https servers (eg, wifi router config pages). (Other browsers like Firefox appear to default to a low limit like this as well, or at least did at the time.) > > There the underlying layer it seems it is attempting a TLS negotiation > > without any TLS versions enabled. That's why the INTERNAL_ERROR was > > returned. This should be either in libsoup or glib-networking. > Then that fails, because the site is TLS 1.2 intolerant. Then we try again > with a fallback handshake, where we disable everything except the lowest > protocol level allowed in an attempt to connect to the broken server: No, the cleverer fallback code is only in glib-networking git master. In the version in F21, fallback is always to SSL3, and since epiphany is disabling SSL3, it ends up attempting to do a handshake with all versions of TLS/SSL disabled, as Nikos said. And then it misinterprets the error code. We could fix the error code, but it would make more sense to just patch in the cleverer fallback code from git master.
(In reply to Dan Winship from comment #6) > At least in the past, this was needed in order to be able to connect to some > embedded https servers (eg, wifi router config pages). (Other browsers like > Firefox appear to default to a low limit like this as well, or at least did > at the time.) > No, the cleverer fallback code is only in glib-networking git master. In the > version in F21, fallback is always to SSL3, and since epiphany is disabling > SSL3, it ends up attempting to do a handshake with all versions of TLS/SSL > disabled, as Nikos said. And then it misinterprets the error code. Oh yeah. :) But the cleverer fallback code still results in "peer failed to perform TLS handshake"; that's what I was actually testing yesterday. (In reply to Michael Catanzaro from comment #5) > When I manually override the priority without !VERS-TLS-ALL, like this: > > G_TLS_GNUTLS_PRIORITY=NORMAL:%COMPAT:-VERS-SSL3.0:-VERS-TLS1.2:-VERS-TLS1.1: > +VERS-TLS1.0 epiphany > > Then I can connect to this broken site. Whoops, the site also works if I do 'G_TLS_GNUTLS_PRIORITY=NORMAL:%COMPAT:-VERS-SSL3.0:%COMPAT:-VERS-TLS-ALL:+VERS-TLS1.0 epiphany', the same priority we use for fallback, which does not work, so I was wrong to assume the priority string is the problem.
(In reply to Dan Winship from comment #6) > (In reply to Michael Catanzaro from comment #5) > > > One issue which is a bit troubling is: > > > gnutls[1]: Note that the security level of the Diffie-Hellman key exchange > > > has been lowered to 256 bits and this may allow decryption of the session > > > data > > At least in the past, this was needed in order to be able to connect to some > embedded https servers (eg, wifi router config pages). (Other browsers like > Firefox appear to default to a low limit like this as well, or at least did > at the time.) Firefox still does, but I have submitted a patch to NSS to not do that any more :). To the point though, currently the defaults of gnutls of are 768 bits on the "NORMAL" level, and prioritizes the DHE after ECDHE and RSA, to avoid this kind of incompatibilities. The issue was with older gnutls versions which didn't have ECDHE, and prioritized DHE over RSA for forward secrecy. However, with the addition of ECDHE this is no longer the case and that prevents this kind of handshake failures this override is supposed to solve. So I'd suggest to no longer override that value.
(In reply to Nikos Mavrogiannopoulos from comment #8) > Firefox still does, but I have submitted a patch to NSS to not do that any > more :). To the point though, currently the defaults of gnutls of are 768 > bits on the "NORMAL" level, and prioritizes the DHE after ECDHE and RSA, to > avoid this kind of incompatibilities. The issue was with older gnutls > versions which didn't have ECDHE, and prioritized DHE over RSA for forward > secrecy. However, with the addition of ECDHE this is no longer the case and > that prevents this kind of handshake failures this override is supposed to > solve. So I'd suggest to no longer override that value. OK, for F22 we will no longer override this setting. However I note that Ivan Ristic's Bulletproof SSL book describes 1024-bit DH parameters as "weak" and 728-bit parameters as "insecure." Keeping this bug open as that was a side issue. I need to debug further to figure out why our connection doesn't work.
glib-networking-2.42.0-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/glib-networking-2.42.0-2.fc21
submitted updated f21 packages that include the smarter fallback code from git master
Package glib-networking-2.42.0-2.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glib-networking-2.42.0-2.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-3363/glib-networking-2.42.0-2.fc21 then log in and leave karma (feedback).
glib-networking-2.42.0-2.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Nikos Mavrogiannopoulos from comment #3) > One issue which is a bit troubling is: > gnutls[1]: Note that the security level of the Diffie-Hellman key exchange > has been lowered to 256 bits and this may allow decryption of the session > data As a follow-up to this spinoff discussion: it turns out that we were calling gnutls_dh_set_prime_bits() *before* calling gnutls_priority_set(), which resets the effects of the call to gnutls_dh_set_prime_bits(). This is why Epiphany on F21 with the problematic call to gnutls_dh_set_prime_bits() is nevertheless passing online Logjam tests like https://www.ssllabs.com:10445/