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

[Eric Rescorla <[e-mail]>]

On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk <[e-mail]> 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 <[e-mail]
> > <mailto:[e-mail]>> 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
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/tls
> >     <https://www.ietf.org/mailman/listinfo/tls>
> >
> >
>
>