Captive portal detection server hosting

RESOLVED FIXED

Status

Cloud Services
Operations: Marketplace
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: jcheng, Unassigned)

Tracking

other
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(blocking-b2g:tef+)

Details

(Whiteboard: [NPOTB])

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
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?
(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".
Assignee: nobody → server-ops
Component: Server: Other → Server Operations
Product: Mozilla Services → mozilla.org
QA Contact: shyam
Version: unspecified → other
Your test page currently returns "true".  Should we use that or "Success"?  I'm guessing the device expects something specific?
(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.
Could we get an ETA for this bug please?  Its a blocker for 1.0.1 (shira requirement).
blocking-b2g: --- → tef?
blocking-b2g: tef? → tef+
Blocks: 851760
Punting to a more appropriate queue.
Assignee: server-ops → server-ops-webops
Component: Server Operations → Server Operations: Web Operations
QA Contact: shyam → nmaul

Updated

5 years ago
Whiteboard: [NPOTB]

Comment 7

5 years ago
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?
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.

Updated

5 years ago
Assignee: server-ops-webops → server-ops-amo
Component: Server Operations: Web Operations → Server Operations: AMO Operations
QA Contact: nmaul → oremj
I don't see a Paul in the CC list.
Flags: needinfo?(ladamski)
Flags: needinfo?(ptheriault)
Clearing NI on me, I think that was covered in previous comment.
Flags: needinfo?(ladamski)
emailed paul
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
Flags: needinfo?(ptheriault)
BTW, this is how Apple does it.

http://erratasec.blogspot.com/2010/09/apples-secret-wispr-request.html
Is my proposal in comment 7 adequate? What can I do to close this out?
(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.
File is hosted at http://detectportal.firefox.com/success.txt.

Monitoring will be set up in Bug 866200.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Component: Server Operations: AMO Operations → Operations: Marketplace
Product: mozilla.org → Mozilla Services

Updated

2 years ago
Blocks: 1215006
No longer blocks: 1215006
You need to log in before you can comment on or make changes to this bug.