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

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 <hidinginthebbc@gmail.com> 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
> 
> 
> 0: https://github.com/capport-wg/architecture/pull/26
> 
> 1: https://en.wikipedia.org/wiki/Captive_portal#ICMP_redirect
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals