Subject: [Captive-portals] Any other existing detection methods?

From: Thomas Peterson <[email-masked]>
Date: Mon, 1 Apr 2019 16:52:38 +0100

A recent pull request[0] for the architecture document contains a new 
appendix describing known methods devices may use to detect a captive 
portal. Two of the ways I have found are DNS and HTTP based.

Are the any other means that clients use to detect captive portal 
presence besides what I have described? Wikipedia lists ICMP redirect[1] 
as a means, but I have been unable to find documentation from a vendor 
to support this.

Regards

0: https://github.com/capport-wg/architecture/pull/26

1: https://en.wikipedia.org/wiki/Captive_portal#ICMP_redirect

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Apr 2019 14:42:14 -0700

Text in the PR is unclear if it intends to be normative ("This check should not be secured with TLS") or is discussing why TLS isn't used.  In my view, the hostname mismatch is a strong indicator the captive portal is intercepting the connection; in fact, that's exactly what my mail user agent complains about when my OS fails to detect the captive portal.  This failure occurs because captive portals purposefully return the "expected text", in order to fool the OS into displaying a WiFi "connected" indicator (the "pie") in the hopes the user will launch a non-restricted browser and view an un-encrypted HTTP page.  Which is a faint hope in 2019 with nearly every page being HTTPS and with non-browser applications that may launch first (e.g., mail user agent, Facebook, Instagram, WhatsApp, etc.).

-d

> On Apr 1, 2019, at 8:52 AM, Thomas Peterson <[email-masked]> wrote:
> 
> A recent pull request[0] for the architecture document contains a new appendix describing known methods devices may use to detect a captive portal. Two of the ways I have found are DNS and HTTP based.
> 
> Are the any other means that clients use to detect captive portal presence besides what I have described? Wikipedia lists ICMP redirect[1] as a means, but I have been unable to find documentation from a vendor to support this.
> 
> 
> Regards
> 
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Thomas Peterson <[email-masked]>
Date: Tue, 2 Apr 2019 10:27:12 +0100

Thanks for your feedback.

The language is specifically trying to be non-normative and a previous 
edit had the quote you mentioned, but was subsequently replaced[0]. I'm 
unsure if there is any implementation that considers hostname mismatch 
is presence of a captive portal as there are other possible scenarios 
such as malicious middlebox that is not the captive portal, or 
misconfigured network.

Regards

0: 
https://github.com/capport-wg/architecture/pull/26/files#diff-ae7561d353e2851c8cac706fb1827bd2R871