0

I setup a captive portal on a wireless access point. If I use a laptop to connect to it, the laptop pops up a browser telling me to login to the captive portal. I can open any browser on the laptop (IE, Chrome, Firefox) and it works fine.

With my Samsung Galaxy S8 (Android 9), when I connect to the wireless access point, Android automatically checks for captive portals, same as every other device does these days. Since it detects it, it also pops up a browser and tries to load the login page, and on my phone, it shows an SSL cert error. Other Android phones don't have this error.

enter image description here

If I tell my phone to stay connected to the WiFi despite not having logged in, and open Chrome on my phone, the exact same captive portal redirect loads without any issues. It is clear that whatever internal browser my phone is popping up, it's not the regular Chrome browser, as that one works fine. It also doesn't appear to be the "Internet" app my phone shipped with, as that shows no SSL error either.

What browser is my Galaxy S8 using to detect captive portals? Why does it have an SSL error when other browsers and devices don't? How do I even begin to debug this?

Note: My SSL cert was generated by LetsEncrypt. It points to http://ocsp.int-x3.letsencrypt.org as the server for verifying that the cert hasn't been revoked. I added this domain to my captive portal's walled garden (bypass) list, so that connections to that domain are NOT redirected, but it didn't help.

Improve this question
8
  • Your captive portal has the HTTPS url cprewrite.hyperlinkinc.ca? Do you correctly publish the captive portal via DHCP (see rfc7710).
    – Robert
    Jan 30, 2020 at 9:40
  • Yes - the device creating the captive portal redirects requests to our login page, located at cprewrite.hyperlinkinc.ca. I know normally captive portals redirect to a web server on the LAN, but ours is remote. As you can see, cprewrite.hyperlinkinc.ca has a legitimate certificate issued by lets-encrypt that is accepted by every modern browser there is. It sounds like the DHCP option might help Androiid detect that there is a portal if it wasn't detecting it, but it clearly does, or there would be no popup.
    – John
    Jan 30, 2020 at 16:06
  • I would say it is the other way around: announcing login portals via DHCP is the standard and captive portals are outdated hacking techniques.
    – Robert
    Jan 30, 2020 at 17:25
  • Please check the developer settings on the device which browser is selected as "WebView Implementation". Make sure the same web browser is selected as you had used for opening the captive portal page. Note: According to SSLLabs the used server certificate is not trusted.
    – Robert
    Jan 30, 2020 at 18:24
  • @Robert My Galaxy S8 WebView Implementation lists Chrome, and Android System WebView. Chrome is selected. The other one is greyed out. The Captive Portal popup is definitely not using Chrome, so it's weird that this setting says it should be. Unless you're seeing different results on SSLLabs than I am, or I'm reading it wrong, the report says that the Grade is capped at B because the server doesn't support Forward Secrecy, but the certificate is trusted by "Mozilla, Apple, Android, Java, Windows", which is almost everyone. Certainly Android.
    – John
    Jan 30, 2020 at 19:27

1 Answer 1

Reset to default
1

After a ton of digging, I finally figured it out.

First - a quick recap: The captive portal's job is to intercept any requests to the internet, and redirect it to the captive portal's login page. Because my login page is cprewrite.hyperlinkinc.ca, a remote website, I had to add it to the whitelist. Any requests to that domain will actually get online. This works great.

The problem is that when the user is redirected to that web page, the web page's HTML reference some external resources. My page relied on bootstrap for some css formatting. My bootstrap was stored locally, on cprewrite.hyperlinkinc.ca, so that wasn't a problem. Unfortunately, when I read the source code for bootstrap (bootstrap.min.css), one of the first lines reads:

*/@import url("https://fonts.googleapis.com/css?family=Lato:400,700,400italic");

Essentially bootstrap references an external resource for its fonts. This makes the Galaxy S8 try to load the resource. Because the link is an HTTPS link (not HTTP), it is expecting to receive an SSL cert for fonts.googleapis.com. Since fonts.googleapis.com was not in the whitelist, my captive portal was redirecting the request to itself, returning its own SSL certificate, rather then the expected one.

Some browsers, like the regular Google Chrome browser on Android, just fail silently. Others, like this In-App browser, fail loudly, and show an SSL warning.

I'm still not entirely sure what this browser is that pops up when captive portals are detected, but the question is now moot, since I know why it didn't like my page.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .