842953 - Captive portal detection server hosting

Status: RESOLVED FIXED

(Cloud Services :: Operations: Marketplace, task)

Description

[Joe Cheng [:jcheng] (please needinfo)]

This bug is to follow up on the server request for Bug 752982 - Captive portal pop up dialog is not automatically triggered on Wifi connect

To support captive portal detection in B2G, there needs to be a captive portal detection server hosted.

Not sure if this is the correct component, please change if needed. Thanks

Comment 1

[Lucas Adamski [:ladamski]]

Could we get some more detail into this bug to describe what needs to be implemented? Do we need a new server or just a specific page (and what URL)?  What string(s) should the page contain?

Comment 2

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Lucas Adamski from comment #1)
> Could we get some more detail into this bug to describe what needs to be
> implemented? Do we need a new server or just a specific page (and what URL)?
> What string(s) should the page contain?
We only need a static web page like http://people.mozilla.org/~schien/test.txt. The page content could simply use "Success".

Comment 3

[Lucas Adamski [:ladamski]]

Your test page currently returns "true".  Should we use that or "Success"?  I'm guessing the device expects something specific?

Comment 4

[[:fabrice] Fabrice Desré]

(In reply to Lucas Adamski from comment #3)
> Your test page currently returns "true".  Should we use that or "Success"? 
> I'm guessing the device expects something specific?

The returned value is configured in the captivedetect.canonicalContent preference, so it can be anything.

Comment 5

[Lucas Adamski [:ladamski]]

Could we get an ETA for this bug please?  Its a blocker for 1.0.1 (shira requirement).

Comment 6

[Ashish Vijayaram [:ashish]]

Punting to a more appropriate queue.

Comment 7

[Jeremy Orem [:oremj]]

Just to confirm. This just need to be one text file, containing the work "success" and can be hosted at any URL?

Does it need TLS or can it just be plain http?

Comment 8

[Lucas Adamski [:ladamski]]

Sorry this was (unfortunately) covered via email earlier:

Yes, I think we should expect this to scale to a very high number of connections.  Putting this on some linearly scalable solution would make the most sense.  

Good question re HTTP vs HTTPS, but I believe it actually should be HTTP.  Reasoning is that if a captive portal wants to MITM HTTPS to put in a login, it'll end up throwing an untrusted cert chain error and so we'll have to assume any cert error == captive portal anyway.  So it doesn't seem to buy us anything.  Adding Paul to sanity check, tho.

A page just containing the string "success" makes sense to me.

Comment 9

[Dietrich Ayala (:dietrich)]

I don't see a Paul in the CC list.

Comment 10

[Lucas Adamski [:ladamski]]

Clearing NI on me, I think that was covered in previous comment.

Comment 11

[Dietrich Ayala (:dietrich)]

emailed paul

Comment 12

[Paul Theriault [:pauljt] (no longer reading bugmail)]

Sorry I replied to the email, not the bug. TLDR: use http not https.

With http Wifi network could intercept/spoof the expected response, but all that would do is:  
 * provide the expected response (instead of us) -> Captive portal sign-on doesn't load, and this is actually needed sometimes for weird portals 
 * try to poison the cache to DoS this feature ->  current code bypasses the cache [1] so no issue here.

So I can't see an issue here with using http. And afaict, with current code, https wouldn't actually work, since we only trigger captive portal on non-matching response OR HTTP redirect. IE we don't trigger on other errors, such as cert errors.

Some brief research also seems to point to both IoS and Android doing this detection over http, not https.

[1] https://mxr.mozilla.org/mozilla-central/source/toolkit/components/captivedetect/captivedetect.js#29

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

BTW, this is how Apple does it.

http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html

Comment 14

[Jeremy Orem [:oremj]]

Is my proposal in comment 7 adequate? What can I do to close this out?

Comment 15

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Jeremy Orem [:oremj] from comment #14)
> Is my proposal in comment 7 adequate? What can I do to close this out?
Txt file hosted by plain http is enough.

Comment 16

[Jeremy Orem [:oremj]]

File is hosted at http://detectportal.firefox.com/success.txt.

Monitoring will be set up in Bug 866200.