On Tue, Jan 2, 2018 at 12:08 PM, Mateusz Jończyk <mat.jonc...@o2.pl> 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 <mat.jonc...@o2.pl > > <mailto:mat.jonc...@o2.pl>> 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 > > TLS@ietf.org <mailto:TLS@ietf.org> > > https://www.ietf.org/mailman/listinfo/tls > > <https://www.ietf.org/mailman/listinfo/tls> > > > > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
