Re: [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)

Ben Schwartz <> Fri, 15 March 2019 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97977130F29 for <>; Thu, 14 Mar 2019 20:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MyV0DX5HUnjA for <>; Thu, 14 Mar 2019 20:01:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70FA8129524 for <>; Thu, 14 Mar 2019 20:01:08 -0700 (PDT)
Received: by with SMTP id s15so2653646uap.6 for <>; Thu, 14 Mar 2019 20:01:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vAv0/eT35i5P1OlsMgsGv6Y55BBKlSyzNZRDzlppXy0=; b=iZiQPIsKc/YgSpyddPucsE3LvJCxP0AdBXijVRaUR6vz82KlsFBlhc6BGeXrnCGNMt izqUjr3rPuVwhukqq+uXE8sE+rgMYVnCyll0L5n79qdB3ZQy7j13U659XYky2LRjnW5F RNCReL+cPtOAHUFBF3iJDaKpfZ/QC3LGYmwiutlfTxkd1zjupx1T7Q60KFOwB0cTrQaD v8B3yd8A/b28QCtB+gxR12frsJA0TvRqfyuxQEHpukTwFw3UnvbMMzmGutDyPAcWYtz4 NGTgg4M/6nHPE9iUVeTzjKkaPCVtHp4X606APoIkb4FahIWWQfW7Uz/dn5QoAnrnTeet BuRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vAv0/eT35i5P1OlsMgsGv6Y55BBKlSyzNZRDzlppXy0=; b=pe6HPSWtzgJrs7zvAJeKPiDuzOddsG9FVslZSOhErRH/Uv3DYehEMOYvyyxHhvJyDJ BxFw+hntnvi6X8PIUpTydBXziF6S+MVTshaoZpnOkQwMWRcTvHeFfceyWA9rxQWUjCk4 iqAT7BzhYJd4DHGAMJQ7uMmcAumDUMPlz1zT7cBFrra+OQ21gvFs5Efqs8l8BS5pv/jW 5OYa8EyVo3OoksZ6Yqv6hKZe2S00sZiPbThlwpuwW5QO3vGFDdGJnJNPU7o3rZvsAC1b DeMhCSkkhd48TdjVxxXmYBs/kEUYerqf75ofVrzQAu+7afCcUeQ5rkREWuq4VhLiixNN mn3g==
X-Gm-Message-State: APjAAAVs/nHhL195u0PRkg9HcaSsjiankZAnrOBKczhvmDi/2PylBCRU Sc5sTv5Hl2bWx6CCPXxIJlUVw1FSGmcV97aHP10ROwN3fio=
X-Google-Smtp-Source: APXvYqwQt62JFkLCDuQr+Q2qMR7V9nMExyY4DjnBOoVIENVUo+6FceOpqz95V0iFhkO+CMszZ+nMpvlEJr/0ED1fYUc=
X-Received: by 2002:ab0:6819:: with SMTP id z25mr7685160uar.0.1552618867189; Thu, 14 Mar 2019 20:01:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 14 Mar 2019 23:00:56 -0400
Message-ID: <>
To: Martin Thomson <>
Cc: DoH WG <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000138e350584194088"
Archived-At: <>
Subject: Re: [Doh] Captive portals (was Re: suggested slides for IETF 104 on draft-reid-doh-operator)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2019 03:01:12 -0000

On Thu, Mar 14, 2019 at 10:22 PM Martin Thomson <> wrote:

> Thanks for sharing the slides Jim,
> (As an aside, the parallels between your summary of the draft and
> draft-mm-wg-effect-encrypt are striking.)
> There are lots of *things* on your list, but maybe it would help to look
> at a few in more detail to see what they teach us.  I happen to chair a
> working group that is tasked with improving the captive portal situation,
> so I thought I'd start there because it's first on your list too.
> The first thing I observe is that the story could be different depending
> on where the remote resolver is configured.  In particular, whether you
> consider the configuration of an remote, encrypted resolver to be
> system-wide or per-application.
> Captive portal detection is typically done at a system level, and so the
> system-wide configuration would seem to be most relevant to this particular
> issue.  That is, unless the network manages to successfully evade the
> various captive portal detection mechanisms in the hopes that they can
> somehow present information in the browser, which I'll get back to.
> As I've learned, operating systems typically use very different network
> configuration during the captive portal detection phase, and most won't be
> applying encrypted DNS policies until they have first validated the network
> is "usable".  So I would expect that even if the operating system is
> configured to use an encrypted DNS service other than the one the network
> provides, it would still use the network-provided service while it is
> bootstrapping.  For instance, I understand that Android uses the network
> resolver to discover the IP address of its DoT/DoH resolver (Ben can
> probably clarify/correct me here).

Yes, if the user has specified a DoT resolver, Android resolves that name
through the network's default DNS server.  Specifically, Android simulates
a parallel version of the network configuration that is used for captive
portal login and DoT bootstrap, but is not accessible to normal apps.  This
version may be used even after login succeeds, in order to handle "captive
portal snapback" (e.g. session expiration).

The Chrome team has also been prioritizing correct functioning with captive
portals on all supported platforms.  I don't foresee DoH implementation
causing any significant regression.

> If the network decides to evade captive portal detection, then it is
> playing roulette.  Most applications now use authenticated connections to
> services, and so do many websites.  A DNS redirection is no more effective
> in these circumstances than a port 80 interception[1].  The application
> detects the "attack" and throws up errors.  That can lead to the operating
> system concluding that the network is broken if applications report these
> errors.  If you are lucky and it is a web browser that first makes a
> connection and that connection is to a site without HSTS, then the network
> gets a chance to show a web page.  I shouldn't need to quote stats on app
> vs. browser usage and proportion of HTTPS on the web to make it clear that
> this playing this game has increasingly bad prospects.
> If this is a per-application configuration, then only those applications
> that are configured to use remote, encrypted resolvers are affected.  They
> fail to get the modified DNS results, but all the other problems still
> exist.
> That makes me conclude that captive portals aren't any worse off as a
> result of operating systems or applications choosing to configure their own
> encrypted resolver service.  Given that using DNS for captive portals is
> worse than alternative methods[1], I'd suggest that we not concern
> ourselves with this particular problem.
> Cheers,
> Martin
> [1] Spoofing DNS results for captive portals poisons the cache, which
> makes DNS rewriting a bad choice for this use case.  This is - in part -
> why most captive portals intercept TCP on port 80 and spoof an HTTP 302
> instead.  And if you consider DNSSEC-validating endpoints, that would be
> another reason not to spoof DNS... if those existed in any significant
> numbers.
> On Fri, Mar 15, 2019, at 03:39, Jim Reid wrote:
> > Here’s what I plan to present at the WG. Please comment on the list if
> > you have questions or suggestions.
> _______________________________________________
> Doh mailing list