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

Mateusz Jończyk <mat.jonczyk@o2.pl> Tue, 02 January 2018 21:40 UTC

Return-Path: <mat.jonczyk@o2.pl>
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 5666C1276AF for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 13:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 T6HjtNJpt485 for <tls@ietfa.amsl.com>; Tue, 2 Jan 2018 13:40:10 -0800 (PST)
Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 E701C126CBF for <tls@ietf.org>; Tue, 2 Jan 2018 13:40:09 -0800 (PST)
Received: (wp-smtpd smtp.tlen.pl 20984 invoked from network); 2 Jan 2018 22:40:07 +0100
Received: from ceh60.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.30.183.60]) (envelope-sender <mat.jonczyk@o2.pl>) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-SHA encrypted SMTP for <mellon@fugue.com>; 2 Jan 2018 22:40:07 +0100
To: Eric Rescorla <ekr@rtfm.com>
References: <096449a4-38fc-e17f-d995-a584f976b422@o2.pl> <CABcZeBOYH5sFszpTVbTyp8kYtmhqCX+_TJN9ofW5vuUMx50KRg@mail.gmail.com> <5e9e9357-2031-9cc9-4ee7-10865e562184@o2.pl> <CABcZeBPBCBtMioG7hcVLxMDO+K_A=oYa8LvD4AQm8Q5tzV4QSg@mail.gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Ted Lemon <mellon@fugue.com>
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
X-Enigmail-Draft-Status: N1110
Message-ID: <9356637a-09b1-1074-86b6-15e9d1f00c1f@o2.pl>
Date: Tue, 02 Jan 2018 22:40:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBPBCBtMioG7hcVLxMDO+K_A=oYa8LvD4AQm8Q5tzV4QSg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-WP-MailID: 82c83d3f094f26830790cac9155d319f
X-WP-AV: skaner antywirusowy Poczty o2
X-WP-SPAM: NO 000000A [sXPk]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WWzNNrrHpy_kEJv4I_48G2HL15c>
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 21:40:12 -0000

CCing Ted Lemon <mellon at fugue.com> as the author of previous proposition.

W dniu 02.01.2018 o 21:20, Eric Rescorla pisze:
> On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk <mat.jonczyk@o2.pl
> <mailto:mat.jonczyk@o2.pl>> wrote:
> 
>     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.
Not any more then they ignore certificate warnings [2].
>
>     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.
> 
But when the user will ignore the certificate warning (which many users will do
[2]), they will see a site with attacker-controlled information anyway. And it
is better not to make users used to ignoring certificate warnings.

An attacker that can perform full MITM can always try to phish the user. Even a
captive portal detection could be fraudulent (and redirect the user to a
fraudulent site).

There was an attack [1] that changed DNS settings on a router and then
redirected all websites to a site that claimed that a "router upgrade" is
required. This fraudulent site than phished the users to download and run an
.exe file to "upgrade the router". Needless to say that this .exe file contained
a virus (in this case a keylogger).

In this case, how could the absence or presence of the proposed feature change
anything?

Greetings,
Mateusz

[1]
https://zaufanatrzeciastrona.pl/post/uwaga-na-niebezpieczne-ataki-na-uzytkownikow-ruterow-tp-link/
(in Polish, this attack was limited to Poland so there is no English version AFAIK)
[2] http://adrifelt.github.io/sslinterstitial-chi.pdf