Hello,

On Jun 13, 2015 4:28 AM, "Michael Catanzaro" <mcatanzaro@gnome.org> wrote:
> On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
> > >
> > But that's not even right.  Suppose you have a captive portal that
> > wants you to log in via your Google account.  It can send you do
> > https://accounts.google.com, and your browser can verify the
> > certificate and show you an indication that the connection is secure.
> > Then you really can safely enter your password.
>
> Hmmm, I didn't realize legitimate portals might take you to the public
> Internet.

I think I've seen this in airports and in some hotel chains.

Yes; sadly, many “legitimate portals” (easily 50% of the airport hotspots I have encoutered in Europe) are pretty much attackers.

In particular, many of them want to bypass hotspot detection so that the log in screen does not appear in the sandboxed hotspot sign-on browser; by now it is a pretty standard feature of business access points to have a “bypass hotspot detection” checkbox. (For iOS, this has reportedly been done by recognizing an unique User-Agent used for the hotspot check; not sure about Android.)¹

They want to use the regular, unsandboxed, browser so that
What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider deliberately let the hotspot probe lookup and connection through, but kept redirecting everything else?
   Mirek

¹ You can guess what this does to any applications which use unauthenticated HTTP to download data in the background: all that data suddenly becomes the hotspot login page and the application may not realize there is anything suspect about it.