Hacker News Reader

Comment by jasonzemos | Hacker News Reader

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

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.

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)

This is why (until very recently) Windows updates are distributed over HTTP - the only benefit of TLS is real-time error checking (and only because there are stateful HTTP proxies that can mangle files).

Also no guarantee the computer's clock is set ballpark accurately (which TLS requires), which can be relevant if Windows is checking for Internet connectivity before (for example) using NTP to update the computer's clock.

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

> and you get free caching

Mayeb that's the problem?

Howso? You still need internet access to hit the recursive.

Mindless routers (which are frighteningly many) that cache the results and won't show the true state of upstream connection, which is an important thing. There are a lot less transparent HTTP proxies that wouldn't respect no-store than mindless routers trying their best to cache results.

Don't need internet access to read a cached record from a DNS service on localhost, on the LAN, etc.

Unless you know what the DNS request is "supposed to return", you can't know that just getting any DNS response indicates that you have full Internet connectivity.

They control the record contents just as they would some text in a file on some server, and could be checked in a similar manner.

Sorry, you were imagining the use of a TXT record (I assume) and that would work better than an A record inquiry that I was considering.

It still wouldn’t find http filtering, but it would work better than I initially gave it credit. (I still doubt it would give a contextually correct answer for an airplane wifi connection [where DNS May very well work but few other services do if not paid].)

The whole point is to determine if you have full internet access, so you want to make sure that an HTTP request returns the data you're expecting. You may be able to get DNS responses but not have full internet access, like when on a public wifi that redirects all requests to a login page.

What is "full" Internet access?

I mean really, what does it mean to you, or to Windows, that I have "full" access to the Internet?

For me personally, I only visit a few walled gardens, so as long as I had my Google, my Wikipedia, and my work-related sites, I wouldn't miss 99.99% of the Internet anyway.

But what if your ISP blocks a whole bunch of ports? What if Adware has taken over 33% of your DNS space? What if you're behind a Great Firewall of <Dictatorship>? What if there's some sort of Balkanization or segmentation of your side of the 'net and you can't reach a lot of stuff? What if Cloudflare's down again?

Yes, "full" internet access is a hard to define term and this simple test doesn't cover all possible cases. But it will work in probably 99.99% of cases and honestly I think that's good enough. If it doesn't work you end up with a little "no internet connection" icon in your taskbar and that's about it. You can still use the connection, so I don't think it's a big deal that this test isn't 100% accurate. It's still more useful to the majority of users to have a slightly inaccurate test than to have no test at all.

They do, if you look at the docs Raymond linked that's actually the first step.

However that doesn't tell you about the presence of a portal or if HTTP traffic is actually possible.

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.

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.

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

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

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

Reply on news.ycombinator.com