[jasonzemos]

Is it a problem that the URL is not HTTPS or is it the blessing required to defeat it?

[YPPH]

One reason for that is explained well in a comment on the article.

Note that as with the Windows version, the protocol is HTTP, not HTTPS – because captive portals completely break TLS, but plaintext HTTP will result in a clean redirect to the portal, allowing the network service to detect the presence of the portal and to bring up a browser window to let the user authenticate.

(https://devblogs.microsoft.com/oldnewthing/20221115-00/?p=10...)

I can see no reason why HTTPS is needed in any event. It's a single purpose domain that serves a static text file which everyone knows the content of.

[rkagerer]

Yeah, and there's also no guarantee the computer's certificates are even up to date (eg. first time you connect a PC after a fresh install off older media)

[silisili]

Why not just fire off a DNS request ? Not blocked by captive portals, and you get free caching.

[c0nsumer]

You've got it exactly. This is also part of Windows captive portal detection, which makes what you say even more important. HTTPS would actually be a step backwards here.

[eightysixfour]

I realized a while back that msftconnecttest.com is the domain it uses to check online status, and is the domain it checks in the background that gets redirected to wifi captive portals and pulls up. Any time I have an issue with a captive portal, I use that domain and the redirect works, because I know any other URL with end up with a certificate issue and I won’t be able to get to the portal.

[fegu]

This is why neverssl.com exists. I always use that when I need the login page of a wifi.

[Kuinox]

http://example.com will forever be http.

[sweatypalmer]

The comments explain why, common web login pages would fail otherwise.