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

JW <jw@pcthink.com> Tue, 02 January 2018 20:01 UTC

Return-Path: <jw@pcthink.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 BB7B012D82F for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 12:01:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 sYW5Uv5LSy6t for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 12:01:55 -0800 (PST)
Received: from atl4mhob19.registeredsite.com (atl4mhob19.registeredsite.com [209.17.115.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC97212D80E for <tls@ietf.org>; Tue, 2 Jan 2018 12:01:54 -0800 (PST)
Received: from mailpod.hostingplatform.com ([10.30.71.209]) by atl4mhob19.registeredsite.com (8.14.4/8.14.4) with ESMTP id w02K1pF4013734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <tls@ietf.org>; Tue, 2 Jan 2018 15:01:52 -0500
Message-Id: <201801022001.w02K1pF4013734@atl4mhob19.registeredsite.com>
Received: (qmail 27972 invoked by uid 0); 2 Jan 2018 20:01:51 -0000
X-TCPREMOTEIP: 73.251.233.169
X-Authenticated-UID: jw@pcthink.com
Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 2 Jan 2018 20:01:51 -0000
SavedFromEmail: jw@pcthink.com
Date: Tue, 02 Jan 2018 15:01:48 -0500
In-Reply-To: <CABcZeBOYH5sFszpTVbTyp8kYtmhqCX+_TJN9ofW5vuUMx50KRg@mail.gmail.com>
Importance: normal
From: JW <jw@pcthink.com>
To: Eric Rescorla <ekr@rtfm.com>, =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: jw@pcthink.com, tls@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_6924514054049550"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/3ixQYp91wp8CCI5pIldkcLT6YeQ>
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:01:58 -0000

Hi,
My colleagues and I are currently pursuing a TLS extension to address a very similar scenario.  It is good to see we are not alone in this pursuit.
We are still working out details at a somewhat high level but expect to have a draft out shortly.  Please feel free to contact me if you would like to be included in our discussions.

Thanks,John Woodworth
-------- Original message --------From: Eric Rescorla <ekr@rtfm.com> Date: 1/2/18  2:37 PM  (GMT-05:00) To: Mateusz Jończyk <mat.jonczyk@o2.pl> Cc: tls@ietf.org Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages 
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 prohibiteduse cases because the information being provided to the user is unverifiable. I.e., thisjust tells you that someone on the network didn't like it, but the message itself is justan assertion (this is different from 451 in that that's provided inside the TLS channelif TLS is used). It's not like, for instance, the browser should display the string to theuser as if it were true.
The captive portal case seems a bit more plausible, in that it can be machine processedby the client to do some sort of captive portal detection thingy (e.g., connect toa site over HTTP). However, the right place to bring this kind of proposal would probably beCAPPORT (https://tools.ietf.org/wg/capport/). However, I see that they are pursuinga 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