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

Thomas Peterson <hidinginthebbc@gmail.com> Tue, 02 April 2019 09:27 UTC

Return-Path: <hidinginthebbc@gmail.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D71200B5 for <captive-portals@ietfa.amsl.com>; Tue, 2 Apr 2019 02:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lfYN3NHybpu for <captive-portals@ietfa.amsl.com>; Tue, 2 Apr 2019 02:27:17 -0700 (PDT)
Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C461200B4 for <captive-portals@ietf.org>; Tue, 2 Apr 2019 02:27:17 -0700 (PDT)
Received: by mail-wm1-x32b.google.com with SMTP id v14so2753298wmf.2 for <captive-portals@ietf.org>; Tue, 02 Apr 2019 02:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=NyBJJFFAf9+MkFGWLzRZ38Lt7wvoN5vTTIY7n3xGFbA=; b=LItUyWAvyeAgB5XJpvXVP4Asmk3gYi3GLNbI8Lrvw8ut5OI15BLVGHjHbZ1AvUIXKw gbsQZRwAuUhNUr7rT58a7JHr+vYbsRdW3qiC16HLexIm9WCwfn/DXYT0uaiiYqWr88B/ w7kcdgNzIdG47ihv5PS23hl7N7WAOmYQ3d+d6iFQbGjQDr5jEEK9vWmEP1FidyCvE/YG 0pGD0o04ZnYqBs7dIARiSK84HIjMNrI16MIKTJzJ2jNgcfdzLRgzg1fC/dnm5mw/nws9 przciCWEMyFI0liwzJy4j3bkQTHxhcGB3RK4o20d3N8F+7sdbKjtP/h27KNlojfg4hQr 668g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NyBJJFFAf9+MkFGWLzRZ38Lt7wvoN5vTTIY7n3xGFbA=; b=H3sjG9dkyGS2EnhmiOxl5C4oEawJjZEBi+dEAIN0bUs/0ib/Vb9LSW0mZ9/kldD6uV diqAd9lTmCMmFgXSHpYUetAhJ7ffUT/w+g13i3M6iKmSRrmnMYFlhIL0LJB7ELuGhpmm nXLPihkmHcL/6+2nHTThMjY+oB/Y2Y6jGnP16lDEy/lMRzEI4KioYLNwVZTJ0oTMAegP ncw5dXJ/UDkzCGbUW51w9MgKoBqH3H09iYxPxNeD95QGCR7H1EAYtzNamhk8nJMxcvlr 2xL4j5/k1M2RDAZj4gFuF3/6XMGHatjjZ5/nC1s6mJl3RPzcOvJ6NtMB+obpwYrn7bEB N4iw==
X-Gm-Message-State: APjAAAW9VTo+vMvYIIJ1dzoNQUJp7vYCqCYshjmiyirIzULd3xazmBly fC3tBNBGZTEjjcESSpjzvLE2A3bV
X-Google-Smtp-Source: APXvYqwJ/VRkuTJF9NDv80ZLPQ+5j0i8Yp7p8gvpzwPRempjYUjbdFWl2Q/6q1S3XKU+af65R3PPFw==
X-Received: by 2002:a1c:6c09:: with SMTP id h9mr2819702wmc.130.1554197235039; Tue, 02 Apr 2019 02:27:15 -0700 (PDT)
Received: from ROADKILL.local ([132.185.158.37]) by smtp.gmail.com with ESMTPSA id j7sm14180170wrt.96.2019.04.02.02.27.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 02:27:14 -0700 (PDT)
To: Dan Wing <danwing@gmail.com>
Cc: captive-portals@ietf.org
References: <fc21fb49-1408-9169-6c71-dc57c273b824@gmail.com> <221D6FA1-BBE6-4954-80D6-B3B549079A1F@gmail.com>
From: Thomas Peterson <hidinginthebbc@gmail.com>
Message-ID: <e025a320-83a5-f562-49b8-a80f7ca243b9@gmail.com>
Date: Tue, 02 Apr 2019 10:27:12 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <221D6FA1-BBE6-4954-80D6-B3B549079A1F@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/XdDVJi2VAS_HAWpF7YOAElljBYQ>
Subject: Re: [Captive-portals] Any other existing detection methods?
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2019 09:27:19 -0000

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

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.).
>
> -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