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

Ted Lemon <> Tue, 02 January 2018 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6B7412D84A for <>; Tue, 2 Jan 2018 14:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q6IW5E-ROWmK for <>; Tue, 2 Jan 2018 14:06:31 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C4AC1242F7 for <>; Tue, 2 Jan 2018 14:06:31 -0800 (PST)
Received: by with SMTP id a16so64887471qtj.3 for <>; Tue, 02 Jan 2018 14:06:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yK2ECUVx10NIGNk7ftCztKpGg5f9WF3GEgEV/iT+Ta4=; b=AvZZKgnei+yHCqV4toBM3c/WBtRTuA7MtyKu/AJq3oYvJ/09M2Exz59BlJkFXWO7G5 34qPZebfnV3ENBGMakLru37dlFErqhiZnM1ze+Q+JoKDAi+Ia3Dt2oV7mTtH/xqI5rCf JRJ9vPy3dHvNJmAjhJcPkqy3nlpD69jAsirVCrGkn/jMeZHIDcgZNst6ClCWS2k3ge0T O4ZnqUTb+f1f0D/wu360bpPUuasUSpu7Jmrre7pV97CIgn1aTaM4ZOB6H/4ySoQD+UmH Pt4PSw5Ac8VP/OhJzibs1VrlKLNQtZnidWL5qc09V9KgoGU/Doyvmrfxv1/0Ks1oioIV bqPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=yK2ECUVx10NIGNk7ftCztKpGg5f9WF3GEgEV/iT+Ta4=; b=UgW54FnwRP9/pdLfgs/WV4it2uGRwQkw7aL5YNGxYyfeI54VNEk3dD0qZDY4eMMoFz Hnf3ZMBmRsYDBMKVPzWz4ICVMeZil5Lug5hWWmU6GP7Ztft8Ewtqj4dLd4I4IIWrnfDR Cblukm8b0R0P671IiM+bNvMhqH23lWItaDnNyV1+NAHMzTdxa6iv0OX8r8xqTV/19ZYg nTIYkZA7Y1RPiZeaDJPV50nKo9+eYbiWkOSlF9Pl0Alj5aIWZ3a1fzS4mzO+kF7hjJpV jQ400uEiRxcQYvmeIDM4EM/TBZRCXFK7TaArWT4Zfa0/1rJQWyqcKe4JHEomek0gGpOn TGXQ==
X-Gm-Message-State: AKGB3mJ62HEN/Wy3anHCiTPJNMDwE7AINoZNLFdRYtFnMonOO0fbbIAo g1ywxS87ZFmKmsBl/AiG7lSrwA==
X-Google-Smtp-Source: ACJfBov4/DeKMnAdaIoeYIce4G/QUgc71G0luQCEnumxQpO6sJRMxodqUnbdiWynqV1DKmTJgGBjKw==
X-Received: by with SMTP id 20mr62431354qky.348.1514930790535; Tue, 02 Jan 2018 14:06:30 -0800 (PST)
Received: from cavall.lan ( []) by with ESMTPSA id h21sm29392441qte.44.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Jan 2018 14:06:30 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Ted Lemon <>
In-Reply-To: <>
Date: Tue, 2 Jan 2018 17:06:28 -0500
Cc: =?utf-8?Q?Mateusz_Jo=C5=84czyk?= <>, "<>" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [TLS] Captive portals, "access administratively disabled" and alert messages
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jan 2018 22:06:34 -0000

We had a conversation about this at a Boston IETF meetup last year; the consensus, with which I agree, is that simply adding TLS alerts isn't good enough, for (essentially) the reason you stated earlier: we have no way to know that the attacker here is a good guy.   E.g., in the case of the OpenDNS behavior being described here, we don't know if OpenDNS is protecting us or attacking us.

A solution to this problem would require that there be a way for the MITM to signal that in this particular case, the connection is being blocked, and to sign that assertion with a cert that the application is configured to trust.   This establishes a trust relationship with the protecting party (the operator of the OpenDNS server) that the user can agree to or refuse to agree to, and if the UI is done well, the user can be reminded that this intercept is the result of them agreeing previously to such intercepts.

This avoids presenting the user with something to click through, but also provides a way to attribute the intercept to a specific, authorized entity, so that if that entity decides to censor something I didn't agree to have censored, there's a way for the service provider to help me to understand why I can't access their service.

I'm responding in detail here because I want to make it clear that I am no longer a proponent of the original proposal, not because I'm specifically advocating what I describe above.   Another way to deal with this problem is to simply not provide the "bad cert" popup in the first place—that's a very bad UI design, and I've noticed that modern browsers are starting to abandon it (yay).