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

Eric Rescorla <ekr@rtfm.com> Tue, 02 January 2018 20:21 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 15A6E127077 for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 12:21:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] 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 awH-nVWByf2z for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 12:21:25 -0800 (PST)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 A9445127076 for <tls@ietf.org>; Tue, 2 Jan 2018 12:21:25 -0800 (PST)
Received: by mail-yb0-x234.google.com with SMTP id w1so19119640ybe.10 for <tls@ietf.org>; Tue, 02 Jan 2018 12:21:25 -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=DzwmzM4zLpDWK8QZMzKoChrnYHTNSUj3yBj0hrV5O/o=; b=mlzM7fsGgwrCjZs5AAsD27+5mQCpN39owOJbG3WBGBIMCBu0p0Q7f3aGFYHb+DeUMP jN9X4/xZ0zeB0F1fYyK8qRNS3CK/iOMz86rzpYf6yGagQf8lxxSo9ciaXHQwrhLXO7h8 wKaUEA+VYaEsjaSkyJK31rzpRweTHSrNNdq0Wbd4FY9fwqGbCxwkW93D7QpjeXWJdNVF MEU1nQN6Yd+Rs3sGyCcJmOQg5za89Wo9GY8wxsvFRwg2KPOQA5dvKigUorqOcFFSKnu3 Ndl9pQtm3LGDqDwvlaMQINZmItEb5cZcdgNu9dB7F1DgOJ2B+JE1SfPeChLIHfFgwUR1 PitQ==
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=DzwmzM4zLpDWK8QZMzKoChrnYHTNSUj3yBj0hrV5O/o=; b=lWXMMDKjnW1qcjH791+SHpbm+sZ1OwEDZ+MplRQkZlzIXc00OE5pPcGQ5U8sUl74yQ dOstbpMkVNd65F0GMVWJSwBTn5Fgmdb1+wFUb0EWf2Kk6SKUkP9oGetEhljNf2BQZR4Y 5EELuj8scSuVOmP/GqxGjU2dpnGPgNvuCMTwsUpqG8Rmch6yX55ttnu8PNfnse0em8lR B2UaEf8yyuDVhs/FpRWvHZgHYgmsIc/LCgSNYhQDhKMR7g3qFDGG9UR/tboPGqeH7TIf kyqpKk9aMDB9yBUWKdyhN5YV7JiWb5CMmqhH/X57dEj+Nlty7xjzXXVzXZu+2YC0IjsC 074A==
X-Gm-Message-State: AKGB3mIGn1rs9Jw4yYA/2i/CgGvVadi7xeh1S5obdcGNude99N79OzFz s2e8+vNU1ypYonP1+Rb2+BeKFwPE/8yGz3q5GbXRZA==
X-Google-Smtp-Source: ACJfBovlJinsDwSyWhK4bMA3pxsY4iPzl+n7e9WYzY5tr3zXlP63xYjpm0hzcMLo/J5Qbj+dxcxHrAI6xCV8I7Hf79w=
X-Received: by 10.37.78.212 with SMTP id c203mr17344175ybb.423.1514924484739; Tue, 02 Jan 2018 12:21:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 12:20:44 -0800 (PST)
In-Reply-To: <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl>
References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <CABcZeBOYH5sFszpTVbTyp8kYtmhqCX+_TJN9ofW5vuUMx50KRg@mail.gmail.com> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 2 Jan 2018 12:20:44 -0800
Message-ID: <CABcZeBPBCBtMioG7hcVLxMDO+K_A=oYa8LvD4AQm8Q5tzV4QSg@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113e7f86c65abc0561d0d790"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3Zn0fK1wdmew-ZMexiN9U3tWLRE>
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 20:21:28 -0000

On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk <mat.jonczyk@o2.pl> wrote:

> Hello,
> Thank You for reviewing my email.
>
> W dniu 02.01.2018 o 20:37, Eric Rescorla pisze:
> > 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.
>
> Then the browser should display a message inside the warning screen that
> the
> string cannot be trusted.


Users tend to ignore that kind of warning.


> This is no less secure then an alternative: a TLS
> certificate error that conveys no message to the user whatsoever.
>

No, I don't believe that that's correct, because the certificate warning
does not
contain attacker-controlled information.



> Additionally, error 451 is / could be currently typically delivered by
> network
> intermediaries. It is much more common that network intermediaries / ISPs
> block
> content than website providers do so. When the whole world will use HTTPS,
> there
> will be almost no use of error 451 whatsoever (apart from SSL MITM).
>

The point of the comparison to 451 is to examine the security properties,
not to say that 451 works particularly well.

-Ekr


> > 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
>
>
> Responding to a message from Brian Smith,
> <https://www.ietf.org/mail-archive/web/tls/current/msg20276.html>
> > Standardizing and implementing things like this signals, politically,
> that we
> > accept and even encourage censorship like we see in China and many other
> > places already in the world. That, on its own, makes this a non-starter.
>
> If so, then the document should specify that filtering is discouraged or
> something similar.
>
> Greetings,
> Mateusz Jończyk
>
> >
> >
> >
> >
> > On Tue, Jan 2, 2018 at 11:15 AM, Mateusz Jończyk <mat.jonczyk@o2.pl
> > <mailto: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 <mailto:TLS@ietf.org>
> >     https://www.ietf.org/mailman/listinfo/tls
> >     <https://www.ietf.org/mailman/listinfo/tls>
> >
> >
>
>