Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1176316 - HTTPS connectivity check fails
Summary: HTTPS connectivity check fails
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1187867 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-12-20 11:30 UTC by Michael Chapman
Modified: 2015-10-05 09:04 UTC (History)
14 users (show)

Fixed In Version: NetworkManager-1.0.6-6.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-04 22:52:59 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
SSLv3 attempt (deleted)
2015-07-01 03:29 UTC, Jason Haar
no flags Details
Logging of connectivity issue through proxy (deleted)
2015-10-05 08:59 UTC, Jan Vlug
no flags Details


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 750260 0 None None None 2019-03-12 04:41:17 UTC

Description Michael Chapman 2014-12-20 11:30:28 UTC
This problem was found with NetworkManager-0.9.10.0-14.git20140704.fc21.x86_64.

NetworkManager in Fedora is configured to probe https://fedoraproject.org/static/hotspot.txt to test network connectivity. This probe is continually failing, with NM logging:

"""
Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer failed to perform TLS handshake'.
"""

I am treating that error message with suspicion, because as far as I can tell fedoraproject.org does do TLS correctly.

Instead, I suspect the problem is due to the HTTP request itself. According to bug 1135777, the request looks like:

"""
GET /static/hotspot.txt
Host: fedoraproject.org
"""

As this does not contain an HTTP version on the first line, it's treated as a pre-HTTP/1.0 request, which means it can not contain any request headers. The fedoraproject.org server responds with a 404 Not Found page immediately after it receives the first line.

I have not been able to confirm that this is the exact form of the request; the behaviour described here has been discovered by manually testing with "openssl s_client -connect fedoraproject.org:443".

A workaround is to switch back to the non-HTTPS URL, http://fedoraproject.org/static/hotspot.txt. I'm not entirely sure why, but with a non-HTTPS URL NM generates a valid HTTP/1.1 request:

"""
GET /static/hotspot.txt HTTP/1.1
Host: fedoraproject.org
Connection: keep-alive
"""

Comment 1 Charles R. Anderson 2015-01-31 13:53:12 UTC
*** Bug 1187867 has been marked as a duplicate of this bug. ***

Comment 2 Thomas Haller 2015-06-02 20:19:16 UTC
I cannot confirm the analysis:


openssl req -newkey rsa:1024 -x509 -nodes -keyout test_key.pem -new -out test_cert.pem  
openssl s_server -cert test_cert.pem -key test_key.pem -state -debug -accept 10443


then NetworkManager-0.9.10.2-5.fc21 sends:

GET /static/hotspot.txt HTTP/1.1
Host: 127.0.0.1:10443
Connection: close

Comment 3 Martin Dengler 2015-06-03 12:44:18 UTC
I can get the page https://fedoraproject.org/static/hotspot.txt via Firefox and wget fine:

$ wget https://fedoraproject.org/static/hotspot.txt
--2015-06-03 13:33:54--  https://fedoraproject.org/static/hotspot.txt
Resolving fedoraproject.org (fedoraproject.org)... 5.175.150.50, 209.132.181.15, 152.19.134.142, ...
Connecting to fedoraproject.org (fedoraproject.org)|5.175.150.50|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3 [text/plain]
Saving to: ‘hotspot.txt’

hotspot.txt                        100%[==================================================================>]       3  --.-KB/s   in 0s     

2015-06-03 13:33:54 (248 KB/s) - ‘hotspot.txt’ saved [3/3]

...but even with this:

# rpm -q NetworkManager
NetworkManager-0.9.10.2-5.fc21.x86_64

...I am still seeing this:

# journalctl -n 1000 -u NetworkManager | grep https | tail -3
Jun 03 13:24:29 ll NetworkManager[827]: <info>  Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer 
failed to perform TLS handshake'.
Jun 03 13:29:29 ll NetworkManager[827]: <info>  Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer 
failed to perform TLS handshake'.
Jun 03 13:34:29 ll NetworkManager[827]: <info>  Connectivity check for uri 'https://fedoraproject.org/static/hotspot.txt' failed with 'Peer 
failed to perform TLS handshake'.

Background:

# uname -a
Linux ll 3.19.5-200.fc21.x86_64 #1 SMP Mon Apr 20 19:51:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
# cat /etc/fedora-release 
Fedora release 21 (Twenty One)

Comment:
I think some other package update may have fixed this (journalctl messages) in the last couple of months, because I see this issue (journalctl messages) on another of my F21 machines but not a third F21 machine, all connected to the same network.

Comment 4 Jason Haar 2015-07-01 02:22:44 UTC
I'm seeing the same issue with F22 - I'm getting around 100-200 of these errors a day

Don't seem to be causing any problem, but certainly annoying. As per the original writer, that URL works fine using curl

BTW. I do have a localhost proxy installed as my "Network" area under "All Settings" refers to it. However, it shows no attempts to access fedoraproject.org, so I doubt it's related - just being thorough (ie maybe NetworkManager has a bug with this check IFF a proxy is involved)

Comment 5 Michael Chapman 2015-07-01 02:59:29 UTC
(In reply to Jason Haar from comment #4)
> BTW. I do have a localhost proxy installed as my "Network" area under "All
> Settings" refers to it. However, it shows no attempts to access
> fedoraproject.org, so I doubt it's related - just being thorough (ie maybe
> NetworkManager has a bug with this check IFF a proxy is involved)

That's interesting, as I use a proxy too.

I've kept the config on the non-HTTPS URL since opening this bug, but I'll have to test it with HTTPS and bypassing the proxy.

Comment 6 Jason Haar 2015-07-01 03:29:26 UTC
Created attachment 1044865 [details]
SSLv3 attempt

Comment 7 Jason Haar 2015-07-01 03:30:15 UTC
I think I've found the problem. The NetworkManager code is using SSLv3 and the HTTPS server doesn't support SSLv3 anymore!

This is now a security bug: nothing should be using SSLv3.

Attached is my tcpdump showing NetworkManager connecting to https://fedoraproject.org/static/hotspot.txt, and you can see the Alert from the server(s) as it rejects its SSLv3 attempt

Comment 8 Jirka Klimes 2015-07-01 08:22:40 UTC
What are the versions of libsoup, glib-networking and gnutls you have? When I capture the trafic with wireshark, I can see that TLSv1.2 is used.

$ rpm -q libsoup
libsoup-2.48.1-2.fc21.x86_64
$ rpm -q glib-networking
glib-networking-2.42.0-2.fc21.x86_64
$ rpm -q gnutls
gnutls-3.3.15-1.fc21.x86_64

Note:The bug 1177964 might be related.

Comment 9 Michael Chapman 2015-07-01 08:49:35 UTC
I have the same package versions installed.

I've just switched back to the HTTPS URL. I am seeing TLSv1.2 also, and NM is reporting full connectivity.

So it's possible there is some combination of packages where it doesn't work, but I can't reproduce the problem now.

Comment 10 Jason Haar 2015-07-01 10:05:07 UTC
I'm running "dnf update" nightly, so my F22 is up to date

$ rpm -q libsoup
libsoup-2.50.0-1.fc22.x86_64
$  rpm -q glib-networking
glib-networking-2.44.0-1.fc22.x86_64
$ rpm -q gnutls
gnutls-3.3.15-1.fc22.x86_64
gnutls-3.3.15-1.fc22.i686

Comment 11 Fedora Admin XMLRPC Client 2015-08-18 14:58:11 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Jan Vlug 2015-08-31 10:02:47 UTC
See also: https://bugzilla.gnome.org/show_bug.cgi?id=750260

Comment 13 Jason Haar 2015-09-08 07:37:57 UTC
Still occurring. Fully patched f22 system. wireshark still says nm is using SSLv3 to talk to the server, and the server is (rightfully) rejecting the connection attempt (I can see the "client helo" followed by the server responding with a Fatal Alert SSL error)


Every time I see that question-mark where the wifi fan should be, I'm reminded of this bug :-)

Jason

Comment 14 Thomas Haller 2015-09-08 10:21:34 UTC
This will be fixed by NetworkManager-1.0.6-2.fc22 and newer, which doesn't use https for connectivity checking anymore.

This goes along with upstream bug https://bugzilla.gnome.org/show_bug.cgi?id=747866 and commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=2a3a4eb16f9119bf434a28adc94c2684da8fd5e4


NetworkManager-1.0.6-2.fc22 (and newer) is currently still in updates-testing.


dnf --enablerepo=updates-testing install NetworkManager

Comment 15 Fedora Update System 2015-09-08 10:32:32 UTC
NetworkManager-1.0.6-2.fc22 NetworkManager-openswan-1.0.6-2.fc22 NetworkManager-openvpn-1.0.6-3.fc22 NetworkManager-vpnc-1.0.6-3.fc22 network-manager-applet-1.0.6-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-10143

Comment 16 Fedora Update System 2015-09-08 11:15:00 UTC
NetworkManager-1.0.6-3.fc22 NetworkManager-openswan-1.0.6-2.fc22 NetworkManager-openvpn-1.0.6-3.fc22 NetworkManager-vpnc-1.0.6-3.fc22 network-manager-applet-1.0.6-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-10143

Comment 17 Fedora Update System 2015-09-08 21:26:37 UTC
NetworkManager-1.0.6-4.fc22, NetworkManager-openswan-1.0.6-2.fc22, NetworkManager-openvpn-1.0.6-3.fc22, NetworkManager-vpnc-1.0.6-3.fc22, network-manager-applet-1.0.6-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update network-manager-applet NetworkManager NetworkManager-openvpn NetworkManager-openswan NetworkManager-vpnc'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-10143

Comment 18 Fedora Update System 2015-09-28 21:01:23 UTC
NetworkManager-1.0.6-6.fc22 NetworkManager-openswan-1.0.6-2.fc22 NetworkManager-openvpn-1.0.6-3.fc22 NetworkManager-vpnc-1.0.6-3.fc22 network-manager-applet-1.0.6-2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-10143

Comment 19 Fedora Update System 2015-10-02 03:49:42 UTC
NetworkManager-1.0.6-6.fc22, NetworkManager-openswan-1.0.6-2.fc22, NetworkManager-openvpn-1.0.6-3.fc22, NetworkManager-vpnc-1.0.6-3.fc22, network-manager-applet-1.0.6-2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update NetworkManager-openswan network-manager-applet NetworkManager NetworkManager-openvpn NetworkManager-vpnc'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-10143

Comment 20 Fedora Update System 2015-10-04 22:52:25 UTC
NetworkManager-1.0.6-6.fc22, NetworkManager-openswan-1.0.6-2.fc22, NetworkManager-openvpn-1.0.6-3.fc22, NetworkManager-vpnc-1.0.6-3.fc22, network-manager-applet-1.0.6-2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 21 Jan Vlug 2015-10-05 08:55:31 UTC
I'm using NetworkManager.x86_64 1:1.0.6-6.fc22, but the connectivity check still fails. I guess due to the fact that the proxy is not being used, Though it is set through the gnome settings panel.

I will attach a file with some logging details

Comment 22 Jan Vlug 2015-10-05 08:59:55 UTC
Created attachment 1079868 [details]
Logging of connectivity issue through proxy

Comment 23 Jan Vlug 2015-10-05 09:04:15 UTC
Sorry, separate bug #1184406 is specific for the problem with the connectivity check through a proxy.


Note You need to log in before you can comment on or make changes to this bug.