5 ms·
Is it a problem that the URL is not HTTPS or is it the blessing required to defeat it?
by jasonzemos 4y ago
Is it a problem that the URL is not HTTPS or is it the blessing required to defeat it?
- sweatypalmer 4y agoThe comments explain why, common web login pages would fail otherwise.
- YPPH 4y agoOne 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=107399#comment-139867 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 4y agoYeah, 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)
- zinekeller 4y agoThis 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).
- deleted 4y ago[deleted]
- moduspol 4y agoAlso 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.
- silisili 4y agoWhy not just fire off a DNS request ? Not blocked by captive portals, and you get free caching.
- iudqnolq 4y ago> and you get free caching Mayeb that's the problem?
- silisili 4y agoHowso? You still need internet access to hit the recursive.
- zinekeller 4y agoMindless 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.
- sk5t 4y agoDon't need internet access to read a cached record from a DNS service on localhost, on the LAN, etc.
- sokoloff 4y agoUnless 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.
- silisili 4y agoThey control the record contents just as they would some text in a file on some server, and could be checked in a similar manner.
- 4y ago
- c0nsumer 4y agoYou'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 4y agoI 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.