Re: [TLS] Captive portals, "access administratively disabled" and alert messages

Eric Rescorla <ekr@rtfm.com> Tue, 02 January 2018 19:38 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8766612D834 for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 11:38:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 upH_O8SNGcvK for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 11:38:40 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 AAE201200C1 for <tls@ietf.org>; Tue, 2 Jan 2018 11:38:40 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id g191so12224229ywe.7 for <tls@ietf.org>; Tue, 02 Jan 2018 11:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F6Shi2PeTIZOdIsCpNTIM3wzXdg9ZyIGUJScVd51R1k=; b=NvBM0GzUniUgD3jUC+vh5ff4jF63sNDr1V9fYC2jBBjdVQMF8hzJ1sYYOQtiAxdxfY +7VIw8zGGRZOFchhbgPpEQYKFrPHLNox/1RMEWgQfClw5y1L+uns5Oe3V7co0eGpcp0W Z4My4z/7saEHYmK1iGd1cCaPnKzpr6My3rUCLcBQ096mBMkkG06Ohgps+iHg6bHtH+lI 0pX2s5qIzzXN4dNM+kDfNwCRfnlUTRyMv1fKE+7y3aFoym38IAA7pNx2jVu/SFuQwa98 GIxDkj7keGUW7OIplpXIoXh/GVHmlGzDiJuoHY9ct+t9gNgot4WhczxsTCAs77aGkUtP vh9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F6Shi2PeTIZOdIsCpNTIM3wzXdg9ZyIGUJScVd51R1k=; b=YpMSuR/zMOVywDd4tYzBYjLqkHpm7PqpZarc6ld3gGH5A4tDDcUpjl0W6MBpI1ebzn APY6OERNbdhW3d+RJ7LsblEk8z+8HgntOcZ8YG9vWfn5l2XhZABSXwHhYbLLnO4EYAwM R9O2Mlp9HZpnACETTh7fkFcfmou9z6yiXZOyRdjjx9vdf1Qm1Q7B7jLW5JC1RdtIOZxc 31wJMBwum01wGUJtbgCfC7JHq+FbSAOoipXaUGu/EQcOpUO87QO4oXH2rj2FTRPOl0VN najdHFggVW1cOKzvHwS2n1QYzOAmG81b0QTlLuP6JNzehUPieye+FFfZuxnlBz3iTCEv f8pQ==
X-Gm-Message-State: AKGB3mJzxAV/ZAGszkwyTs3HWlz0Cn7vzqzX8jgO/DSG6AZf6B+/Jwm9 ui4B9emG1P5CSUaRASq/5QaPOS+WI9mvfpd9bNxRUg==
X-Google-Smtp-Source: ACJfBotFYmEbekp3J2ybDjBxVsah3HV9OQcTklPHf3mSRiRpMJkAjjhkjkqnDPIoybXSGCpgkEHu1Y9V/iSjNgaV5z4=
X-Received: by 10.129.154.22 with SMTP id r22mr33049670ywg.296.1514921919799; Tue, 02 Jan 2018 11:38:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 11:37:59 -0800 (PST)
In-Reply-To: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl>
References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 2 Jan 2018 11:37:59 -0800
Message-ID: <CABcZeBOYH5sFszpTVbTyp8kYtmhqCX+_TJN9ofW5vuUMx50KRg@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0bb4e8e473e40561d03e8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h4nFhbcM_UFFB3rnjYysMo_1frM>
Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jan 2018 19:38:44 -0000

A similar idea was proposed a while back, albeit with simpler semantics:

  https://tools.ietf.org/html/draft-lemon-tls-blocking-alert-00

Discussion here:

  https://www.ietf.org/mail-archive/web/tls/current/msg20264.html

I'm not really enthusiastic about any of these ideas for any of the
administratively prohibited
use cases because the information being provided to the user is
unverifiable. I.e., this
just tells you that someone on the network didn't like it, but the message
itself is just
an assertion (this is different from 451 in that that's provided inside the
TLS channel
if TLS is used). It's not like, for instance, the browser should display
the string to the
user as if it were true.

The captive portal case seems a bit more plausible, in that it can be
machine processed
by the client to do some sort of captive portal detection thingy (e.g.,
connect to
a site over HTTP). However, the right place to bring this kind of proposal
would probably be
CAPPORT (https://tools.ietf.org/wg/capport/). However, I see that they are
pursuing
a different direction based on HTTP.

-Ekr




On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:

> Hello,
> OpenDNS by default blocks websites that are used for phishing and
> optionally
> other sites as configured by the deployer. It does this by DNS poisoning:
> it
> responds with a forged A or AAAA response that redirects to their server.
> An
> example website blocked by OpenDNS in this manner is
> https://internetbadguys.com/.
>
> When OpenDNS blocks a website that is served by HTTPS, the user is
> presented
> with a "Certificate Error" message. To see what happened, she then has to
> accept
> the incorrect certificate or visit the plain HTTP version of the webpage.
> This
> creates some problems: aside from a bad user experience, it makes users
> accustomed to ignoring certificate errors.
>
> Another problem is created by captive portals: networks that use "a web
> page
> which is displayed to newly connected users before they are granted broader
> access to network resources." (Wikipedia).
>
> This could be solved by specifying two new values of AlertDescription:
> access_administratively_disabled and captive_portal as well as a new
> field to
> struct Alert: alert_message.
>
> Let alert_message be a fixed-length UTF-8-encoded string. It would be only
> valid
> for
>         (description == access_administratively_disabled
>         ||
>         description == captive_portal)
> and otherwise a client would HAVE TO ignore it. It would be plain-text for
> simplicity, shortness and security. It would be null-terminated and then
> randomly padded to a size of perhaps 100 bytes. A TLS client would HAVE TO
> filter the message for any odd characters, invalid UTF-8 sequences, etc.
> as will
> be specified in the standard.
>
> Greetings,
> Mateusz Jończyk
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>