Dave Dolson <[email protected]> wrote:
> I’d like to hear from browser vendors as to why the browser gets
> sandboxed when interacting with a captive portal.
Security in layers.
The browser contains lots of interesting cookies and other state.
A captive portal could, for instance, provide a stack of img URLs to places
where the user might have cookies, and the browser may reach out to try
to load things. Even if those URLs are HTTPS and the captive portal lets
them through, just observing the size of the packets would tell the
portal operator whether or not the user has a relationship to that
entity. Of course, if they put http URLs in then snooping is obvious.
(The operator can, of course, do this anyway, but the user does have a
point where they can, for instance, bring up a VPN to protect all their
traffic. My Android phone now apparently does this for me automatically when
I'm on high-quality public WiFI. More cool is that it appears to use IPv6 on
the inside. More funny was that google then alerted me to suspicious
activity from an IPv6 I'd never before logged into... which was the inner
tunnel IP...)
> If one could trust the URL came from the local network (via DHCP),
> could restrictions be lifted?
I don't think this matters at all.
> If the URL were HTTPS, and certificates were valid (e.g., valid cert of
> Chicago OHare Airport), could restrictions be lifted?
I don't think so. I'm also unclear how the end-user can be sure that the
certificate in question is really from the location they are in. In many
cases, it's not "chicago-ord.com", but rather, "ord.boingo.com"...