[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


0: https://github.com/capport-wg/architecture/pull/26/files#diff-ae7561d353e2851c8cac706fb1827bd2R871
On 01/04/2019 22:42, Dan Wing wrote:
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.).


On Apr 1, 2019, at 8:52 AM, Thomas Peterson <[email protected]> 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.


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

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

Captive-portals mailing list
[email protected]