UserAgent: Mozilla/5.0 (X11; CrOS x86_64 8530.81.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.103 Safari/537.36
Platform: 8530.81.0 (Official Build) stable-channel stumpy

Steps to reproduce the problem:
1. I saw a Wi-Fi access point called "xfinity".
2. Connected to it.
3. Saw a "Captive Portal" pop-up window with no identifying URL and no SSL certificate information.
4. This window asked for Xfinity login name and password. There was no way to tell if it came from Xfinity aka Comcast, or if it came from somebody posing as Xfinity simply wanting to collect login credentials.

What is the expected behavior?
For proper security, the user should be shown an https URL from where the login prompt originates, and some way of validating the SSL certificate for that URL. Does the SSL certificate come from Xfinity? There is no way to tell.

In this case, the access point really did belong to Xfinity. When I connected to it with a Nexus 9 tablet, I saw a similar login prompt, but the window had a URL and I could identify it as an xfinity.com URL with a valid SSL certificate. But Chrome OS did not let me do the same type of verification.

(This problem is bigger than just Chrome OS. Similar insecurities are present in other places not related to Chrome OS. Users are being trained to blindly enter security credentials in response to unverifiable requests. E.g., in the Android system, applications, such as Android Pay, sometimes ask the user to re-enter the screen lock code. The user is given no way of verifying if this request comes securely from the OS or if the application is merely faking the request so it can collect the user's screen lock code.)

What went wrong?
Phishing potential.

Did this work before? N/A 

Chrome version: 53.0.2785.103  Channel: n/a
OS Version: 8530.81.0
Flash Version: Shockwave Flash 22.0 r0
 

Deleted: Screenshot 2016-09-22 at 02.59.51.png 233 KB

	Screenshot 2016-09-22 at 02.59.51.png 233 KB View Download