5 ms·

I've run into issues with using public wifi when I override my MacBook's DNS server to 1.1.1.1 or 8.8.8.8. I believe this is because captive portals require cu

I've run into issues with using public wifi when I override my MacBook's DNS server to 1.1.1.1 or 8.8.8.8. I believe this is because captive portals require custom resolution of the name captive.apple.com. And external DNS servers will not resolve that correctly to the local gateway's authorization page.

brians 2mo ago
That’s a Mac bug if so—it should be always using dumb udp/53 for captive detection, not some fancy DoH thing.
MayeulC 2mo ago
AFAIK (at least it worked like that some 10 years ago) the captive portal just intercepts the HTTP page load and inserts its own content (most often a 302). So it just has to be a http web page. Firefox uses http://detectportal.firefox.com/canonical.html http://detectportal.firefox.com/canonical.html Relevant support page, though light in details: https://support.mozilla.org/en-US/kb/captive-portal https://support.mozilla.org/en-US/kb/captive-portal Edit: ah, yes, DNS can be hijacked too (requires intercepting outgoing traffic on port 53 therefore incompatible with DoH), that may require fewer computing resources. Still need http otherwise the server cannot use the correct cert chain. Edit 2: Wikipedia says both methods are used: https://en.wikipedia.org/wiki/Captive_portal https://en.wikipedia.org/wiki/Captive_portal and also mentions RFC 8910. I suspected something like that existed, hence my initial disclaimer. My point was: that domain is not treated any differently from other domains.
- fc417fc802 2mo ago
  Can we take a minute to appreciate how utterly broken this state of affairs is? The dogged over centralization of DNS is an endless source of problems.
- comprev 2mo ago
  I've had reliable success by using http://neverssl.com http://neverssl.com to force a basic HTTP connection for kickstarting a public WiFi portal login, although I have to disable NextDNS (iOS) too.
  - Sohcahtoa82 2mo ago
    The ironic part of neverssl.com is that it does indeed now support SSL.
  - bpicolo 2mo ago
    I use good ol example.org
deathanatos 2mo ago
Dumb captive portals, which do still exist in some places, usually do MitM attacks on the connection, so you need some http(no-s) site that you can abuse as "yeah, this can get attacked by the WiFi" to then answer the portal. The right way is that there's DHCP option for the network to signal "I have a captive portal", that's been standardized for over a decade. … or … IDK … just stop shoving ads down people's throats just because they want WiFi.
- jcgl 2mo ago
  I’ve never even heard of the DHCP option for this. How widely adopted is it? It’s surprising to hear it called “the right way” when it wouldn’t work for a single-stack IPv6 (or IPv6-mostly, probably) network.
  - deathanatos 2mo ago
    DHCP works over IPv6, but there's also a corresponding RA option, too, if your v6-only network doesn't use DHCP. https://www.rfc-editor.org/info/rfc8910/ https://www.rfc-editor.org/info/rfc8910/ is, I think, the latest version of the standard.
    - jcgl 2mo ago
      Ah great, thanks for the link! A very clearly-written RFC.

brians 2mo ago

That’s a Mac bug if so—it should be always using dumb udp/53 for captive detection, not some fancy DoH thing.

MayeulC 2mo ago

AFAIK (at least it worked like that some 10 years ago) the captive portal just intercepts the HTTP page load and inserts its own content (most often a 302). So it just has to be a http web page. Firefox uses http://detectportal.firefox.com/canonical.html http://detectportal.firefox.com/canonical.html Relevant support page, though light in details: https://support.mozilla.org/en-US/kb/captive-portal https://support.mozilla.org/en-US/kb/captive-portal Edit: ah, yes, DNS can be hijacked too (requires intercepting outgoing traffic on port 53 therefore incompatible with DoH), that may require fewer computing resources. Still need http otherwise the server cannot use the correct cert chain. Edit 2: Wikipedia says both methods are used: https://en.wikipedia.org/wiki/Captive_portal https://en.wikipedia.org/wiki/Captive_portal and also mentions RFC 8910. I suspected something like that existed, hence my initial disclaimer. My point was: that domain is not treated any differently from other domains.

fc417fc802 2mo ago
Can we take a minute to appreciate how utterly broken this state of affairs is? The dogged over centralization of DNS is an endless source of problems.
comprev 2mo ago
I've had reliable success by using http://neverssl.com http://neverssl.com to force a basic HTTP connection for kickstarting a public WiFi portal login, although I have to disable NextDNS (iOS) too.
- Sohcahtoa82 2mo ago
  The ironic part of neverssl.com is that it does indeed now support SSL.
- bpicolo 2mo ago
  I use good ol example.org

deathanatos 2mo ago

Dumb captive portals, which do still exist in some places, usually do MitM attacks on the connection, so you need some http(no-s) site that you can abuse as "yeah, this can get attacked by the WiFi" to then answer the portal. The right way is that there's DHCP option for the network to signal "I have a captive portal", that's been standardized for over a decade. … or … IDK … just stop shoving ads down people's throats just because they want WiFi.

jcgl 2mo ago
I’ve never even heard of the DHCP option for this. How widely adopted is it? It’s surprising to hear it called “the right way” when it wouldn’t work for a single-stack IPv6 (or IPv6-mostly, probably) network.
- deathanatos 2mo ago
  DHCP works over IPv6, but there's also a corresponding RA option, too, if your v6-only network doesn't use DHCP. https://www.rfc-editor.org/info/rfc8910/ https://www.rfc-editor.org/info/rfc8910/ is, I think, the latest version of the standard.
  - jcgl 2mo ago
    Ah great, thanks for the link! A very clearly-written RFC.