Issue metadata
Sign in to add a comment
|
Chrome failure with captive portal - Your connection is not private: NET::ERR_COMMON_NAME_INVALID
Reported by
sain.da...@gmail.com,
Nov 3 2016
|
||||||||||||||||||||||||||
Issue descriptionSteps to reproduce the problem: 1. Setup Cisco WebAuth with valid SSL certificate on Cisco Wireless Controller. 2. Connect to open Wi-Fi. 3. Browser opens, Receive error. Public user unable to continue and use network. What is the expected behavior? Expected behavior is as Firefox/Safari/IE function on Android/iOS/Windows and load WebAuth page so public has to accept Acceptable Use Policy and are able to use internet. What went wrong? I understand the https://google.com home page uses HSTS for security but I don't know if this plays into the issue at this point. I've captured packets (at the WLC and over the air sniffing with a spare thin AP) so I can see everything, including the 802.11, DNS, HTTP requests and responses. This is basically what I see: Connect device to Wi-Fi Device performs a DNS request for connectivitycheck.android.com. DNS responds with an IP Device initiates an HTTP GET for IP/generate_204 HTTP/1.1 Response created by the Cisco WLC is HTTP/1.1 200 OKAY (text/html). In this response there is a location entry that points to the WLC login page: https://wlc.ourdomain.org/fs/customwebauth/login.html?switch_url=https://wlc.ourdomain.org/login.html&ap_mac=64:f6:9d:e4:b0:e0&client_mac=fc:c2:de:a7:14:5f&wlan=SSID&redirect=connectivitycheck.android.com/generate_204 At this point, the above error is displayed. From reading various sources, it looks like the SSL cert presented does not match the expected DNS name requested so Chrome displays the message (please correct me if I am wrong). At an end user level they are blocked and cannot proceed. There is no skip/accept process within the browser now like in the past. This is the general public - remember that they are not going to know what to do unless we help them and I don't want to be at the door greeting every person as they come in the door telling them to change their default browser if using Android with Chrome. From what I understand, Chrome needs an error response or a "redirect", based on the tech white paper. The HTTP 1.1 Location tag is a type of redirect (but I don't know if it's valid in a 200 response - maybe a 201 or 202). In searching, it appears Aruba Networks wireless has similar issues to what I'm seeing with Cisco. To prevent a large amount of stale connections, we expire the connections every 4 hours. This means when the user reconnects they will receive the error again. The "Google" solution is to type a non HTTPS URL into the address bar which will cause the WebAuth page to load. Attached is image of issue and packet capture. Did this work before? No Chrome version: 54.0.2840.85 Channel: stable OS Version: 6.0.1 Flash Version: I have packet capture I can share, but I don't want it publicly visible.
,
Nov 4 2016
,
Nov 4 2016
Chrome has a special captive portal interstitial integrated with the SSL warning page. (Click one of the captive portal links on chrome://interstitials to see it.) According to my understanding, the captive portal interstitial should have fired for this case, unless the probe request timed out after more than 3 seconds. To the original reporter, if you're still on the captive portal, I wonder if you'd be able to check the timing on the generate_204 response and see if it took more than 3 seconds?
,
Nov 4 2016
Thanks for the reply. Packet capture shows this: 96 12:10:23.655956 10.132.3.33 216.58.194.46 HTTP 527 GET /generate_204 HTTP/1.1 97 12:10:23.655956 216.58.194.46 10.132.3.33 TCP 96 80→60011 [ACK] Seq=1 Ack=432 Win=6592 Len=0 TSval=506641742 TSecr=18579442 98 12:10:23.655956 216.58.194.46 10.132.3.33 HTTP 854 HTTP/1.1 200 OK (text/html)
,
Nov 4 2016
Is the HTTP 200 OK response correct to fire the interstitial? I see it's the HSTS, non-overridable page I am seeing... Regards, David
,
Nov 4 2016
The captive portal interstitial is not enabled on Android, so we wouldn't show it even if the response returned back in 3 seconds (which seems to be the case here). That's bug 642993 , I think we can merge this bug into that?
,
Nov 4 2016
generate_204 pages are expected to return HTTP 204, and ideally any other code should be interpreted as being behind a captive portal. However, Chrome and Android's captive portal heuristics are slightly different, and I'm not sure how they interact. I'd expect Android's captive portal app to open in this case though.
,
Nov 4 2016
Looks like 335933 is related also? I've a production site with a Cisco WLC5508 running. We are leaving the public Captive Portal in production although all Android with default Chrome users (any current Samsung? Others?) will have issues. We are stating issues are the device owner's issue, not ours, but offering two solutions, (1) on expiration (every 4 hours), type a non http address in the address bar on the HSTS interstitial page, or (2) install and default to Firefox. I'm guessing (2) is not preferred by Chrome, but does provide a usable experience for end users. I am willing to do testing/packet captures if desired, to work toward a solution. Installing 54.? off of play store onto an old Galaxy SIII to test it with also - it's default browser is something custom (Internet version 4.4.2-I535VRUDNE1, perhaps written by Verizon or Samsung devs for the i535 handset) that seems to do captive portal detection just fine.
,
Nov 4 2016
connectivitycheck.android.com probe likely comes from Android, not Chrome. I imagine the certificate errors coming from Chrome are related to your Cisco serving pages with self-signed certificates. You might want to disable this behavior as it causes these errors: https://supportforums.cisco.com/discussion/11684706/wlc-captive-portal-not-loading-images-or-http-correctly
,
Nov 6 2016
Good morning. connectivitycheck.android.com has a SSL cert issued to *.google.com. I do not see a probe to http://www.gstatic.com/generate_204 per: https://www.google.com/chrome/browser/privacy/whitepaper.html Guessing this was changed or works differently for Android Chrome. The Cisco WLC 5508 has a valid certificate, not self-signed. See attached image. When redirecting HTTPS to HTTP, an error would be generated in Chrome, that is why I setup a valid SSL cert. I've tried with secure WebAuth disabled and that doesn't help. Changing the setting does require a downtime for wireless at the hospital to reboot the controllers, so it's something I don't take lightly. Additionally, that link refers to an older version of software. I've worked with Cisco TAC, running a their recommended software and they don't know why the re-direct doesn't work with Chrome on Android, but does with all other browsers I have tested. Regards, David
,
Nov 7 2016
That certificate is for wlc.mdmh.org while the certificate error in the first comment is for www.google.com. I'm confused as to what's going on here, could you collect a net-internals log covering the time from when a device connects to your captive portal until the time the certificate error is displayed? http://dev.chromium.org/for-testers/providing-network-details
,
Nov 7 2016
Client makes a request to https://www.google.com (the home page), but it's re-directed to https://wlc.mdmh.org. Chrome does not handle the HTTPS redirection, so it is expecting to receive a cert from *.google.com, but receives one from *.mdmh.org instead so it's ticked off and tells us net::err_cert_common_name_invalid. Log is attached.
,
Nov 8 2016
HSTS caused redirect from http://www.google.com to https://www.google.com. This is the same as Issue 642322 ; merging into umbrella bug. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Nov 4 2016Labels: -Type-Bug-Security -Pri-2 -Restrict-View-SecurityTeam Pri-3 Type-Bug