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

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 2 Jan 2018 20:15:09 +0100

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jan 2018 11:37:59 -0800

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 <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: JW <[email-masked]>
Date: Tue, 02 Jan 2018 15:01:48 -0500

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 <[email-masked]> Date: 1/2/18  2:37 PM  (GMT-05:00) To: Mateusz Jończyk <[email-masked]> Cc: [email-masked] 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:

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

for

        ||

Greetings,

Mateusz Jończyk

TLS mailing list

[email-masked]

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 2 Jan 2018 21:08:40 +0100

Hello,
Thank You for reviewing my email.

W dniu 02.01.2018 o 20:37, Eric Rescorla pisze:
> use cases because the information being provided to the user is unverifiable.
> I.e., this
> 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. This is no less secure then an alternative: a TLS
certificate error that conveys no message to the user whatsoever.

The message could theoretically be signed by some filtering party, but this is
out of scope here.

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 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

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Hello,
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/tls>
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 2 Jan 2018 20:18:42 +0000

On 02/01/18 20:08, Mateusz Jończyk wrote:
> string cannot be trusted. 

There isn't always a browser. I'd say caldav was responsible for
nearly as many cert warnings for me, but I only know that 'cause
I delved into detail to find out. And the same'd be true of any
application that regularly pulls from somewhere. I think that's
another reason to handle this in the capport wg - I'd guess folks
there are more aware of the full range of cases that may need
handling and of how to try interpose the portal web page stuff
before other applications see the n/w as active (or whatever it
is they're doing with HTTP:-).

> This is no less secure then an alternative: a TLS

That's true. OTOH, I'm not sure a different error is any more
secure either.

S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jan 2018 12:20:44 -0800

On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk <[email-masked]> wrote:

> unverifiable.
> the

Users tend to ignore that kind of warning.

> 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.

> 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

> machine

---

From: Mateusz Jończyk <[email-masked]>
Date: Tue, 2 Jan 2018 22:40:06 +0100

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 <[email-masked]
Not any more then they ignore certificate warnings [2].
> No, I don't believe that that's correct, because the certificate warning does not
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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Jan 2018 08:56:11 +1100

On Wed, Jan 3, 2018 at 7:18 AM, Stephen Farrell
<[email-masked]> wrote:
> [...] the capport wg - I'd guess folks

As chair of capport, this is definitely something for that group.  The
current approach we are taking there avoids having user equipment
attempt to connect to anything at all, which avoids this class of
problem.  If you look at modern devices, they all probe a network
before making the interface available to applications, and most of
what we would be doing exists at that probing phase.

We are additionally considering a network-based signal for those cases
where the attempt is made anyway, but I don't think that is firm yet.

Captive portal cases are separate to those related to selective
blocking of names or destinations, which is essentially a censorship
mechanism.  We've been careful to avoid creating mechanisms to support
that sort of discrimination.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 2 Jan 2018 13:56:19 -0800

> Not any more then they ignore certificate warnings [2].

That's not clear. We would be providing some sort of attacker-controlled
text to the user with a warning that says "you can't trust this". That's
difficult to pull off.

Moreover, the certificate warnings are under control of the browser, but we
actively work to discourage the user from ignoring them. Moreover, for HSTS
sites, the browser doesn't allow the user to override them, so providing
some attacker-controlled information would make the situation materially
worse. And given that a lot of the sites which people are likely to hit
with captive portals are in fact HSTS sites (because HSTS is common in big
sites) instead showing attacker controlled information would make things
materially worse.

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jan 2018 17:06:28 -0500

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).

---

From: Geoffrey Keating <[email-masked]>
Date: 02 Jan 2018 14:29:39 -0800

Two problems with this proposal, that don't occur with the proposal
the capport WG is working on, are:

- What do you do if you get one of these alerts over multipath TCP?

- What happens if some site far away on the Internet sends you one of
  these alerts?  Perhaps because DNS was forged and hasn't timed out
  yet?

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 03 Jan 2018 04:05:01 +0000

Eric Rescorla <[email-masked]>于2018年1月3日周三 上午5:57写道：

> Moreover, the certificate warnings are under control of the browser, but
> we actively work to discourage the user from ignoring them. Moreover, for
> HSTS sites, the browser doesn't allow the user to override them, so
> providing some attacker-controlled information would make the situation
> materially worse. And given that a lot of the sites which people are likely
> to hit with captive portals are in fact HSTS sites (because HSTS is common
> in big sites) instead showing attacker controlled information would make
> things materially worse.
>

providing some attacker-controlled information would make the situation
materially worse.  +1

Although some browsers support HSTS, but also offer a "user friendly"
configure item to ignore all ssl warnings.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan