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

[Mateusz Jończyk <[e-mail]>]

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