Re: Badly behaved captive portals

On 9/21/12 7:19 PM, "Andrew Betts" <andrew.betts@ft.com> wrote:

>
>On 21 Sep 2012, at 17:46, Tobie Langel wrote:
>
>> On 9/21/12 5:53 PM, "Andrew Betts" <andrew.betts@ft.com> wrote:
>> 
>>>>> However, today we've been looking at the possibility that a captive
>>>>> portal simply returns a login page on the URL you requested rather
>>>>> than returning a redirect.  It wouldn't be good practice, but it
>>>>>would
>>>>> be technically feasible.  In that situation, potentially our user
>>>>>will
>>>>> get the captive portal page appearing in our app, and will have to -
>>>>> rather ironically - turn off their network connectivity in order to
>>>>> get the app to work.
>>>>> 
>>>> Isn't this issue orthogonal to AppCache, and isn't the only mitigation
>>>> strategy to use SSL?
>>> 
>>> No, I don't see it that way.  Captive portals are rarely incompetent
>>> enough to allow SSL traffic without login (otherwise we'd all be
>>> leeching free wifi), so they would likely just intercept it and return
>>> the login page anyway, despite the certificate errors that would
>>> result from that.  In addition, users typically don't start their
>>> session on SSL - I type gmail.com, and Google redirects me to https.
>>> By then I've already hit the captive portal.
>> 
>> I was referring to the case where the user is already on
>>https://gmail.com
>> and XHR requests hit the portal instead of a redirect.
>> 
>>> Since an element of the design strategy behind the current appcache
>>> spec is intended specifically to cope with captive portals
>> 
>> My understanding is its not so much coping with captive portals as it is
>> avoiding malicious behavior.
>> 
>>> it seems
>>> sensible to ensure that we capture that use case when considering any
>>> possible improvement or replacement to appcache.  I think this covers
>>> it:
>>> 
>>> - A user is in a hotel lobby and connects to the WiFi, not knowing if
>>> it is free or not.  They use a homescreen shortcut to launch a
>>> previously saved web app, hoping it will work.  But the hotel wifi is
>>> serving a captive portal login page in response to every request.
>>> Nevertheless, the user sees the app start and is able to use the
>>> offline features.
>> 
>> How can you possibly mitigate this without relying on https?
>
>I can immediately think of two ways:
>
>1) if I had a proxy/controller type thing, I'd be able to inspect the
>response, see it was not what I expected, and fish something out of
>localstorage instead.

How can you see the response was not what was expected? The portal could
very well make the request on your behalf and inject extra content in it
(like adds, for example).

>2) if I had a way of doing fallbacks without a network check first, I
>could configure those in the manifest for the entry point URLs, and avoid
>any risk of captive portal interception

Agreed, that's the Chromium's INTERCEPT feature, which I think is a great
add on, but which doesn't protect you from the kind of issue you're
talking about. Only removing FALLBACK would help you there.

--tobie

Received on Friday, 21 September 2012 17:26:59 UTC