Open Bug 2036862 Opened 1 month ago Updated 3 days ago

Firefox's captive-portal detection misfires on Finnair flights (due to their panasonic.aero "Panasonic Avionics" in-flight network equipment serving a redirect for *specifically* our captive-portal URL)

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Type:
defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged][necko-priority-new])

Lars noticed on a Finnair flight that Firefox's captive-portal detection UI is appearing on tab that he opens on Finnair flights, even after authenticating to get fully online.

It turns out that's because, even when fully online, the flight's network equipment specifically intercepts requests to our captive-portal-detection endpoint ( http://detectportal.firefox.com/canonical.html ) and returns a different answer from what we expect (redirecting to their own URL). No idea why they're doing that, but it means we end up detecting this as a captive-portal situation even though other URLs are resolving just fine.

We should figure out a way to mitigate this.

The equipment is from Panasonic Aviation, so I doubt it's just Finnair that's affected.

From a fully-connected device, an HTTP request our endpoint (executed via curl e.g. curl -v http://detectportal.firefox.com/canonical.html) should return HTTP/1.1 200 OK with this HTML content:

<meta http-equiv="refresh" content="0;url=https://support.mozilla.org/kb/captive-portal"/>

On Lars's Finnair flight, it instead returns this HTML content:

<html>
<!--
<?xml version="1.0" encoding="UTF-8"?>
  <WISPAccessGatewayParam
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="http://gateway.pacwisp.net/xml/WISPAccessGatewayParam.xsd">
    <Redirect>
        <AccessProcedure>1.0</AccessProcedure>
        <AccessLocation>GEN3FIN-Prod</AccessLocation>
        <LocationName></LocationName>
        <LoginURL>https://gateway.pacwisp.net/login?target=xml</LoginURL>
        <MessageType>100</MessageType>
        <ResponseCode>0</ResponseCode>
    </Redirect>
  </WISPAccessGatewayParam>
-->
<head>
<title>...</title>
<meta http-equiv="refresh" content="0; url=http://portal-pax.exconnect.panasonic.aero">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="-1">
</head>
<body>
</body>
</html>

However, for Lars on this flight, other HTTP URLs return the expected content for him (consistent with what I'm getting on a regular internet connection). We tested these ones in particular:
(1) A mockup http endpoint I stood up that returned the same <meta http-equiv="refresh" content="0;url=https://support.mozilla.org/kb/captive-portal"/> content as our captive-portal.
(2) http://detectportal.firefox.com/ (no "canonical.html" suffix)
(3) Chrome's endpoint http://connectivitycheck.gstatic.com/generate_204

So they're not sniffing-for/rewriting the specific plaintext html content that our endpoint returns; and they're not intercepting detectportal.firefox.com as-a-whole; and they're not intercepting browser-captive-portal-detection-pages in general. Just our specific URL, for unknown reasons...

Valentin suggested that we stand up our own "generate_204" http endpoint similar to Chrome's, to use along-with or instead-of our existing captive-portal page.

The Bugbug bot thinks this bug should belong to the 'Core::Networking: HTTP' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Networking: HTTP
Product: Firefox → Core

(In reply to Lars Eggert [:lars] from comment #1)

The equipment is from Panasonic Aviation, so I doubt it's just Finnair that's affected.

https://www.panasonic.aero/press/astrova-achieves-historic-milestone-with-one-hundredth-airline-program suggests that at least one of its systems is used by "over 30 airlines for 100 individual airline programs". Looks like WestJet might be one, based on bug 1913766 having "aero-panasonic" in its screenshot.

We should do some outreach to find out if this URL-interception is something they have an explanation for & are willing to remove. I found a contact-us page here, as a start: https://www.panasonic.aero/contact-us
The phone number there isn't useful -- it hits a switchboard where you need to ask for a specific person by name in order to proceed. There is a customer-service email address, though... I'll poke around and see if I can find a contact.

See Also: → 1913766
Summary: Firefox's captive-portal detection misfires on Finnair flights (due to their network equipment serving a redirect for *specifically* our captive-portal URL) → Firefox's captive-portal detection misfires on Finnair flights (due to their panasonic.aero "Panasonic Avionics" in-flight network equipment serving a redirect for *specifically* our captive-portal URL)

The phone number there isn't useful -- it hits a switchboard where you need to ask for a specific person by name in order to proceed. There is a customer-service email address, though... I'll poke around and see if I can find a contact.

Thanks Daniel!

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-new]

Sure! For the record, I did email the customer-service email address. I also found contact-info for a software engineer who may work there, and I sent an email to them as well. I'll post an update here if/when I hear back.

Isn't it just a plain bug on their end if they redirect to their login page even after signing in?

The issue is that we keep showing the "click here to login" slideout in the UI.

You need to log in before you can comment on or make changes to this bug.