New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 776945 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Nov 2017
Cc:
█ lassey@chromium.org
tbansal@chromium.org
est...@chromium.org
█ talo@chromium.org
bengr@chromium.org
█ cbentzel@chromium.org
mea...@chromium.org
█ f...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

SSL cert error on WiFi login portal is confusing

Project Member Reported by mdw@chromium.org, Oct 20 2017 
Application Version (from "Chrome Settings > About Chrome"): 63.0.3223.7
Android Build Number (from "Android Settings > About Phone/Tablet"): Pixel
Device: NHG47O

Steps to reproduce: 

1) Connect to a WiFi hotspot run by ETECSA in Havana, Cuba
2) Open Chrome
3) Try to visit any website (e.g., cnn.com)

Observed behavior: 

The captive portal for this network redirects you to https://login.nauta.cu:8443//LoginServlet. This page shows an SSL cert error with NET::ERR_CERT_COMMON_NAME_INVALID (see attached screenshot).

This is a bit of a problem because it puts up a substantial roadblock to users trying to login to the WiFi portal in Cuba, which is already a cumbersome process. I am not sure how many users would know to click on the "Advanced" and "Proceed to login.nauta.cu (unsafe)" error.

Arguably this is not a bug in Chrome but rather a misconfiguration with the hotspot. However, we should probably think about the implication here since this could be a serious impediment to users getting online. Especially since this is a login portal and not a case where the user was intending to visit login.nauta.cu explicitly, it seems odd to me that we'd bother the user with this warning -- their request was already being redirected by the captive portal.

I'm not sure what a good solution is here -- perhaps just ask ETECSA to fix their certs -- but I want to flag it since this problem was not evident when using UC Browser.
Screenshot_20171017-165647.png
168 KB View Download

Comment 1 by cbentzel@chromium.org, Oct 20 2017 

I'd be interested in why UC doesn't flag it.

Put another way - what if the captive portal redirected to
https://www.gmail.com, and the browser automatically proceeded through the
certificate warning. That seems horrible from user security perspective.

We also don't even necessarily know it's the captive portal - it could be
anyone in network path.

My recommendation would be that they fix their certs, even though I am
sympathetic to difficulties getting online under current configuration.

Comment 2 by cbentzel@chromium.org, Oct 20 2017 

Basically - we can have reasonably high confidence that a captive portal or someone in the network is redirecting us to a page (using things like the gen204 probe), but I don't think we can have confidence that it's actually a captive portal login page that we are going to.

Comment 3 by cbentzel@chromium.org, Oct 20 2017

Cc: -cbentzel@chromium.org lassey@chromium.org

Comment 4 by cbentzel@chromium.org, Oct 20 2017

Cc: cbentzel@chromium.org

Comment 5 by lgar...@chromium.org, Oct 20 2017

Components: UI>Browser>Interstitials

Comment 6 by est...@chromium.org, Oct 23 2017

Cc: est...@chromium.org

Comment 7 by f...@chromium.org, Oct 25 2017

Cc: mea...@chromium.org
UC Browser doesn't check for valid HTTPS under many conditions. It's trivial to MITM. So, it's unfortunately not surprising that UC Browser would work in this situation.

I am unfortunately not sure what we could do better here without opening up the door to attacks. It is a very frustrating problem. I don't like that Chrome is preventing people from getting online, but if we were to change Chrome's behavior to make it more lenient, it would lead to MITM attacks.

Comment 8 by jialiul@chromium.org, Nov 1 2017

Status: WontFix (was: Untriaged)
I agree with #7, this is WAI.
Mark this as Won'tFix.
►

Sign in to add a comment