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 <hidinginthe...@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
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
