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 <mat.jonc...@o2.pl > <mailto:mat.jonc...@o2.pl>> wrote: > > 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. Not any more then they ignore certificate warnings [2]. > > 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. > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
