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

[Ben Schwartz <[e-mail]>]

On Thu, Mar 14, 2019 at 10:22 PM Martin Thomson <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>